This episode of the Acima Development Podcast dives deep into the art of effective meetings, exploring both what makes them successful and what causes them to fail. Mike opens with humorous anecdotes of ineffective meetings, such as “death by PowerPoint” and marathon discussions that inadvertently turned into workout sessions. These examples highlight the common pitfalls of meetings that lack focus, preparation, or structure. The episode aims to turn these common frustrations into learning points for hosting productive, engaging, and goal-oriented meetings.
\n\nPanelists Tad, Eddy, and Dave contribute insights into the key components of successful meetings. Tad emphasizes the importance of structure, such as having a clear agenda, timekeeping, and redirecting off-topic discussions to maintain focus. Eddy underscores the value of respecting participants' time, avoiding unnecessary tangents, and setting clear expectations for the meeting’s purpose. Dave provides a philosophical perspective, distinguishing between passive, reactive participation and proactive engagement, and stresses the importance of preparation and decision-making as central objectives of any meeting. The group also discusses strategies like giving everyone an active role, employing visual aids, and embracing rules like timeboxing to manage discussions effectively.
\n\nThe conversation concludes with actionable takeaways for designing better meetings. Key recommendations include establishing rules of engagement, distributing materials beforehand to ensure participants come prepared, and maintaining focus through time management and participant roles. The panel advocates for meetings that prioritize purpose over duration, ensuring decisions are made efficiently. By adopting these strategies, the podcast argues, teams can transform meetings from dreaded time sinks into productive, collaborative sessions that respect everyone’s time and energy.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I am hosting again today. With me, I have a nice panel. We've got Dave.
\n\nDAVE: Howdy, Howdy.
\n\nMIKE: Ramses.
\n\nRAMSES: Howdy, Howdy.
\n\nMIKE: Eddy.
\n\nEDDY: Hey.
\n\nMIKE: And Tad.
\n\nTAD: Hi.
\n\nMIKE: Today, we are going to be talking about meetings, specifically about how to have effective meetings. And I'm going to present the topic on purpose because then I'm going to talk about the alternate. Because I think that if you're listening to this, and you're old enough to listen to a podcast, you have been in a horrible meeting. It was ineffective. It seems to be the default state of meetings because they are awful. They're famously bad.
\n\nI've been wondering about which particular example to bring up. I have a couple from my experience of bad meetings. Once somebody offered...when I was doing a presentation, they had a related presentation, and they had some slides for it. This was some time back. I was teaching a class, and they had some slides. And they said, “Well, do you want some slides for your class?” And I said...and I paused for a moment. And I thought, slides? And I asked him, “Have you heard of death by PowerPoint?” [laughs] And he said, “Yes, actually, I have.” And it surprised me that the question was even asked because it just sounded so opposite of what I thought an effective discussion would be made of. It’s the first example that came to mind.
\n\nI had another situation, this was quite a few years ago, where the team I was on discussed things so much. We had such long discussions about every architectural decision because we were building out a new application. It was hours. It was like six hours a day. And this was before people generally had cameras on. This is long enough ago, you know, video didn't always work, so it was audio meetings. And I couldn't stay awake. So, I started doing pull-ups and push-ups [laughs] during my meetings. And I put on 15 pounds of muscle from my meetings [laughs]. It was so bad that it actually improved my health [laughs].
\n\nTAD: Nice.
\n\nMIKE: So, I don't know whether to complain about that or not, but meetings can be that bad. And, on the flip side, when you're in a meeting that's good, that is on point, and you get your topic covered, and you end early, everybody is just like, “Wow, how did that happen? That was a good meeting.” And I think it stands out because it's so different from what we expect by default. It turns out meetings are hard. It's hard to have a good meeting. And so, we're going to talk at length about that today.
\n\nAnd I can give my ideas, but I've talked about some bad ones. I'm going to kind of step back and ask the panel here, you know, what do you think is important to have a good meeting? Or we can start off on the other track as well, you know, feel free to mention what you think makes for a bad meeting. I have some things that I believe are key to having a good and effective meeting, but I'm not going to throw those out first. I'm interested in what you all have to say, and then we'll build from there. So, what makes for a good meeting?
\n\nTAD: One of the reasons why this topic kind of struck me is because I've actually...and I haven't been a member recently, but I was a member of Toastmasters for about four years. And it's primarily known as a public speaking club. But they’ve kind of tried to change the branding a little bit of more just a leadership business public speaking. Like, there's a whole host of skills that they really are trying to promote. And one of them is specifically meeting management because every Toastmasters meeting they require that you have an agenda. They require that you know all the speakers, all the things that are going to happen beforehand, how long they're going to speak for, that sort of thing.
\n\nAnd as the person that runs the meeting, the success of your meeting is determined by did you hit all of the time points, and did you close the meeting out in an hour or less? And that's considered success, right? And they actually have someone in the meeting who's the timekeeper who the person running the meeting has to consult regularly like, okay, are we on time? Oh, did we fall behind? Okay, let me adjust. So, for me, it would be, do you have an agenda? Do you know what's going to happen in that meeting? Do you have a good idea of how long each piece of that meeting is going to take? And did you end on time?
\n\nAnd part of that is, also, a lot of times things will come up in the meeting, and you have to have a way to, like, you’re like, “Okay, that's a great point. That's off-topic.” What's the process to handle something like that, right? Okay, do you take a note? That will be an action item. We'll take that offline. We'll have a discussion about that later, that sort of thing, too. So, those are just a handful of elements that I think make for a good meeting.
\n\nMIKE: Okay. So, I think you've given a good list there. I'm going to come back to some of those as host because I think they're worth revisiting. What about others in the call here?
\n\nEDDY: I think one thing people need to realize when they set up meetings is that you need to respect other people's time, right? If you're going to ask someone to be there for 30 minutes and then you spend 20 of those minutes about random stuff that's not even part of the agenda or the topic, you're not being effective, and then you're actually causing people to not pay attention, right? So, I think what's really important is that you have to respect the fact that other people have other things to do and to stay on course. I think that's one of my biggest concerns when being part of meetings.
\n\nAnother one that kind of just top of my head is timeboxing. It's something that we like to do in other meetings, right? Like, set things up in a certain window. If you think that it's going to go longer than that, axe it and then talk about that elsewhere. Again, it goes back to respecting people's time. I think that's really important.
\n\nAnd probably setting some expectations, like, some ground rules, right? Like, this is what this meeting is going to be about. Let's try to not go into tangents and stay on course. So, I think those three core things, for me, is what makes meetings important.
\n\nDAVE: When I think about good meetings, there's, like, the how, and the why, and those are two separate things in my mind. Like, the why, like, what is this meeting for, and, you know, why are we doing this? Most people come to a meeting in reactive, passive response mode. Just like, well, I'm just going to go to this room. I'm going to sit down, and then I'm going to see what happens. And then, I'm going to respond or react to it. And that's what most of us do in our meetings. And when you've got 99 people in a meeting, and only one person has a 5-minute agenda, it's going to be an hour-long meeting where it's just chit-chat, and socialize, and discussion.
\n\nThere's a really good very, very short book. It used to be free. I don't know if it is anymore. It was paid for a while. It was, like, two bucks at the time. It's called “Read This Before Our Next Meeting.” And he takes a very aggressive stance. I mentioned it a couple of weeks ago in the podcast, a couple of episodes ago, that we do stand up with 30 people on Michael’s teams, and we're out in five minutes. And Will got mad.
\n\nHe’s like, there's no way you're having...and I'm like, there's no way we're getting together, and discussing, and socializing, and screwing around and not having a meeting. You're right; we're not getting any of that done. But we are getting decisions made, and we are getting emergencies addressed, which was the whole point of that particular meeting.
\n\nThe read this before the meeting guy...I don't want to do a whole book report, but he basically says, “Meetings are to make decisions.” Everyone in the meeting should come ready to make that decision, which means they should have the information they need. Now, we do an architecture meeting where we get everybody together. And we say, “Let me show you this system,” and that's kind of information dissemination. If we wanted to be really, really aggressive, we could say, “You know what? Why don't you go make a 20-minute video? And then, in architecture, we'll just show people where the link is, and they can go watch it on their own time. We don't have to have everybody here.”
\n\nI kind of like the socialization side of it. It's not worth, you know, like, really getting it after. But what I noticed is that if you go through any of the meeting etiquette books, they'll tell you: don't have status meetings; just stop. Because you should know what your team is doing. You should know what's going on, and if you don't, you're going to end up one person talking about “Well, I'm working on this,” and half the people in the room aren't on that team. They don't care. It's like Eddy said, “ Be respectful of people's time.”
\n\nAnd I think it's really, really interesting that if you...that's the how versus the why. If you come in ready to say, “We need to make a decision. Are we going to use this technology or that technology, or is there a third-party technology we need to be ready for?” That's a very, very active meeting at that point. You come in. You have an argument, you know, hopefully. Well, hopefully not.
\n\nBut, I mean, like, if you're prepared to debate and push back, everybody's got their ammo loaded. Everyone's loaded for bear because they came ready to talk about this is the Elasticsearch problem, or this is the Sidekiq problem, or this is dah dah dah. And everybody comes ready and laser-focused; I think we should. And then, the objective is get to a decision. Everybody commits to the decision, and we walk out.
\n\nNot to tattle on ourselves, but, like, we've talked about dry monads versus dry transactions for like two years, and we haven't made a decision. And now they're both in the codebase because we have people that want to champion it. And that's fine. I mean, that's one of our functions. That's how we do things, and that's fine. But if we had wanted, if we needed a very strong discrimination of, like, “We want one, and we definitely want not the other.” We would send everybody, “Go study this, go study that, play with them both. Come armed and ready because when you walk out, you're going to be using one of these, and it might not be the one you like.” And that's a very active meeting. You come much more energized and ready to go.
\n\nAnd you can actually have...I've done this before where I've walked into a meeting, and we're all loaded for bear, and then, also, we find out every single person in the room already agrees. Like, there's literally nobody backing the other contender, and it's like, we're done. Let's just not have the rest of this meeting. And you kind of go from there. So, anyway, that's my excited thing.
\n\nI've got a bunch of, like, howsies, you know, like, functional things to do. But that was the big thing is, if you come ready and focused and there's an agenda in advance of, this is what we want to accomplish, and as soon as we accomplish it we're done, oh man, you motivate people by saying, "Would you like some of your life back?"
\n\nTAD: Yeah, I think I want to say Jeff Bezos does that at Amazon, where he requires you to have a full written up memo before the meeting of, what's the core discussion topic? Why is it important? What are the details of it? And if you show up and you haven't read that, he'll be like, “Okay, who hasn't read it? Oh, some of you haven't read it. Okay, we're going to take five minutes at the beginning of this meeting or whatever. And everyone has to read through the document and familiarize themselves with all of the things we're about to discuss.”
\n\nSo, the idea being that you have to do your homework before the meeting or else what's the point of the meeting? Because I think I've been in meetings and you've all been in meetings where you get there, and you realize, oh, we've just got a bunch of questions. We've got a bunch of stuff we don't know. Okay, well, now it's time to assign homework to people and come back and have the real meeting later because this meeting was just a realization that we don't have anything prepared [laughs]. We don't know what's going on yet.
\n\nEDDY: So, you're saying that if a meeting leads to another meeting because that meeting wasn't productive [laughs], that's a problem.
\n\nTAD: Yeah.
\n\nDAVE: I've worked with a manager who took the extreme, draconian other end of that, which was “Has anybody not read this?” And, you know, somebody would be like, “Oh, I'm sorry, I need to catch up on this.” And he just canceled the meeting on the spot. And, like, “No, we need everybody in on this, and I'm not going to waste everybody else's time. We'll meet tomorrow.” And they came ready the next day. I mean, there were some scalded paws, and this particular person didn't mind conflict. He didn't mind upsetting people. But, boy, we all came ready the next day. And --
\n\nEDDY: And, again, you're setting up expectations, right? I think that's why it's important. Like, we come back to that again is that you're respecting people's time, right? You're setting up expectation of what that meeting is going to be about, right? And if you're not going...basically, if you arrive late, or you're not participating, you didn't do your homework, right, then you're not respecting other people. You're saying that your time is not worth --
\n\nDAVE: I wouldn't go so far as to call it disrespect. It absolutely can be considered disrespectful. But I think a lot of us don't realize that, oh, I’ve got this stupid meeting. Fine, I'll just go and find out what it's about, right? And you show up in reactive passive mode. And those are the same thing, right? If you willfully show up unprepared, you're a jerk, yeah, so...
\n\nMike, you talked about being in six-hour meetings, and I had a thought about that, which was that was not a meeting. That was a mob programming design session, right? The objective was to come up with the design. What are we going to build? And if you tell people that's what this is going to be, it's much more palatable.
\n\nEDDY: You know, what I'm actually really interested in is kind of a tangent from that, is, if it really is true, what you said, and I'm hoping it's a bit of an exaggeration, Mike, but if you're in six-hour meetings a day, right, I for one struggle to pay attention for longer than, like, 15 minutes on something before I start wandering off and, you know, start doing stuff. So, I think I have some pretty gnarly ADHD, right, and if I'm not being focused, if you're not actively engaging me, I'm just going to start to drift, and then I'm not even going to listen to you anymore. So, I guess as we progress, I'm really curious to kind of dig your mind on how the heck.
\n\nMIKE: Well, I wasn't exaggerating so you know [laughs]. That was literally what was going on, and it went on for months, and it was brutal [laughs] for all the reasons you mentioned. That's why...and I'll actually say that...and I think we're going to talk about this in a future podcast. One thing that is important to realize is we do have finite ability to concentrate. And if you don't have some way to get through that, yeah, everybody's going to be disengaged [laughs].
\n\nTAD: Well, I think it's especially bad, well, you know, like going back to when I was team lead, I would go from meeting to meeting to meeting. And people would just put stuff on my calendar, and I'd just show up in a meeting. I'd just click next meeting, next meeting, next meeting, and they're back to back to back. And I didn't even know what the meeting was about or why I was in it. I'd just kind of be there.
\n\nBut I think ours is especially tough because a lot of times our meetings are very complex, technical, think real hard kind of meetings. And those kind of meetings really drain your battery a lot more than just a regular meeting, right, like trying to work out very complex systems and systems interactions. I feel like we need a lot more gaps between those types of meetings just to let your brain decompress than just a regular business meeting, right?
\n\nDAVE: I've worked with people, and fortunately, not many. It was, like, 10% of the population are psychopaths that tend to be on that dark triad thing. And I think we've all probably had this experience where there's that one guy who wants you to come to his meeting because he wants to control your time. And so, he's not going to give you an agenda. He's not going to tell you what the objective is. He just wants you here.
\n\nAnd you can tell because he's the guy that when you start looking at your laptop and thinking, you know, I could probably kick off another build, he's the guy that will pounce on you and say, “What do you think?” and will deliberately not tell you what they were just talking about. That's somebody who's a predator at that point. We've all worked with jerks, but it gets weaponized. And if you have people that are reactive and passive, it snowballs, and those people end up running the company, which is why they do it.
\n\nMIKE: So, you touched a little bit on wrong [laughs] meeting management for people. Well, also, on something that tends to just really destroy meetings, which is when you have a single individual who takes control, and that can be the host.
\n\nDAVE: If there's an objective, yeah, let's have a leader. Absolutely.
\n\nMIKE: But there's a difference between being the host to get toward the objective and being a host because you're the focus of the meeting [laughs]. And those are two very different things, right? One is self-aggrandizing, and the other one is to try to facilitate. And we should recognize that facilitation is valuable. Self-aggrandizement is horribly disruptive to meetings; you know, generally, self-aggrandizing is not acting in good faith. They'll say something to draw attention to themselves without necessarily providing value.
\n\nDAVE: Which, again, that's the objective of the meeting, right, is, daddy, come watch me swing basically. Yeah.
\n\nEDDY: But what I feel like really works with me is to try to have a discipline to not multitask and do other things, right, when it directly doesn't involve me. If someone's going and talking about something else, their updates or whatever, you know, and I'm like, okay, cool, I don't need to listen. And I do [laughs]...I go, and I do another task, right, I end up losing all the context.
\n\nAnd then, when I get brought back in, I'm like, oh, crap. I'm like, now I don't know if I should ask them if they need to [laughs] summarize again because I wasn't listening. So, I hate to say that I know stuff when I don't. So, if I have to have them course correct and kind of summarize everything they talked about at that point, I feel really bad. So, I really do my best to, like, try to not do other things while other people are talking because I'm also trying to active listen.
\n\nTAD: So, you need to reduce the distractions. Is that the [inaudible 18:36] there?
\n\nEDDY: Because it's so easy, right? If someone else is doing something, I'm like, oh, they're just talking. I'm going to go ahead and check my build, or something. Oh, I'm going to queue up something. It's really easy [laughs] to --
\n\nDAVE: But it’s also, especially if you've got ADHD, it's impossible to track a meeting where there's nothing interesting, nothing novel, nothing challenging, nothing urgent. If somebody else is talking about their project and it's not even your team's interface, and you start wearing down. And especially if you’ve got ADHD, you're like, I need a rabbit to chase. And so, you start looking at things.
\n\nSo, I agree with you that, as much as possible, it is courteous and powerful to be participating. So, I will do several...I have a bunch of tricks in my back pocket for that. Two very quickly are one is I will go look at...when I was a very short kid, I learned very quickly to never say, "I'm bored," because somebody would hand me some work if I did that. And so, I very quickly learned to entertain myself.
\n\nSo, if I'm sitting in a meeting and we're talking about a thing and I'm like, I have absolutely no interest in this, but they're using that API. I'm going to go look at the API. So, now I'm doing a distraction, but I'm actually trying to contribute by, you know, I'm literally trying to invent questions for the test and go look up the answers for them. It's a great way to study, right?
\n\nThe other one...and I think I've done this to all of everybody in this meeting, and it's not disrespectful. It is literally a coping strategy I use. And it takes guts the first time, and it's always kind of a risk. But if I get caught flat-footed, I don't hem and haw. I just go, “I'm sorry. I was looking at a thing on my laptop. Could you repeat the question, please?” Just own it. Because now what you're saying is I respect you enough to admit that I was distracted and that I wasn't paying attention, and you now have my full attention. And I apologize to everyone for making the question be repeated.
\n\nAnd I don't think I've ever had somebody say, "Fine, I don't want your answer," [laughs] and turn on. But if it was a thousand-person meeting, I wouldn't feel, actually, I would feel really, really bad, but I would agree it was an okay thing to do.
\n\nEDDY: Would you agree, Ramses?
\n\nRAMSES: Yeah, I think so.
\n\nEDDY: Okay, cool. He was paying attention [laughter].
\n\nTAD: So, a strategy that I use is I'll usually turn on subtitles or something. Because I'm like, oh, cool, like, if I'm listening but I'm not totally focused, oh, I need another level of stimuli to help me out here. And so I’ll turn on sub-styles, and I'll read what they're saying as they're saying it and that sort of thing. But I think that's also just probably a good meeting design is that you have lots of...it's not just droning for a PowerPoint. It's audio-visual discussion, variety, that sort of thing, to kind of break things up so that it's not as easy to just zone out in the meeting, right?
\n\nEDDY: Fun fact: part of the symptoms that I have with my ADHD is, if I'm watching a movie or a TV show, and I just try to hear what the dialogue is about, I can't distinguish between, like, sound effects and people talking. It gets mumbled [inaudible 21:57] and stuff like that. So, when I put subtitles on, it helps me keep focused, right? And it helps me be more engaged, and I can actually zone out all the rest of the noise because I'm able to correlate, you know, what they're saying versus what's being written on screen. So, subtitles, yeah, I should really --
\n\nDAVE: I love how fast live captioning went from being space race, futuristic, impossible. Like, in COVID, I don't think I had any meetings where I had live captioning. And now it's in Teams; it's in Google, their Hangouts, they'll do it. All these people will do it. And now we're all just sitting there, and we’re like, oh yeah, that's old hat. You need that. Turn that on. I love it.
\n\nEDDY: Yeah. But you also have to have it going live as you're in the meeting because if you try to retroactively go in and read the transcript, yeah no [laughs].
\n\nDAVE: I want to point out that I'm watching our live captions, and I said, “You need that. Turn that on.” And they transcribed it as turn that off. So, whoever's reading this podcast, pity!
\n\n[laughter]
\n\nMIKE: So, luckily, we have a professional transcriber [laughs], and not the digital version. I provide them with a digital transcript, mostly to see who's talking when so they can pick out the voices.
\n\nSo, I'm going to come back and draw out some themes here. We’ve spent quite a bit of time talking here about engagement and how engagement is a challenge. And I think that goes back to the beginning of why many meetings are so bad is because it is hard to try to maintain focus for something that is not engaging you. And doing that for multiple hours is [laughs]...the thing is, you're not going to. So, you're either going to feel bad, or you're going to be working hard and trying to make it work. Or you're going to...you're going to fail somewhere, right? And somebody's going to call on you, and you're not going to know...like, there's all these problems that come from there.
\n\nWe're talking there about meeting etiquette and how we stay engaged. But if you're thinking from the side of how to present, as mentioned, well, you need to have an engaging presentation that if you go in with an open-ended meeting where there's nothing visual, there's nothing audio, there's no agenda, what you're going to have is either people are going to chat. And if your goal is to socialize, well, maybe you've met your goal.
\n\nDAVE: Absolutely.
\n\nMIKE: And that has merit. So, if that's your purpose, fine. But, typically, you're trying to accomplish something else, and the engagement needs to be handled elsewhere and some proposals there. And I'm going to, again, I’m trying to pull all these threads together. You have an agenda. You have an agenda prepared beforehand and, you know, Tad started right off the bat with that, and not only you have agenda, but you have things time blocked. Time blocking has been mentioned several times.
\n\nDave mentioned that that preparation is not just having, you know, like, the names, you know, these topics we're going to talk about but to have preparation that happens before the meeting. So, an effective meeting comes when informed people come together to make a decision. And if you don't have the information and you don't have the preparation, then you're going to be spending your time getting people up to speed instead and maybe recognizing that. Maybe you're going to have a meeting where you're having a training meeting. Well, that's, again, that's a different purpose because you can't have an effective meeting unless people are prepared. So, that's something else that's come up.
\n\nAnd then, another thing that I caught there that we haven't talked too much about yet is that topics almost always tend to explode. They go longer than you would expect. And when that happens, you need to have a mechanism, some sort of rules in place to say, “Okay, great, this sounds like this is bigger than what we can fit in this meeting. And we're going to ruin the rest of the meeting, unless we take that and give it its own place.” And you need to have rules in place, some sort of mechanism to be able to do that. That's another thing that I'm hearing here.
\n\nAnd, you know, so we gave a checklist. You have your agenda, and you have the time boxes. You have advanced preparation that people are able to take part in before they make it to the meeting, and you have a mechanism to take distractions and lay them somewhere else so they can go be handled elsewhere. Now, if it's truly tangential and has nothing to do with what you're talking about, then you just set it down like, well, we don’t need to...let's get back to the topic. Or maybe it's important, say, “Okay, let's note that. We’ll bring that up in a more appropriate form.”
\n\nDAVE: And it's consciously deliberately...because everyone in the room is thinking, oh, we're trying to get this done. It's good to say, “Okay, we are going to do that,” or “Let's do that later.” Or “Not now.” Everyone should see, okay, yeah. And the gears are still turning for the objective we want.
\n\nMIKE: Another theme here is we're engaging more than just audio, so you have some visual representation. If you’ve got your agenda, you table something. You put that on a list that everybody can see you're putting it on the list. This is an action item. We're taking this elsewhere. You're keeping people engaged in a multi-sensory fashion wherever possible.
\n\nTAD: One thing I touched on, but I feel like I maybe should delve into a little bit deeper is, in Toastmasters, everyone at that meeting has a role and has a job at that meeting. There's no passive anything, right? Meaning that there's the person who's in charge of the meeting. You also have someone who's a timer, who's keeping track of how long everything took and keeping the meeting on track. You'll have someone who's like an ah master who's listening for ums and ahs and hums, right?
\n\nAnd they're keeping a tally, and they're actively going to give a report at the end of the meeting. These are the things that I picked up, you know, terrible, little noise things we add to all of our speech that we're trying to reduce. These are the things I noticed in the meeting. Someone is doing grammar checking, and they're making notes on that thing. And so, everyone in that meeting has something they're actively doing in that meeting.
\n\nAnd just, in a general meeting, you could have someone who's like, okay, I'm in charge of timekeeping, making sure we stay on task. I'm in charge of the action items. I'm going to keep a running list of every action item that comes out of this meeting, right? You could give jobs to all the people in the meeting and have something for them to do other than just passively sit and listen in a meeting. And I find that to be fairly effective that if I have something that I know I'm supposed to be doing, then I'm more likely to be paying attention, especially to the role that I've got in that meeting.
\n\nEDDY: That's a good point.
\n\nMIKE: Well, and that goes to the engagement that we've talked about. If you're in a situation where maybe one person is going to be presenting, then everybody else is going to be likely to disengage unless they have an assignment.
\n\nTAD: Yeah. Well, in Toastmasters, they actually have a role called listener who will ask questions at the end, you know, ask a question and say, “Oh, you know, so and so talked about there are three things that do this. What are those three things?” And the rest of the people are supposed to say like, “Oh, number one was this, number two was this, number three was this.”
\n\nAnd so, you know all these roles. You know the things that are going to get reported on at the end of the meeting. You know what you're going to get asked about. And so, just all those mechanisms make it more engaging because you know you're going to get asked about things. You know there's going to be a report on, like, a little summary report on all these aspects at the end of the meeting.
\n\nMIKE: And it's interesting because that's a training for meetings, right?
\n\nTAD: Yes.
\n\nMIKE: But general training tries to follow best practices. This is the ideal for a meeting. And so, we can learn from that, that in meetings where we're probably not going to have somebody counting the number of times, the presenter says, “Um” in a business meeting, but that idea of a designated listener who, you know, maybe he’s not asking the group. Maybe you have a designated...sorry, a dedicated listener who will ask the presenter at the end, you know, somebody who's looking for holes. And that could be done if you could have more than one person assigned to do that. They could be given assignments. Potentially, everyone in the room could be given the assignment to have a list of questions to ask at the end. There's things that could be done in order to enable that.
\n\nTAD: I think so.
\n\nEDDY: How short should meetings be is my next question. Or rather, another way to twist it, how long should they be before you [laughs] say, okay, after X amount of time, no one's paying attention, and everyone's done, right? Considering the --
\n\nDAVE: It’s a good point.
\n\nTAD: I just think there's a problem in that all of our calendars have one-hour blocks. And so it seems like if I have a meeting, I need to fill that one-hour block. And I would love to instead see, oh, this is a 30-minute meeting. This is a 45-minute meeting. This is an hour meeting. And more than an hour maybe is this should be more than one meeting because I don't know that any time you go over an hour, people are really staying focused on that meeting. I think there's a limit to how long a meeting can go and still be a good meeting.
\n\nEDDY: I want to say a threshold is 30 minutes tops, but that's [laughs] just me.
\n\nTAD: 30 minutes?
\n\nEDDY: Yeah.
\n\nMIKE: Well, you could have a 30-minute threshold for a topic. If you had two extremely engaging topics, each went 30 minutes, that might be an engaging meeting. But if your 30-minute topic starts to climb into 60, 90, then you're probably in a lot of trouble. And it probably depends also on the level of engagement. I've been in architectural discussion meetings on a whiteboard before, where, you know, time flies and three hours are gone. And everybody is like, “Oh, wow, we need to go eat lunch. That was a while ago.” Because everybody is up there drawing pictures, you know, and involved in that discussion and deeply involved in those technical details.
\n\nAnd then, there's other ones where you have the presenter up on the stage, and everybody checks out after five minutes max [laughs]. And those one meeting works and the other one doesn't. So, it seems like it does depend somewhat on the level of engagement from the group.
\n\nEDDY: I've drawn some stuff on a screen, on a laptop. And I've been like, cool, this is awesome, and I get distracted. As opposed to if I get up, get on the whiteboard, basically get a sharpie, and start drawing stuff, I'm engaging the same way, I think, but I think part of that is just nostalgia, right? Maybe. But I do tend to pay more attention if it's in a whiteboard in front of me [laughs]. It could just be that I'm just old.
\n\nMIKE: Well, and thinking about the sensory aspect of it, if you're looking at a screen [laughs], yeah, you don't smell the marker, you know, you're not moving in the same way. It’s genuinely, I think, a different experience. A lot of people say they like paper books more than they like digital books. You're not seeing this, listener, but Dave is nodding wide.
\n\nDAVE: Oh yeah. Oh yeah.
\n\nMIKE: And, you know, I think that having that multi-sensory engagement, even if that small of a marker has nothing to do, and it's probably bad for you, right, has nothing to do with the meeting itself, but there is some engagement. And also standing up...and this is something that I wish was more socially acceptable, is to move in meetings because your brain just works better when you're moving.
\n\nTAD: Well, I've had stand-up meetings that are literally we all stand up and walk to the corner of the room and all talk to each other, and then we go back and sit again, right?
\n\nEDDY: A stand-up meeting was a stand-up meeting [inaudible 34:36]
\n\nTAD: Yeah, like you literally stand up, and you literally move to somewhere not right there at your desk and have the meeting, and then you walk back. And you're just standing the whole time, right? Because I think if you do that, they tend to go a little faster because people don't want to stand around so much [laughs].
\n\nDAVE: You don't want to stand, yeah.
\n\nMIKE: Hence the name, right? If you force people to stand, they don't want to do it, so it's going to be a short meeting.
\n\nDAVE: The counter is true as well, right? You get people that are like, I don't want to do anything in this meeting. I just want to kick back and sit. So, they're the ones that are saying, “I don't want to do stand up. I want to sit down for stand up.” And it’s like, well, it's because you want to check all the way out. You don't want to just not stand. You want to just, like, you know what, fine, you guys do your thing; it's fine, right? So, when you have a stand-up that is three minutes long, all of a sudden, anybody can focus for that long, right?
\n\nTAD: So, I hypothesized earlier that meetings expand to fill the time. Does that tend to be true?
\n\nMIKE: Yes. Almost always [chuckles].
\n\nDAVE: If everyone in the room is reactive and passive, your goal is to pass the time of the meeting. So, you literally have nothing to do, and nobody...especially if you've got like a little bit of organizational pressure, nobody's going to have the psychological safety to go, “Hey, guys, can we just quit? Can we just leave? Can we just be done?” Because there's going to be one person who's like, “Well, but I have a topic, right?” Like, if no one's engaged or if your goal at that...Sorry, I'm an extrovert. I think by talking, and I just hit on this. Thank you, Tad. If you don't have a reason to be there, you're reactive and you're passive, your meeting objective is now to get through the meeting. And you have no objective standard other than the clock.
\n\nMIKE: But, on the flip side, if you have a goal and you've accomplished that goal, that changes things. And it may even be a metric. Going back, also, to Tad's point about having an effective meeting, you have those time boxes. And you measure the effectiveness of the meeting based on how well those time boxes are honored. It's not about an arbitrary box. It seems like the goal there is to effectively contain those decisions. Well, let me say it differently; it's not to contain, but rather to engage. And if you're meeting your purpose, then you're done with that timebox, and you're ready to move on.
\n\nI would say that compressing the time is generally to be considered a success. One metric you could use of effective meeting, and I've often seen this, if you get out early, it's a good meeting because it meant that you were on point. You reached your objective, and you stopped. Your goal is not to fill that space but to solve a problem.
\n\nEDDY: Or the individual who tends to prolong the meetings is not there [laughs].
\n\nDAVE: And the counterpoint is true as well, right? Goodhart's law is that if the metric becomes the goal, it ceases to be a good metric. There will be that same psychopath that wants to drag the meeting and control everybody's time. If you tell that person we want to cut people off at time, they will eagerly do this, not because they want to save people time, but because they like cutting people's toes off. Great.
\n\nAnd as soon as that happens, everyone else in the room will say, “I'm not getting into that timebox because we lose toes in there.” That's Goodhart’s law writ large. All of a sudden, nobody wants to participate in that metric because it's a terrible goal. But if you have another goal, then it's a great metric for measuring, did you achieve it?
\n\nMIKE: But you keep on touching on something here, Dave, which is that an actor not in good faith can...and, you know, sometimes maybe they are even in good faith. They are earnest and just really care about something, and they want to talk about that, nothing else, that a single actor can easily destroy a meeting, and that's hard. That is hard as a meeting host. If you host a meeting where there's somebody who is very interested in getting what they have to say out there, and they're not going to let anybody else stop that, it is a challenge. What can we do to address that problem? Because you get into that situation, it's going to be very hard to have an effective meeting, ever.
\n\nDAVE: Stop inviting them to meetings [laughs]?
\n\nTAD: Robert's Rules of Order.
\n\nDAVE: We had a similar rule to that. It's related to this. It's not a direct answer to that, but we had a rule that we use called ELMO. It stands for Enough, Let's Move On. And, basically, if you've made a point and somebody else makes a point back at you and then you make your same point again and they make their same point back, there's nothing else. We're done. We're done. Let's move on, right? You can weaponize ELMO. I've had somebody shout ELMO at me who very clearly just wanted to hurt me and wanted to just be a jerk. But other people would do it, and it's like oh yeah, I need to focus because I know I get distracted. I get excited.
\n\nMIKE: One thing that got mentioned earlier was having rules of discussion, rules of engagement in your meeting. And if everybody has engaged in the rules before the meeting and has agreed to those rules, then it's not the host who is causing the trouble. It is the rules, right? The rules are what's ending this. And it's really nice to be able to point to the rules and say, okay, well, we decided ahead of time that we're going to timebox this for 15 minutes. We've reached the end. We're going to table this and bring it back another time. Now, you can't blame the host for following the rules.
\n\nThe person who is disrupting agreed to those rules as terms of being in that meeting. So, they cannot, you know, it's not personal. You can't make it into a personal attack. They can ask to change the rules, but that's a group decision, and you have to get consensus. So, it seems we haven't talked very much about those rules of discussion, but they can help the host tremendously. And all of us are going host a meeting sometime, probably [chuckles] by giving control to the rules. And you think, well, no, I want to have control; no, you don't [laughs]. You want to be able to direct the conversation where you can, but you also want to be able to have that structure.
\n\nYou want to have a constitutional meeting where you have a structure that defines the engagement, and your role is to facilitate within that structure. And you can lean on the structure for that rule of law rather than having to invent the law as you go. You cease to become the king. You don't have to have that on your shoulders. King or queen.
\n\nDAVE: It helps when everyone in the room feels like the rules are there to help us get to the thing. Then it becomes, like, if somebody slams the door on your toes, you realize, oh, I'm sliding out of the box that I was supposed to stay in, and we all need this box. One of the most powerful things that happened to me...I did Toastmasters. It's been 20 years, but I loved it.
\n\nAnd I remember watching the president of our club speaking something, and the timekeeper said, “You're out of time.” And he stopped mid-sentence. You're allowed two words when you go over time, and those words are “Thank you.” And he stopped mid-sentence and said, “Thank you,” and he sat down. And I'm like, “Wait, what? You just stopped?” And he’s like, “Yep.” And everybody followed that example after that, and we got out on time every time after that. It was amazing. Again, not because we like chopping people's toes off but because we like the utility that the box gives us. What is the meaning of this?
\n\nMIKE: If people can be bought into the system, then, you know, it's a group effort. It's a tool that people are using to accomplish their goals.
\n\nDAVE: I could do a whole nother hour on allegiance to systems, versus victimization, versus yeah...we have 3 minutes left in our meeting today, so I'm not going to get into that.
\n\nMIKE: We've covered a lot of ground here. This isn't one of our longer episodes, but it has covered some key points repeatedly. This is one I think I may revisit because there's some things that I can reuse here. I've definitely learned some things from the panel here today. We've talked about the rules of engagement and getting everybody working with those, right, using those as a tool, employing those to make the meeting effective, the whole group.
\n\nWe've talked about engagement by giving people assignments, and we're there for a reason. Give people a purpose so that they are engaged, not to waste time but to actually provide utility. And if you can't give somebody an assignment, maybe they don't need to be there [laughs], and they can be excused. Or you need to change what your meeting is because you're not engaging people appropriately.
\n\nWe've talked about timeboxing, making sure you have an agenda and a mechanism in place for being able to end topics when you reach those timeboxes so that they can be discussed elsewhere or can stop.
\n\nWe've talked about some metrics for effective meetings. Ending early suggests that you are trying to solve problems. We've talked about having a discussion ahead of time, the pre-read being very important to enabling people to be able to come in and make an effective discussion and decision. I'm trying to make a summary here as we come to a landing. Anything that I missed?
\n\nDAVE: I don’t think [inaudible 44:15] good.
\n\nMIKE: We had a meeting with a purpose [chuckles]. We gave ourselves a timebox actually on this one, which we're going to hit in about two minutes, and we're going to nail it. We had advanced preparation by giving out the topic ahead of time enabling us to have a discussion. I think we nailed it. I think we did a good job here. Thank you. And until next time on the Acima Development Podcast.
","summary":"","date_published":"2024-12-11T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/0148c8e5-4546-447f-86b6-c25cdb09fae9.mp3","mime_type":"audio/mpeg","size_in_bytes":27044739,"duration_in_seconds":2696}]},{"id":"c93db8ea-574f-4996-b175-d7dfe0e0d171","title":"Episode 60: Business Logic Architecture","url":"https://acima-development.fireside.fm/60","content_text":"In this episode of the Acima Development Podcast, Mike kicks off the discussion with a story about his father’s woodworking journey, which leads him into a reflection on the craftsmanship seen in Michelangelo’s David. Drawing a parallel to software development, Mike explains how Uncle Bob’s philosophy about structuring code emphasizes that frameworks shouldn't dictate structure; rather, it should reflect the application’s purpose and business logic. The panel, comprising Eddy, Kyle, Ramses, and Will, dives into this idea by comparing software architecture to traditional architecture, stressing that applications should be designed to clearly convey their business domains rather than merely reflecting the framework they are built upon.\n\nThe conversation shifts to how different development roles approach structuring business logic. Will, primarily a mobile developer, shares his preference for keeping business logic close to the data layer, ensuring it remains adaptable and maintains integrity across varying platforms. Kyle adds a DevOps perspective, highlighting the value of configuration management and the necessity for disposability in infrastructure components, ensuring business logic stays modular and replicable without becoming burdensome or redundant. The team explores the tension between creating a reusable layer for business logic while managing caching, persistence, and the pitfalls of “fat controllers” in frameworks like Rails. Eddy brings up how MVC can sometimes obscure domain logic, advocating for clean architecture practices and encouraging separation of interface and business layers.\n\nFrom a security angle, Justin emphasizes the importance of validation before any business logic is processed, advocating for clear layers to handle inputs and outputs independently from core logic. The team also discusses how integration and unit testing benefit from this layered approach, allowing developers to isolate and test business logic without impacting UI or data layers. They conclude that a middle layer for business logic—distinct from the UI and data layers—is crucial for maintainable, secure, and efficient code, reflecting that, much like in traditional craftsmanship, thoughtful structuring and separation of concerns lead to better long-term results in software.\n\nTranscript:\n\n MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. I’ve got a great panel with me here today. I've got Eddy, Kyle, Ramses, and Will. And, as usual, I'd like to start off with a story that's not about software development [laughs] and tie it in. \n\nAnd I’ve mentioned my dad a couple of times in the podcast. I'm going to be again today. He's an interesting guy. Like, we all think our dads are interesting. Well, I think my dad is interesting, too [laughs]. Most of his career is building, building things, but he's also a tinkerer. He makes his own tools. So, he does woodworking, right? And he makes his own tools for woodworking, and woodworking ends up doing a lot of things. One of the things that woodworking led him into is, you know, making stuff, then he's done some sculpting.\n\nJust in the last month, my mom and dad traveled to Italy and Greece. They hadn't done a whole lot of traveling. Did it there and went and saw some of the sculptures in Europe. And my dad said when he saw Michelangelo's David, it made him cry [laughs]. Because he's done sculpting professionally, you know, he's been building things his whole life. When he saw the craftspersonship, right, that went into that, it was just overwhelming. And, you know, it really affected him, which is pretty cool [laughs]. I haven't had that reaction seeing, well, I've never been there, so I really can't say. But, you know, when you devote yourself to making stuff so much for a long time, it, you know, it really affects you when you see something that's done well. \n\nNow, we build software [laughs], and you don't see the structure very much. I heard an analogy made by Uncle Bob. Look him up. If you don't know what I'm talking about, he's a luminary in the software community. That's not his full name, but it's what he goes by. He’s one of the signers of the Agile Manifesto. He's a prominent guy. I heard a talk from him once, and he said that in software, we tend to structure our applications around the framework instead of structuring them around what they do, and that idea has really struck me. And he made the comparison to architecture. \n\nI'm going to start with this, going back to this statue of David. You know, if you're going to make a big marble statue, you are constrained by the chunk of marble you start with. If you don't follow that shape, you're going to have some edges, right, where it does not work. And it drives everything that comes afterwards. You know, everything has to work around the constraints of that stone. And somehow, when we build software, we sometimes don't think that way. If we're writing a Rails app, we think, okay, I've got models, views, controllers. Everything should look like the framework.\n\nAnd I'm glad we've got the panel we have here today because not all of us are, you know, we're coming from different kinds of frameworks, which is kind of cool. This idea, though, of structure coming from your framework rather than what your code is it's a big one because if you look at your code and say, okay, yeah, this is a Rails application. I've got models, views, and controllers. I have no idea what this application does. I have no idea what the business domains are. I don't know how to find anything [chuckles]. It's all just lumped in there together. \n\nI'm going to take that further and say that if that's all you see, then there's something probably horribly wrong. Because, in any large application, you've got business logic that has nothing to do with presenting out to the customer. It's probably running in background jobs. It's running...you're probably sending out emails to people. You are, you know, writing reports, whatever the case may be, although you shouldn't write a lot of reports in your app. That's a bad idea. Use an outside tool [laughs]. If you’re writing reports, you're doing it wrong. \n\nAnyway, but there's all these things other than just, you know, your web app, you know, you probably got a mobile app somewhere. You've got an API. You've got to talk to it, talk to that with. So, if all your business logic is structured around your display code, then you've got a serious problem because it's not reusable.\n\nGoing back to what Uncle Bob said, he used the example of not a sculpture but of architecture. He wasn't thinking about that marble you start with, and you get down to the sculpture. He was saying, well, if you look at a floor plan of a building, you know what that building is for. If you look at a school floor plan, you're going to look, and say, okay, here's the gym, here's the, you know, lunchroom, and here's all the classrooms. It's really obvious that it's functionally designed to match that. If you look at an office building and you see your cubicles, you know, and you see your meeting rooms, it's going to make sense. \n\nYou're not going to see every single building look exactly the same because we wouldn't do that because the building should follow the function. We have domains in our code. If you've got something that's, you know, a major component in your code that can make up a...if you've got blogging software, you're probably going to see something around leaving comments, right? And that's a major domain of your application. And if it doesn't look like that, then there's something wrong with how it's structured.\n\nThat idea of thinking about where your business logic goes, thinking about how your application is structured, I think, is a potent one. And that's our topic today. Where should you put your business logic? And we're going to talk about this in kind of a framework-agnostic way. Because I think these principles apply universally regardless of what framework we're working in. \n\nI'm wondering...so, we've got some...so, Will, you're not at Acima. I'm curious what your thoughts. I'm going to start there before we, you know, kind of talk about the Rails side or some of the in-house stuff. I'm also curious what you think, Kyle, and what your thoughts are because you’re looking at this from a DevOps perspective. Where should your business logic go? How do you structure things so that you end up with your business domain and it’s recognizable? And you don't just look like, oh, this is a React app, and that's all it is. I have no idea what else it does. \n\nWILL: I’d say one thing I am doing a lot of mobile development, you know, that's probably 80% of my work these days. And one thing about mobile app development is you can't roll it out with the speed that you can roll out a web app, right? I can have a web app. I could roll the whole server, I don't know, even a big server I can do, you know, in under an hour, you know, little stuff. You can do it in minutes, if not seconds.\n\nSo, one of the things that you really need to be mindful of as a sort of, like, a mobile app developer, is pushing business logic as close to the web server as you possibly can. Sometimes you got to do...I'll do in terms of the data, like, what am I going to render and when, where, why, and how? I always want to push that back onto the server because I can fix it. I can change it. I can get different stuff going. And so, you know, for a mobile app and for a web app, too, I really like to keep that view layer pretty, you know, I mean, in terms of logic, I want to do layout. And I want to do a last line of defense sort of, you know, sanity checking, right?\n\nBecause if something, if for whatever reason, I'm the last line of defense to keep something from being screwed up on the screen, that's what you want, right? That's your goal. That's what you want. But, you know, it's hard to hold that line because you're also sort of managing your L3, 4, 5, like, your last layer of caching, so there's performance considerations there. But, I mean, in terms of that, like, that's as far as I want to go. I want, like, the logic of what I'm being presented to be as far down as possible. \n\nAnd, I mean, in terms of, you know, business logic, you know, once you start crossing over into web land or server land, I should say, you know, I guess what I'd say is I want to keep the view of what I'm thinking about in terms of logic as small as I possibly can. And maybe I think about it more from the other side because I pick up a lot of, you know, legacy, you know, projects. And so, when I'm trying to make sense of a legacy project, where do I sort of start wrapping my head around it? And I almost always go down to the database schema, like, as low as I possibly can in terms of the data, right? So, I'm looking at database schema. I'm looking at the downstream APIs that are feeding data up to me. It's like, that's how I start to untangle, you know, the logic around some other application.\n\nSo, for me, I want to keep it, I think, in general, I want to keep business logic as low as I can get it without duplication. It's like, how do you know, oh, I went too low, you know? Is when I start repeating myself, and I have different subsystems that are doing the same job over and over again. So, I think, you know, broad philosophy-wise. That's the best I've got for you. \n\nMIKE: So, you've got a layer of business logic that lives close to the data but is not right there. It's a little bit above, so you don't have the same thing replicated everywhere or, you know, in all of your database table interaction probably using ORM. It's not duplicated in all those places. It's a layer above. So, it's reusable as widely as possible. \n\nWILL: Exactly. Yeah. Yeah. Push it down. Push it down as far as you could push it until you start to repeat yourself, you start duplicating the same logic, the same functions, the same functional units over and over and over. And then, you know, and then you start bundling them into a module so that you can reuse it. And then, you know, you just kind of continue on as you are. \n\nMIKE: I like that because there's a principle there because it applies both on, you know, you're in your mobile app. You're pushing it as close to the web app as possible which is, the web app is your data layer there, right, that, you know, you're pushing down to there. So, you've got this layer above your data layer for that site that has got your business logic. And then, on the web layer, you've got a similar structure. You want to push down as far as possible, as close to the data layer as you can, so that it's reusable. That sounds like something that can be replicated. Makes some sense. \n\nSo, Kyle, I said I'd ask you as well. So, I'm deliberately going through the non-web app route first before we get into the web app. So, I'm curious what your thoughts are here from the DevOps perspective. Because you write code. You write a lot of code, I'm sure, or at least work with configuration as, you know, as if it was code. What are your thoughts about business logic from a DevOps perspective and where that should go? \n\nKYLE: I'm trying to think how this would relate in the DevOps world. And what's coming to mind is, specifically here at Acima, we deal with a lot of languages, just to start with. And it's kind of impossible for a small DevOps team to learn every language that all the engineers at Acima are dealing with. And just being able to go in and visualize to see, you know, what is this code doing is very helpful.\n\nSo, depending on that structure, which each language is going to have their nuances, if it's going to be in Python versus Ruby, you're going to visualize what's being presented to you in very competing ways just because of the way those languages decided to do things. But kind of like Will is pointing out, no matter what, a language generally has a data schema of some sort. And so, we can kind of see, you know, how is that logic put into a database? You know, how's that being stored, and where does that live? \n\nAnd then, the other thing I was thinking about is where we offload the business logic. Where is this offloaded to that's, you know, can it be replicated? Is this in Redis, RDS, those types of tools? You know, does this get put into a data lake where it then gets replicated across? And kind of trying to think about that. \n\nAnd then, the other thing I was thinking about, too, is at what point do you start making or putting your business logic into executable functions? And I might mean, you know, Lambdas or the like. When is your code, your app code, just your app, and then the business logic itself gets offloaded onto something else that's kind of executing it? Not necessarily something that is done everywhere. \n\nI'm just saying, like, when you offload that work where it's constantly repeatable, constantly something that's a small unit that can be thrown away if need be and then rebuilt, and then, like, you're not, you know, necessarily relying on one framework or another, but you're relying on a small piece of code that you can just kind of get rid of and recreate if need be. Those are my initial thoughts on the subject. \n\nMIKE: Let me dig a little bit more. I know [inaudible 14:28] he uses the analogy a lot of wanting to treat virtual servers, pods, you know, containers like cattle instead of pets. \n\nKYLE: Yes.\n\nMIKE: [laughs] And it's a vivid image there [laughs], you know, they're disposable, right? This is something that you're not going to have any qualms with getting rid of. \n\nKYLE: Yes.\n\nMIKE: And spinning back up. And so, I'm thinking you don't want to have little bespoke components that you have to rebuild every time for every new service that comes up. But rather you want to have a lot of reusable [inaudible 15:07] in your infrastructure config and building, rather than having this fragile thing where you have to build every one separately. \n\nSo, I would ask, you know, how do you go about doing that? Because that's logic in building something. You have reusable components for building the infrastructure out. How do you avoid that reuse or avoid the lack of reuse, right? How do you avoid the situation where you end up having to build everything alone? What does that look like in terms of how you structure what you set up? \n\nKYLE: I'm thinking just everything is config. Everything is config management in that case, especially in the orchestration world. So, you're saving a copy in one place and able to replicate it in several others. And you're taking out those pieces that you aren't relying on that you're able to replicate. So, the server itself, you can replicate that as many times as you want. But the data set, which will probably be the business logic here, has to go into a database that doesn't necessarily...it can have replicas, but you're referencing one data set. And so, everything is kind of going down to that one pipeline. \n\nAnd then, you know, depending on what these other services that you are actually utilizing, would depend on whether or not, you know, are you putting anything? Are you storing something in Redis per se? And is that something that can be thrown away? Because if we're not putting business logic in Redis, basically, if we can treat Redis as a cattle, now we can scale Redis out, and we get a lot more speed. However, if we're putting something that's a pet into Redis, well, now we've got to be careful with how we scale out Redis and how we worry about the HA availability of that. So, does that answer your question, what I'm going with?\n\nMIKE: I think it's an interesting answer. You said a couple of things. You said that we need to structure our applications whenever possible to not have special needs. That is, we need to have data, a single source of truth but try to make everything else disposable. And if you're having a caching layer, try to make that disposable. Like, everything disposable if you can, and only have a single source of truth and [laughs] one and only and not any others because that's costly. That's an interesting idea in that it kind of reflects a little bit of what Will was saying that if you go and understand what the data looks like, it can help drive what comes above it.\n\nWILL: Well, but you said...you made an interesting assumption, right? And as I was sort of, like, thinking about mobile apps, right? So, what I'm doing now is effectively just a glorified web app. I have my single source of truth, right, which is a server, and I'm presenting the data, you know, I'm giving data back. I'm sending it to the data...I'm sending it back and forth. \n\nBut that isn't actually how it came up. It came up doing, you know, like, a fitness app. So, specifically, I was doing a line of fitness apps, and they would generate data. They would generate speed data, location data, like, calorie burn data, heart rate data. All this data was like you had a mobile app, which was a lot like cattle in that I have a very capable, fully-featured computer that is reading data and processing it. It's doing its own thing. It's its own process that can do a lot of stuff, right? Easily comparable to one of many server threads generating data. \n\nBut it's also, like, it can do anything. It's just like, oh, I ran under a bridge. We don't have any cell phone service now. I ran out of battery, so this thing's done. The system's going down right now. I ran out of space. This thing just crashed. Oh, you got a virus, and it took down your whole phone. Apple, for whatever reason, didn't like your process anymore and decided to squash it. Anything can happen to these things. They could stop any time at all, for any reason. You know, like, oh, I put it on airplane mode. Oh, I was uploading this big data set, hmm, not no more. We're done now.\n\nAnd then, you have to sort of catch that, and recover from it, and process it, and get the data back up. It's like, oh, I was sending that thing, but it didn't work out. Oh, and then then I ran out of space. So, I have to delete something. I’m like, they just deleted the whole app, and I had to recreate myself from whatever fragments of state I have available to me. The single source of truth, that's complicated, you know.\n\nAnd if you're talking about your processes like cattle and not pets, it’s like, oh, well, that job? That job just failed, too big. I remember you know, scaling days at Acima where it was just like, sorry, guys. We made too much money today, and we literally can't count it all. And so, we uploaded these giant CSV files to the bank, like, all of our takings for the day. And I'm like, it will crash [laughs]. It will crash. \n\nKyle, you and I, like, I remember you and I were chasing memory leaks in this, you know, giant CSV bank transaction processing thing because we made too much money. We made too much money, you know. And then, we were sort of chasing it down. And so, you have to have sort of like a fault tolerance and checkpointing and, you know, callback steps where it's like, \"Okay, did you get that?\" \"Yes, I got it.\" \"Okay. I'm going to mark this job as finished,\" you know, and then, oh, is the job idempotent? Can I run the job twice? Oh, maybe not. You don't want to double charge. There's where the pigs get fat, hogs get slaughtered. I'm not trying to double my winnings. That would be bad. And so, when there isn't a single source of truth, that's when things start to get interesting. \n\nMIKE: So, you’re saying that the structure of things, because we're talking about structure here, becomes challenging when your data is, well, that source of truth, you know, your data is not very reliable, and, well, anything is not reliable. That's interesting. You think about caching, and caching is a mess. Nobody wants to do caching. It's horrible. And it's also the only answer for a whole bunch of problems because of that same problem. There's so many ways, so many ways.\n\nYou can't get all the instructions to your processor. You can't get them in there fast enough. So, there is caching in there to get that push down, and you can't upload transactions fast enough sometimes. You're getting a stream of data from an app on the other side. You know, even within the company, right? They're sending you data as things are going on. And you could rely on them and send stuff, you know, make a request, like, a REST request every time. And now you've got a single point of failure, and every time they deploy, you go down, too. So, you've got to have that caching layer. You've got to have redundant data, which affects your structure a lot. \n\nWILL: Dump it on the queue. You know what I mean? Dump it on your...I misremember the queue flavor, you know, the AWS queue flavor. The SN –\n\nMIKE: SNS is the notification, and then you subscribe to it with SQS. \n\nWILL: SQS, yeah. SQS or Kafka. Then what happens if you blow out your queue? Uh-oh. Some of these transactions they need to go out and persist to the database. But they don't just, you know, some of them you just persist it out to the database, no problem. But, again, we're talking about people getting paid. You want to commit that atomically. That goes in one time and only one time. And it only commits when all the [inaudible 23:38] are dotted, and ts are crossed, right? And that takes time, especially if you have multiple data centers. \n\nAgain, you don't want to just commit it to one database. You want to make sure everybody got it, and everybody knows they got it. And, like, if you get it, okay. If you get it, okay. And I'm waiting on you [laughter]. Uh-oh, this guy, he's not coming back. So, then I'm dumping my transaction. Transaction is over now. Oh, well, what do we do about that? Now I'm going into the naughty box, where we're going to have to come back to that. Oh, I'm going to retry. How many times do I retry, right? Oh, I've retried it three times. Like, okay, now I'm sending emails. Now pagers are going off, you know [laughter].\n\nKYLE: Well, and it's how do you know when to retry, too? Because you're in the middle of processing a job, and you get a SIGTERM. Okay. Well, did your application handle that gracefully? Is it done? Did it finish? Do we retry now? There's so many cases there. \n\nWILL: Do we all retry at the same time, right? Like, oh, I just lost a whole...I'm kind of falling behind. And so, then I have a big batch of jobs. Like, I was already not quite doing so good, and then I have a big batch of jobs. They all terminate at the same time. And now I'm just like, [inaudible 25:07] my server because all my retries hid in this giant tsunami, and now we've got pagers going off [laughs] once again. \n\nMIKE: And that's a general, yeah, and that's not the only place that happens, you know, cache stampedes where you [chuckles] clear your cache, you know, it didn't come through, so I'm just going to wipe it. And a specific problem, I had a different company. We had a content management system, and we were getting a lot of requests, like, a lot, a lot of requests on the order of about a billion a month or something, you know, so a lot of requests coming in.\n\nAnd, yeah, if you're trying to rebuild, the content for every one of those, oh, you will just die. And [chuckles] so, you have to have layer after layer of guarantees that, you know, when a request comes in, oh, wait, this content is stale. Well, I'm going to go build that in the background. I'm not going to serve you the stale content. And then, when that background content is ready, we're going to stick it in place so that the next person who comes in gets fresh content. But I can't fill up my caches; got finite space. So, I canceled everything forever. And [chuckles] it's messy. And if you ever just take the cache and expect that to rebuild, bad things happen.\n\nKYLE: Well, and it's how much cache do you have, right? Because then it's do you go with a small amount of cache? And, okay, that helps, but a larger amount of cache would be better. But if we lose that large cache, I mean, we're in for even more of a world of hurt. \n\nMIKE: [laughs] It's interesting we're talking so much about caching and messaging, you know, we're talking about structure and business logic. But we're saying, well, data is messy. And so, inevitably, a lot of what we build is going to be around dealing with imperfect persistence and, you know, imperfect connections, all of the weaknesses in the system because things are going to break. What about just your straight-up reusable business logic? Say you've got code that's going to take an input from your user and split it up into its parts and save it to the database.\n\nEddy and Ramses, I deliberately went through Will and Kyle first [laughs]. So, I'm going to come up to the web developers and Rails developers specifically. Rails gives you models, views, and controllers. Should you stick your business logic in one of those places? \n\nEDDY: Just dump everything into your models and then just call it a day [laughs]. You can't go wrong with that. Or also, put everything in your controllers, too, just make them fat, you know, put everything there. \n\nNo [laughs], I think when you started mentioning domain business logic, I started to really write some notes down. And I think what it really comes down to is how large your project is, right? If it's like a simple blog, you know, things like that, I think you're inherently going to have your models and views and everything tightly coupled. And I think that's fine, you know, if it's something that doesn't have much strain in your service or whatever.\n\nBut think in terms, like, merchant portal. DHH, I think, is what we call it. It might be still sufficient, but you need to optimize it in such a way so that you're not putting much constraint in your project. So, I think one way to probably think about that is probably just extracting domain objects, things like that. You may want to mock or stub out tests, you know, just so that things are really simple to follow. And you're not waiting for builds and stuff. But still, you're going to run inherently into a problem where your controllers are really coupled with models and stuff. \n\nAnd [chuckles] so, I think what we really want to consider is extracting data, right? And I ran into this issue. I ran into this terminology a while back called fat controllers, right? Has anyone heard of that term before? \n\nMIKE: [inaudible 29:45] as bad thing [laughs]. \n\nEDDY: Yeah, it's kind of like in dumping ground, right, where you do a bunch of business logic controllers, but that's not really the design for it in MVC, right? Not to mention, I'm a huge subscriber to Singleton, so, like, single responsibility. I think that's really important to also implement into your service. Specifically, if you put stuff in your model, for example, the models, I believe, inherit from ActiveRecord. And they're going to be responsible for a bunch of domain logic and persistence. And I think that's bad, right? So, we want to avoid putting domain or, specifically, business logics into models [inaudible 30:35] controllers, right? Because you're asking for a really bad time. So, something to consider, I think, maybe PORO might be a good alternative, right?\n\nMIKE: So, what you're saying is, don't put it quite in the data layer but have a layer right above that, where you have reusable components as close to your data layer but not quite there. Notice the pattern, which is what Will said should happen in both the mobile app and the web app is that you'd have a layer of business logics. Now, you had talked about having a plain Ruby object. And the specific kind of object really doesn't matter so much. So, you said, well, your business logic should be in its own reusable layer, close to but not quite the same thing as your data layer. \n\nEDDY: Exactly, yep. You mentioned Uncle Bob's Clean Architecture [laughs], so I looked it up really quick. And something that really caught my eye was something...and I quote, “Software dependency should all point towards higher level business rules. The database, web, and other external interfaces does become the lowest level of implementation details.” And I think that's really key to what we're talking about, and I think it's kind of funny because Rails sort of doesn't follow this design, like, we usually think of Rails as, like, database design is probably considered first. And then, you have ActiveRecord models are created by one by one mappings [laughs]. And I think that sort of happens inevitably when you have a CRUD app, right?\n\nMIKE: Yeah, so there's some pushback from him to rethink about that. Think about what your application looks like, possibly independently of what your database structure looks like, because they should not exactly align. You know, maybe you have a concept that doesn't exactly map to what you have in your database but makes sense as a concept. You can build around it, but it isn't necessarily a thing that maps to an exact table. \n\nSo, we've talked to, you know, somebody doing mobile development, somebody doing DevOps, somebody doing web development. And joining us a little late today, we've got Justin. Thanks for joining us, Justin [laughs]. \n\nJUSTIN: Better late than never. \n\nMIKE: And I'm curious, so we've been talking about how we should structure an application so that the structure of the application reflects its purpose. And you're doing security, and I'm interested in your perspective on that. And I'm bouncing over you, Ramses, because Eddy spoke up first, but I'm still interested in your opinion if you've got one. I’m going to jump over to Justin because we're getting a wide variety of perspectives here. So, from a security’s perspective, what are your thoughts about the structure of applications? Specifically, where should business logic go and why? \n\nJUSTIN: So, that's an interesting question because I have never thought of that from a security perspective. Is there a best place for it from a security perspective? If I'm looking at it the way that something is structured, I'm always interested in validating all the input, validating, you know, doing all the checks before any business logic actually gets executed. \n\nSo, you need to be able to do the authentication, do the authorization, you know, validate the inputs. And that's basically it, actually [laughs]. But you got to do those things first, and then you can do business logic. And then, you can, you know, then it gets stored away, you know, whatever happens, happens, the actions, whether it's storing it in a database or calling another third party, or anything like that.\n\nAnother thing that's interesting is the inputs and outputs are always interesting, to me, from a security perspective, because, you know, validate the inputs, validate the outputs. And do that for every layer or third party that you're doing, and that makes it a secure environment. I think there are several models that that could fit within, you know, classic MVC, or it should fit within every model, really. But those are my main concerns there from that point of view. \n\nMIKE: Well, you said something really interesting there. You wanted to have a layer that handles your input, and that's not your business logic layer. \n\nJUSTIN: Yeah, you got to validate that before it hits the business logic because if you have unvalidated data going through your business, it could hit all the branches, and it may be doing something that you may not want it to.\n\nMIKE: So, from a security perspective, you're advocating for a structure where you have a well-defined layer that does input handling. You talked about Rails, you know, and you mentioned MVC with Rails MVC frameworks. We'll talk about that because we've done a lot with that. Your controller layer is positioned to do that input validation, and I would argue is badly, horribly positioned to do the business logic because it's designed to have that request come in, do the input validation, and, hey, are you logged in [chuckles]? Are you giving me valid data? Are you giving me something huge that I shouldn't be doing anything with? You know, whatever the case is that they're handing off. It's designed to do that. \n\nBut then, if it's doing that, thinking about it, well, that's a separate concern, right? That's a different thing. So, you should be handing it off to do something. So, listeners are not seeing visualization. I'm talking with my hands [laughs]. You've got a layer that speaks to the outside world and handles that. But then the business logic you're pushing back down to a deeper layer that sits in between that interface layer and the database. And this is interesting because we've got a recurring theme again [laughs].\n\nSo, Will talked about, well, I'm going to push it as close to the data layer as I can, but not so far that it starts to repeat itself, separating it from the UI concerns, right? Separating from those interface concerns. And he said the same thing about the web application. Well, you're saying the same thing from a security perspective.\n\nAnd Eddy kind of said similar things from a usability perspective for a developer happiness perspective [laughter]. You don't want to have everything in a place that's not reusable. You want to have it in a reusable place. And all of these are kind of pointing to the same idea that you have this interface layer that handles those interface things. But that's a separate concern from your business logic. Your business logic should go somewhere else. It should go in this deeper layer that's not your data layer but is closer to it. \n\nWILL: My original thesis, I still believe in strong, right? Which is that it should go, you know, as deep, as close to the data layer as you can get before you have duplication. So, form validation on the UI side actually sucks. It totally sucks from a software architecture thing because there's all kinds of stuff. You're, like, half-ass verifying, and you're half-ass validating, where it's like, I could check maybe a credit card CVC, or, you know, did you even fill this form in? I could do that stuff.\n\nBut then I got to do all the other stuff on the data layer, right? So, the credit card form. Like, I got to check this card. Is this card actually...is it valid? Is it even on, right? So, I got to do all this, you know, messy stuff. Like, it doesn't get me out of everything. I'd have to write it twice. And it's actually a giant pain in the ass to revalidate the thing just to be like, I went all the way down to, you know, calling the bank, you know, virtually. And the bank says, “Yo, no fricking way,” right? Then I have to parse that data and then update the UIs. But you want to do it because it's better UX, I mean, it's better user experience, right? You want to hit it as fast as you can. \n\nBut in terms of software architecture, awful, just terrible, terrible. Like, from my perspective, for my benefit only, do it all on the server side, all of it on the server. Because I got to do it that way anyway. So, like, why do it twice? Well, because it's not fun. So, anyway, I mean, it's just, you know, we sacrifice; we bleed --\n\nEDDY: I would counter-argue that you do simple validations on the client side, and then do all of your logic validation in your backend; just saying. But I'm also –-\n\nJUSTIN: But that's what he's saying, right?\n\nWILL: Yeah.\n\nEDDY: Oh, gotcha. I thought you said it in reverse. Okay, never mind. Never mind.\n\nWILL: Yeah, well, yeah, you have to do it twice, right? I'm saying that it sucks to have to do it on the frontend, and then you have to do it all over on the backend. Because I don't trust anything coming from the user, right? And so, purely for my benefit, do it all on the backend, but it's just not good UX, right? Because you've got to wait for the round trip, and then the whole thing, and it's just, you know, it's a giant pain that nobody likes, you know, as a consumer. \n\nMIKE: So, you just have to kind of forget about the fact that there's another layer that's doing all this somewhere else, and just live in your own layer [laughs]. The other layers don't exist. Then, you don't have to stress about it because you didn't write the validation again. Somebody else did. Except you probably did because you're probably doing both [laughs]. \n\nWILL: Probably, you're doing both. \n\nMIKE: [laughs]\n\nWILL: And, at the very least, you have to come back, and you have to parse out the, you know, this is the error, and communicate that, you know, even if it doesn't necessarily fit in your form anymore. Anyway [inaudible [40:55]\n\nKYLE: I was thinking, when Justin was talking, something that we haven't necessarily hit on is actually the testing side of this. And it is one of those things where if you get your business logic too close to your UI level, or if you get it too close to your data level, your matrix on your testing scenarios gets a lot higher, and it gets a lot harder to do. And so, if you're able to isolate your business logic, you can mock and stub a lot of what you need in order to test just your business logic and validate that. And that would be helpful, you know, regardless of whether or not it's QA or security, I would imagine. But that just kind of occurred to me. If we treat it as that separate layer, then we can just focus on that, and curate that, and then curate the controllers and stuff that we're using independently.\n\nEDDY: You know, in the past, I probably would have agreed with you cold-heartedly. But I, more often than not, have wished I had integration testing because it turned out I didn't truly understand, you know, what I was actually touching. So, there is a layer to both. \n\nKYLE: Well...yes.\n\nMIKE: They can both be true, though. They can both be true. You can have integration tests that do full end-to-end. \n\nKYLE: Yes. \n\nMIKE: And they take a hundred times as long. And then, you have your unit tests that don't have to touch the data layer and actually go fast. They're separate concerns that are both important. And if you intermingle those, you'll get in trouble because if you try to do all your tests with integration tests, yeah, they'll never finish, ever [laughter]. And –-\n\nEDDY: Unit tests are fine. You better be damn sure you know all of your branches. Like, that's the only thing. And it's bit us more than once, you know, at Acima [laughs]. And so, all I'm saying is past Eddy would have said, \"No, dude, mock, stub, everything. It's fine. You're good.\" But if you're not actually, like, making calls, you have to be 100% sure, you know, like, you understand how that works, what the response is, everything. \n\nMIKE: So, you know, I think coming back to the theme we're coalescing around here, from a security perspective, you want to have this middle layer that's had stuff validated before it gets there, right? From a testing perspective, you want to have a business layer that's able to be tested independently that's not all entangled with your data layers. Your test runs way slower [laughs]. And I wasn't kidding with 100x. That's probably actually low [chuckles]. It is way slower to have tests that have to go through [inaudible 43:38], and then they're fragile.\n\nAnd from a code usability perspective, you don't want to have everything. It all pushes towards...and then, going back to your block of marble, your beautiful block of marble, it gives you some constraints. You've got to have a layer in the middle. You've got to have a layer in the middle. And it's kind of inescapable that that business layer should be somewhere in the middle and not in your interface layer and not in your data layer, but in between. It's important. \n\nJUSTIN: I hate to bring this up at the end of the podcast, but I'm just wondering, have anyone had experience with any of the cases where they store the business logic in the database as data and then they load it into the middle business layer that way? And if it's stored in data in the database, you can do various things with it. But that dream is always more complicated to implement than people would imagine.\n\nMIKE: I talked to somebody who worked for a company that spent a couple of years building this beautiful system that did that until they went bankrupt because it took so long to build it they never made a penny [laughter]. \n\nJUSTIN: So, I worked at a place that tried to do that, and it was painful for everyone involved. But I'm just wondering if other people have run into a success story because that's the ideal, right, is you just define it with words in a database, and there you go. \n\nWILL: I think in terms of the program logic and stuff like that, eh, I think what you can do is sort of...you can have metadata. And one of the things that I've done is I've had sort of metadata around a record, which could be, you know, fairly sophisticated, I mean, really. Like, I'm trying to think if I could characterize this easily. \n\nSo, I'll give you an example, right? So, I used to work on this series of fitness workout apps, right? So, everything was modeled as, you know, exercise. And, you know, it's like, okay, we're going to do chest exercise. We're going to do 20 reps, right? And it would coach you through that in a different way than it would be like, oh, we're going to do 20 minutes on the StairMaster, right, or something like that. \n\nAnd so, like, the way it would communicate to you, the way it would log data, stuff like that, you could think of it like a style sheet, like a CSS style sheet. It would interpret things in this way or that way. It would do this thing in this way or that way. And so, it was metadata that did affect the way things are processed, but it wasn't really actual code. I think if you're writing actual code, I mean, because I've seen, you know, kind of PHP-type backends, where they're doing, you know, kind of weird stuff like that. Like, we have databases in databases in databases, you know, where everything is kind of Siamese twinned together. \n\nAnd I find that stuff pretty...it's hard to work with. It's hard to think about. Sometimes there are sort of technical reasons, performance reasons, or sort of generality reasons that you would do something like that. But generally speaking, it's more of a means to an end to that goal, you know. I know if you go and you open up Core Data, which is, like, Apple's native mobile data layer, right? It's their version of, you know, SQL, or something like that, right? It shifts with all the iPhones. It's a SQLite database, and every row is the same, right? Every row contains all of the columns for all of the rows, right? And it'll populate, you know, these set of columns just based on the data type that it is, and that's just how they did it. \n\nAnd I don't know the internal details around the technical basis for it, but I know some very smart people got paid a lot of money to write a hot, you know, SQLite interpreter for iOS. And I have every reason to believe they had good reasons for choosing what they chose. But if you ever look at it in a SQLite editor, it is just a mess [laughs], you know. \n\nAnd so, I don't know, I try to keep it as dumb and as simple and as easy to read as I can, unless I can't, and then I do what I got to do. \n\nEDDY: Well, I'd like to see that sometime. \n\nWILL: No, you don't [laughter] [inaudible 48:34] \n\nEDDY: Hey, just to be clear, I don't want to write it. I don't want to contribute to it, but I'd like to see it. It seems a bunch of spaghetti. \n\nWILL: Well, I mean, it's exactly what you think. So, if you have, say, think of your random database schema, right? So, you have 10 different data types, right? Every row contains the columns for every data type and some metadata that says, \"Oh, this is a product,\" right? So, it's going to have these columns in it, and they're going to be populated. Or, oh, it's a special sale, and it'll have these, you know, things. It's just a hash. But, I mean, you know, hey, whatever, man. That's the gig. \n\nAnd they wrap it up in an only mildly hostile RM, like, you know, APIs, so that you don't have to know about that kind of stuff unless you really, really, really, hate, you know, yourself and what you were going to think about doing that day. Or, and this is what happened to me, something bad happened, and you need to figure out how to undo what you just did. Nobody --\n\nJUSTIN: Hopefully, you can roll back that database update. \n\nWILL: Exactly, exactly. Rolling back a database update that you screwed up in SQLite is...let's just say anybody who knows how to do that had a real bad day [laughter].\n\nKYLE: [inaudible 49:59]\n\nWILL: All right, well, I don't have anything to add. Should we wrap it up? \n\nEDDY: Awesome. Oh yeah. This was a great conversation, like always. Super good. You guys are awesome. Thanks everyone for joining. \n\nWILL: Thank you, gentlemen. Y'all have [inaudible 50:16]\n\nEDDY: Thank you. Another great session of the Acima podcast. Bye, everyone.","content_html":"In this episode of the Acima Development Podcast, Mike kicks off the discussion with a story about his father’s woodworking journey, which leads him into a reflection on the craftsmanship seen in Michelangelo’s David. Drawing a parallel to software development, Mike explains how Uncle Bob’s philosophy about structuring code emphasizes that frameworks shouldn't dictate structure; rather, it should reflect the application’s purpose and business logic. The panel, comprising Eddy, Kyle, Ramses, and Will, dives into this idea by comparing software architecture to traditional architecture, stressing that applications should be designed to clearly convey their business domains rather than merely reflecting the framework they are built upon.
\n\nThe conversation shifts to how different development roles approach structuring business logic. Will, primarily a mobile developer, shares his preference for keeping business logic close to the data layer, ensuring it remains adaptable and maintains integrity across varying platforms. Kyle adds a DevOps perspective, highlighting the value of configuration management and the necessity for disposability in infrastructure components, ensuring business logic stays modular and replicable without becoming burdensome or redundant. The team explores the tension between creating a reusable layer for business logic while managing caching, persistence, and the pitfalls of “fat controllers” in frameworks like Rails. Eddy brings up how MVC can sometimes obscure domain logic, advocating for clean architecture practices and encouraging separation of interface and business layers.
\n\nFrom a security angle, Justin emphasizes the importance of validation before any business logic is processed, advocating for clear layers to handle inputs and outputs independently from core logic. The team also discusses how integration and unit testing benefit from this layered approach, allowing developers to isolate and test business logic without impacting UI or data layers. They conclude that a middle layer for business logic—distinct from the UI and data layers—is crucial for maintainable, secure, and efficient code, reflecting that, much like in traditional craftsmanship, thoughtful structuring and separation of concerns lead to better long-term results in software.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. I’ve got a great panel with me here today. I've got Eddy, Kyle, Ramses, and Will. And, as usual, I'd like to start off with a story that's not about software development [laughs] and tie it in.
\n\nAnd I’ve mentioned my dad a couple of times in the podcast. I'm going to be again today. He's an interesting guy. Like, we all think our dads are interesting. Well, I think my dad is interesting, too [laughs]. Most of his career is building, building things, but he's also a tinkerer. He makes his own tools. So, he does woodworking, right? And he makes his own tools for woodworking, and woodworking ends up doing a lot of things. One of the things that woodworking led him into is, you know, making stuff, then he's done some sculpting.
\n\nJust in the last month, my mom and dad traveled to Italy and Greece. They hadn't done a whole lot of traveling. Did it there and went and saw some of the sculptures in Europe. And my dad said when he saw Michelangelo's David, it made him cry [laughs]. Because he's done sculpting professionally, you know, he's been building things his whole life. When he saw the craftspersonship, right, that went into that, it was just overwhelming. And, you know, it really affected him, which is pretty cool [laughs]. I haven't had that reaction seeing, well, I've never been there, so I really can't say. But, you know, when you devote yourself to making stuff so much for a long time, it, you know, it really affects you when you see something that's done well.
\n\nNow, we build software [laughs], and you don't see the structure very much. I heard an analogy made by Uncle Bob. Look him up. If you don't know what I'm talking about, he's a luminary in the software community. That's not his full name, but it's what he goes by. He’s one of the signers of the Agile Manifesto. He's a prominent guy. I heard a talk from him once, and he said that in software, we tend to structure our applications around the framework instead of structuring them around what they do, and that idea has really struck me. And he made the comparison to architecture.
\n\nI'm going to start with this, going back to this statue of David. You know, if you're going to make a big marble statue, you are constrained by the chunk of marble you start with. If you don't follow that shape, you're going to have some edges, right, where it does not work. And it drives everything that comes afterwards. You know, everything has to work around the constraints of that stone. And somehow, when we build software, we sometimes don't think that way. If we're writing a Rails app, we think, okay, I've got models, views, controllers. Everything should look like the framework.
\n\nAnd I'm glad we've got the panel we have here today because not all of us are, you know, we're coming from different kinds of frameworks, which is kind of cool. This idea, though, of structure coming from your framework rather than what your code is it's a big one because if you look at your code and say, okay, yeah, this is a Rails application. I've got models, views, and controllers. I have no idea what this application does. I have no idea what the business domains are. I don't know how to find anything [chuckles]. It's all just lumped in there together.
\n\nI'm going to take that further and say that if that's all you see, then there's something probably horribly wrong. Because, in any large application, you've got business logic that has nothing to do with presenting out to the customer. It's probably running in background jobs. It's running...you're probably sending out emails to people. You are, you know, writing reports, whatever the case may be, although you shouldn't write a lot of reports in your app. That's a bad idea. Use an outside tool [laughs]. If you’re writing reports, you're doing it wrong.
\n\nAnyway, but there's all these things other than just, you know, your web app, you know, you probably got a mobile app somewhere. You've got an API. You've got to talk to it, talk to that with. So, if all your business logic is structured around your display code, then you've got a serious problem because it's not reusable.
\n\nGoing back to what Uncle Bob said, he used the example of not a sculpture but of architecture. He wasn't thinking about that marble you start with, and you get down to the sculpture. He was saying, well, if you look at a floor plan of a building, you know what that building is for. If you look at a school floor plan, you're going to look, and say, okay, here's the gym, here's the, you know, lunchroom, and here's all the classrooms. It's really obvious that it's functionally designed to match that. If you look at an office building and you see your cubicles, you know, and you see your meeting rooms, it's going to make sense.
\n\nYou're not going to see every single building look exactly the same because we wouldn't do that because the building should follow the function. We have domains in our code. If you've got something that's, you know, a major component in your code that can make up a...if you've got blogging software, you're probably going to see something around leaving comments, right? And that's a major domain of your application. And if it doesn't look like that, then there's something wrong with how it's structured.
\n\nThat idea of thinking about where your business logic goes, thinking about how your application is structured, I think, is a potent one. And that's our topic today. Where should you put your business logic? And we're going to talk about this in kind of a framework-agnostic way. Because I think these principles apply universally regardless of what framework we're working in.
\n\nI'm wondering...so, we've got some...so, Will, you're not at Acima. I'm curious what your thoughts. I'm going to start there before we, you know, kind of talk about the Rails side or some of the in-house stuff. I'm also curious what you think, Kyle, and what your thoughts are because you’re looking at this from a DevOps perspective. Where should your business logic go? How do you structure things so that you end up with your business domain and it’s recognizable? And you don't just look like, oh, this is a React app, and that's all it is. I have no idea what else it does.
\n\nWILL: I’d say one thing I am doing a lot of mobile development, you know, that's probably 80% of my work these days. And one thing about mobile app development is you can't roll it out with the speed that you can roll out a web app, right? I can have a web app. I could roll the whole server, I don't know, even a big server I can do, you know, in under an hour, you know, little stuff. You can do it in minutes, if not seconds.
\n\nSo, one of the things that you really need to be mindful of as a sort of, like, a mobile app developer, is pushing business logic as close to the web server as you possibly can. Sometimes you got to do...I'll do in terms of the data, like, what am I going to render and when, where, why, and how? I always want to push that back onto the server because I can fix it. I can change it. I can get different stuff going. And so, you know, for a mobile app and for a web app, too, I really like to keep that view layer pretty, you know, I mean, in terms of logic, I want to do layout. And I want to do a last line of defense sort of, you know, sanity checking, right?
\n\nBecause if something, if for whatever reason, I'm the last line of defense to keep something from being screwed up on the screen, that's what you want, right? That's your goal. That's what you want. But, you know, it's hard to hold that line because you're also sort of managing your L3, 4, 5, like, your last layer of caching, so there's performance considerations there. But, I mean, in terms of that, like, that's as far as I want to go. I want, like, the logic of what I'm being presented to be as far down as possible.
\n\nAnd, I mean, in terms of, you know, business logic, you know, once you start crossing over into web land or server land, I should say, you know, I guess what I'd say is I want to keep the view of what I'm thinking about in terms of logic as small as I possibly can. And maybe I think about it more from the other side because I pick up a lot of, you know, legacy, you know, projects. And so, when I'm trying to make sense of a legacy project, where do I sort of start wrapping my head around it? And I almost always go down to the database schema, like, as low as I possibly can in terms of the data, right? So, I'm looking at database schema. I'm looking at the downstream APIs that are feeding data up to me. It's like, that's how I start to untangle, you know, the logic around some other application.
\n\nSo, for me, I want to keep it, I think, in general, I want to keep business logic as low as I can get it without duplication. It's like, how do you know, oh, I went too low, you know? Is when I start repeating myself, and I have different subsystems that are doing the same job over and over again. So, I think, you know, broad philosophy-wise. That's the best I've got for you.
\n\nMIKE: So, you've got a layer of business logic that lives close to the data but is not right there. It's a little bit above, so you don't have the same thing replicated everywhere or, you know, in all of your database table interaction probably using ORM. It's not duplicated in all those places. It's a layer above. So, it's reusable as widely as possible.
\n\nWILL: Exactly. Yeah. Yeah. Push it down. Push it down as far as you could push it until you start to repeat yourself, you start duplicating the same logic, the same functions, the same functional units over and over and over. And then, you know, and then you start bundling them into a module so that you can reuse it. And then, you know, you just kind of continue on as you are.
\n\nMIKE: I like that because there's a principle there because it applies both on, you know, you're in your mobile app. You're pushing it as close to the web app as possible which is, the web app is your data layer there, right, that, you know, you're pushing down to there. So, you've got this layer above your data layer for that site that has got your business logic. And then, on the web layer, you've got a similar structure. You want to push down as far as possible, as close to the data layer as you can, so that it's reusable. That sounds like something that can be replicated. Makes some sense.
\n\nSo, Kyle, I said I'd ask you as well. So, I'm deliberately going through the non-web app route first before we get into the web app. So, I'm curious what your thoughts are here from the DevOps perspective. Because you write code. You write a lot of code, I'm sure, or at least work with configuration as, you know, as if it was code. What are your thoughts about business logic from a DevOps perspective and where that should go?
\n\nKYLE: I'm trying to think how this would relate in the DevOps world. And what's coming to mind is, specifically here at Acima, we deal with a lot of languages, just to start with. And it's kind of impossible for a small DevOps team to learn every language that all the engineers at Acima are dealing with. And just being able to go in and visualize to see, you know, what is this code doing is very helpful.
\n\nSo, depending on that structure, which each language is going to have their nuances, if it's going to be in Python versus Ruby, you're going to visualize what's being presented to you in very competing ways just because of the way those languages decided to do things. But kind of like Will is pointing out, no matter what, a language generally has a data schema of some sort. And so, we can kind of see, you know, how is that logic put into a database? You know, how's that being stored, and where does that live?
\n\nAnd then, the other thing I was thinking about is where we offload the business logic. Where is this offloaded to that's, you know, can it be replicated? Is this in Redis, RDS, those types of tools? You know, does this get put into a data lake where it then gets replicated across? And kind of trying to think about that.
\n\nAnd then, the other thing I was thinking about, too, is at what point do you start making or putting your business logic into executable functions? And I might mean, you know, Lambdas or the like. When is your code, your app code, just your app, and then the business logic itself gets offloaded onto something else that's kind of executing it? Not necessarily something that is done everywhere.
\n\nI'm just saying, like, when you offload that work where it's constantly repeatable, constantly something that's a small unit that can be thrown away if need be and then rebuilt, and then, like, you're not, you know, necessarily relying on one framework or another, but you're relying on a small piece of code that you can just kind of get rid of and recreate if need be. Those are my initial thoughts on the subject.
\n\nMIKE: Let me dig a little bit more. I know [inaudible 14:28] he uses the analogy a lot of wanting to treat virtual servers, pods, you know, containers like cattle instead of pets.
\n\nKYLE: Yes.
\n\nMIKE: [laughs] And it's a vivid image there [laughs], you know, they're disposable, right? This is something that you're not going to have any qualms with getting rid of.
\n\nKYLE: Yes.
\n\nMIKE: And spinning back up. And so, I'm thinking you don't want to have little bespoke components that you have to rebuild every time for every new service that comes up. But rather you want to have a lot of reusable [inaudible 15:07] in your infrastructure config and building, rather than having this fragile thing where you have to build every one separately.
\n\nSo, I would ask, you know, how do you go about doing that? Because that's logic in building something. You have reusable components for building the infrastructure out. How do you avoid that reuse or avoid the lack of reuse, right? How do you avoid the situation where you end up having to build everything alone? What does that look like in terms of how you structure what you set up?
\n\nKYLE: I'm thinking just everything is config. Everything is config management in that case, especially in the orchestration world. So, you're saving a copy in one place and able to replicate it in several others. And you're taking out those pieces that you aren't relying on that you're able to replicate. So, the server itself, you can replicate that as many times as you want. But the data set, which will probably be the business logic here, has to go into a database that doesn't necessarily...it can have replicas, but you're referencing one data set. And so, everything is kind of going down to that one pipeline.
\n\nAnd then, you know, depending on what these other services that you are actually utilizing, would depend on whether or not, you know, are you putting anything? Are you storing something in Redis per se? And is that something that can be thrown away? Because if we're not putting business logic in Redis, basically, if we can treat Redis as a cattle, now we can scale Redis out, and we get a lot more speed. However, if we're putting something that's a pet into Redis, well, now we've got to be careful with how we scale out Redis and how we worry about the HA availability of that. So, does that answer your question, what I'm going with?
\n\nMIKE: I think it's an interesting answer. You said a couple of things. You said that we need to structure our applications whenever possible to not have special needs. That is, we need to have data, a single source of truth but try to make everything else disposable. And if you're having a caching layer, try to make that disposable. Like, everything disposable if you can, and only have a single source of truth and [laughs] one and only and not any others because that's costly. That's an interesting idea in that it kind of reflects a little bit of what Will was saying that if you go and understand what the data looks like, it can help drive what comes above it.
\n\nWILL: Well, but you said...you made an interesting assumption, right? And as I was sort of, like, thinking about mobile apps, right? So, what I'm doing now is effectively just a glorified web app. I have my single source of truth, right, which is a server, and I'm presenting the data, you know, I'm giving data back. I'm sending it to the data...I'm sending it back and forth.
\n\nBut that isn't actually how it came up. It came up doing, you know, like, a fitness app. So, specifically, I was doing a line of fitness apps, and they would generate data. They would generate speed data, location data, like, calorie burn data, heart rate data. All this data was like you had a mobile app, which was a lot like cattle in that I have a very capable, fully-featured computer that is reading data and processing it. It's doing its own thing. It's its own process that can do a lot of stuff, right? Easily comparable to one of many server threads generating data.
\n\nBut it's also, like, it can do anything. It's just like, oh, I ran under a bridge. We don't have any cell phone service now. I ran out of battery, so this thing's done. The system's going down right now. I ran out of space. This thing just crashed. Oh, you got a virus, and it took down your whole phone. Apple, for whatever reason, didn't like your process anymore and decided to squash it. Anything can happen to these things. They could stop any time at all, for any reason. You know, like, oh, I put it on airplane mode. Oh, I was uploading this big data set, hmm, not no more. We're done now.
\n\nAnd then, you have to sort of catch that, and recover from it, and process it, and get the data back up. It's like, oh, I was sending that thing, but it didn't work out. Oh, and then then I ran out of space. So, I have to delete something. I’m like, they just deleted the whole app, and I had to recreate myself from whatever fragments of state I have available to me. The single source of truth, that's complicated, you know.
\n\nAnd if you're talking about your processes like cattle and not pets, it’s like, oh, well, that job? That job just failed, too big. I remember you know, scaling days at Acima where it was just like, sorry, guys. We made too much money today, and we literally can't count it all. And so, we uploaded these giant CSV files to the bank, like, all of our takings for the day. And I'm like, it will crash [laughs]. It will crash.
\n\nKyle, you and I, like, I remember you and I were chasing memory leaks in this, you know, giant CSV bank transaction processing thing because we made too much money. We made too much money, you know. And then, we were sort of chasing it down. And so, you have to have sort of like a fault tolerance and checkpointing and, you know, callback steps where it's like, "Okay, did you get that?" "Yes, I got it." "Okay. I'm going to mark this job as finished," you know, and then, oh, is the job idempotent? Can I run the job twice? Oh, maybe not. You don't want to double charge. There's where the pigs get fat, hogs get slaughtered. I'm not trying to double my winnings. That would be bad. And so, when there isn't a single source of truth, that's when things start to get interesting.
\n\nMIKE: So, you’re saying that the structure of things, because we're talking about structure here, becomes challenging when your data is, well, that source of truth, you know, your data is not very reliable, and, well, anything is not reliable. That's interesting. You think about caching, and caching is a mess. Nobody wants to do caching. It's horrible. And it's also the only answer for a whole bunch of problems because of that same problem. There's so many ways, so many ways.
\n\nYou can't get all the instructions to your processor. You can't get them in there fast enough. So, there is caching in there to get that push down, and you can't upload transactions fast enough sometimes. You're getting a stream of data from an app on the other side. You know, even within the company, right? They're sending you data as things are going on. And you could rely on them and send stuff, you know, make a request, like, a REST request every time. And now you've got a single point of failure, and every time they deploy, you go down, too. So, you've got to have that caching layer. You've got to have redundant data, which affects your structure a lot.
\n\nWILL: Dump it on the queue. You know what I mean? Dump it on your...I misremember the queue flavor, you know, the AWS queue flavor. The SN –
\n\nMIKE: SNS is the notification, and then you subscribe to it with SQS.
\n\nWILL: SQS, yeah. SQS or Kafka. Then what happens if you blow out your queue? Uh-oh. Some of these transactions they need to go out and persist to the database. But they don't just, you know, some of them you just persist it out to the database, no problem. But, again, we're talking about people getting paid. You want to commit that atomically. That goes in one time and only one time. And it only commits when all the [inaudible 23:38] are dotted, and ts are crossed, right? And that takes time, especially if you have multiple data centers.
\n\nAgain, you don't want to just commit it to one database. You want to make sure everybody got it, and everybody knows they got it. And, like, if you get it, okay. If you get it, okay. And I'm waiting on you [laughter]. Uh-oh, this guy, he's not coming back. So, then I'm dumping my transaction. Transaction is over now. Oh, well, what do we do about that? Now I'm going into the naughty box, where we're going to have to come back to that. Oh, I'm going to retry. How many times do I retry, right? Oh, I've retried it three times. Like, okay, now I'm sending emails. Now pagers are going off, you know [laughter].
\n\nKYLE: Well, and it's how do you know when to retry, too? Because you're in the middle of processing a job, and you get a SIGTERM. Okay. Well, did your application handle that gracefully? Is it done? Did it finish? Do we retry now? There's so many cases there.
\n\nWILL: Do we all retry at the same time, right? Like, oh, I just lost a whole...I'm kind of falling behind. And so, then I have a big batch of jobs. Like, I was already not quite doing so good, and then I have a big batch of jobs. They all terminate at the same time. And now I'm just like, [inaudible 25:07] my server because all my retries hid in this giant tsunami, and now we've got pagers going off [laughs] once again.
\n\nMIKE: And that's a general, yeah, and that's not the only place that happens, you know, cache stampedes where you [chuckles] clear your cache, you know, it didn't come through, so I'm just going to wipe it. And a specific problem, I had a different company. We had a content management system, and we were getting a lot of requests, like, a lot, a lot of requests on the order of about a billion a month or something, you know, so a lot of requests coming in.
\n\nAnd, yeah, if you're trying to rebuild, the content for every one of those, oh, you will just die. And [chuckles] so, you have to have layer after layer of guarantees that, you know, when a request comes in, oh, wait, this content is stale. Well, I'm going to go build that in the background. I'm not going to serve you the stale content. And then, when that background content is ready, we're going to stick it in place so that the next person who comes in gets fresh content. But I can't fill up my caches; got finite space. So, I canceled everything forever. And [chuckles] it's messy. And if you ever just take the cache and expect that to rebuild, bad things happen.
\n\nKYLE: Well, and it's how much cache do you have, right? Because then it's do you go with a small amount of cache? And, okay, that helps, but a larger amount of cache would be better. But if we lose that large cache, I mean, we're in for even more of a world of hurt.
\n\nMIKE: [laughs] It's interesting we're talking so much about caching and messaging, you know, we're talking about structure and business logic. But we're saying, well, data is messy. And so, inevitably, a lot of what we build is going to be around dealing with imperfect persistence and, you know, imperfect connections, all of the weaknesses in the system because things are going to break. What about just your straight-up reusable business logic? Say you've got code that's going to take an input from your user and split it up into its parts and save it to the database.
\n\nEddy and Ramses, I deliberately went through Will and Kyle first [laughs]. So, I'm going to come up to the web developers and Rails developers specifically. Rails gives you models, views, and controllers. Should you stick your business logic in one of those places?
\n\nEDDY: Just dump everything into your models and then just call it a day [laughs]. You can't go wrong with that. Or also, put everything in your controllers, too, just make them fat, you know, put everything there.
\n\nNo [laughs], I think when you started mentioning domain business logic, I started to really write some notes down. And I think what it really comes down to is how large your project is, right? If it's like a simple blog, you know, things like that, I think you're inherently going to have your models and views and everything tightly coupled. And I think that's fine, you know, if it's something that doesn't have much strain in your service or whatever.
\n\nBut think in terms, like, merchant portal. DHH, I think, is what we call it. It might be still sufficient, but you need to optimize it in such a way so that you're not putting much constraint in your project. So, I think one way to probably think about that is probably just extracting domain objects, things like that. You may want to mock or stub out tests, you know, just so that things are really simple to follow. And you're not waiting for builds and stuff. But still, you're going to run inherently into a problem where your controllers are really coupled with models and stuff.
\n\nAnd [chuckles] so, I think what we really want to consider is extracting data, right? And I ran into this issue. I ran into this terminology a while back called fat controllers, right? Has anyone heard of that term before?
\n\nMIKE: [inaudible 29:45] as bad thing [laughs].
\n\nEDDY: Yeah, it's kind of like in dumping ground, right, where you do a bunch of business logic controllers, but that's not really the design for it in MVC, right? Not to mention, I'm a huge subscriber to Singleton, so, like, single responsibility. I think that's really important to also implement into your service. Specifically, if you put stuff in your model, for example, the models, I believe, inherit from ActiveRecord. And they're going to be responsible for a bunch of domain logic and persistence. And I think that's bad, right? So, we want to avoid putting domain or, specifically, business logics into models [inaudible 30:35] controllers, right? Because you're asking for a really bad time. So, something to consider, I think, maybe PORO might be a good alternative, right?
\n\nMIKE: So, what you're saying is, don't put it quite in the data layer but have a layer right above that, where you have reusable components as close to your data layer but not quite there. Notice the pattern, which is what Will said should happen in both the mobile app and the web app is that you'd have a layer of business logics. Now, you had talked about having a plain Ruby object. And the specific kind of object really doesn't matter so much. So, you said, well, your business logic should be in its own reusable layer, close to but not quite the same thing as your data layer.
\n\nEDDY: Exactly, yep. You mentioned Uncle Bob's Clean Architecture [laughs], so I looked it up really quick. And something that really caught my eye was something...and I quote, “Software dependency should all point towards higher level business rules. The database, web, and other external interfaces does become the lowest level of implementation details.” And I think that's really key to what we're talking about, and I think it's kind of funny because Rails sort of doesn't follow this design, like, we usually think of Rails as, like, database design is probably considered first. And then, you have ActiveRecord models are created by one by one mappings [laughs]. And I think that sort of happens inevitably when you have a CRUD app, right?
\n\nMIKE: Yeah, so there's some pushback from him to rethink about that. Think about what your application looks like, possibly independently of what your database structure looks like, because they should not exactly align. You know, maybe you have a concept that doesn't exactly map to what you have in your database but makes sense as a concept. You can build around it, but it isn't necessarily a thing that maps to an exact table.
\n\nSo, we've talked to, you know, somebody doing mobile development, somebody doing DevOps, somebody doing web development. And joining us a little late today, we've got Justin. Thanks for joining us, Justin [laughs].
\n\nJUSTIN: Better late than never.
\n\nMIKE: And I'm curious, so we've been talking about how we should structure an application so that the structure of the application reflects its purpose. And you're doing security, and I'm interested in your perspective on that. And I'm bouncing over you, Ramses, because Eddy spoke up first, but I'm still interested in your opinion if you've got one. I’m going to jump over to Justin because we're getting a wide variety of perspectives here. So, from a security’s perspective, what are your thoughts about the structure of applications? Specifically, where should business logic go and why?
\n\nJUSTIN: So, that's an interesting question because I have never thought of that from a security perspective. Is there a best place for it from a security perspective? If I'm looking at it the way that something is structured, I'm always interested in validating all the input, validating, you know, doing all the checks before any business logic actually gets executed.
\n\nSo, you need to be able to do the authentication, do the authorization, you know, validate the inputs. And that's basically it, actually [laughs]. But you got to do those things first, and then you can do business logic. And then, you can, you know, then it gets stored away, you know, whatever happens, happens, the actions, whether it's storing it in a database or calling another third party, or anything like that.
\n\nAnother thing that's interesting is the inputs and outputs are always interesting, to me, from a security perspective, because, you know, validate the inputs, validate the outputs. And do that for every layer or third party that you're doing, and that makes it a secure environment. I think there are several models that that could fit within, you know, classic MVC, or it should fit within every model, really. But those are my main concerns there from that point of view.
\n\nMIKE: Well, you said something really interesting there. You wanted to have a layer that handles your input, and that's not your business logic layer.
\n\nJUSTIN: Yeah, you got to validate that before it hits the business logic because if you have unvalidated data going through your business, it could hit all the branches, and it may be doing something that you may not want it to.
\n\nMIKE: So, from a security perspective, you're advocating for a structure where you have a well-defined layer that does input handling. You talked about Rails, you know, and you mentioned MVC with Rails MVC frameworks. We'll talk about that because we've done a lot with that. Your controller layer is positioned to do that input validation, and I would argue is badly, horribly positioned to do the business logic because it's designed to have that request come in, do the input validation, and, hey, are you logged in [chuckles]? Are you giving me valid data? Are you giving me something huge that I shouldn't be doing anything with? You know, whatever the case is that they're handing off. It's designed to do that.
\n\nBut then, if it's doing that, thinking about it, well, that's a separate concern, right? That's a different thing. So, you should be handing it off to do something. So, listeners are not seeing visualization. I'm talking with my hands [laughs]. You've got a layer that speaks to the outside world and handles that. But then the business logic you're pushing back down to a deeper layer that sits in between that interface layer and the database. And this is interesting because we've got a recurring theme again [laughs].
\n\nSo, Will talked about, well, I'm going to push it as close to the data layer as I can, but not so far that it starts to repeat itself, separating it from the UI concerns, right? Separating from those interface concerns. And he said the same thing about the web application. Well, you're saying the same thing from a security perspective.
\n\nAnd Eddy kind of said similar things from a usability perspective for a developer happiness perspective [laughter]. You don't want to have everything in a place that's not reusable. You want to have it in a reusable place. And all of these are kind of pointing to the same idea that you have this interface layer that handles those interface things. But that's a separate concern from your business logic. Your business logic should go somewhere else. It should go in this deeper layer that's not your data layer but is closer to it.
\n\nWILL: My original thesis, I still believe in strong, right? Which is that it should go, you know, as deep, as close to the data layer as you can get before you have duplication. So, form validation on the UI side actually sucks. It totally sucks from a software architecture thing because there's all kinds of stuff. You're, like, half-ass verifying, and you're half-ass validating, where it's like, I could check maybe a credit card CVC, or, you know, did you even fill this form in? I could do that stuff.
\n\nBut then I got to do all the other stuff on the data layer, right? So, the credit card form. Like, I got to check this card. Is this card actually...is it valid? Is it even on, right? So, I got to do all this, you know, messy stuff. Like, it doesn't get me out of everything. I'd have to write it twice. And it's actually a giant pain in the ass to revalidate the thing just to be like, I went all the way down to, you know, calling the bank, you know, virtually. And the bank says, “Yo, no fricking way,” right? Then I have to parse that data and then update the UIs. But you want to do it because it's better UX, I mean, it's better user experience, right? You want to hit it as fast as you can.
\n\nBut in terms of software architecture, awful, just terrible, terrible. Like, from my perspective, for my benefit only, do it all on the server side, all of it on the server. Because I got to do it that way anyway. So, like, why do it twice? Well, because it's not fun. So, anyway, I mean, it's just, you know, we sacrifice; we bleed --
\n\nEDDY: I would counter-argue that you do simple validations on the client side, and then do all of your logic validation in your backend; just saying. But I'm also –-
\n\nJUSTIN: But that's what he's saying, right?
\n\nWILL: Yeah.
\n\nEDDY: Oh, gotcha. I thought you said it in reverse. Okay, never mind. Never mind.
\n\nWILL: Yeah, well, yeah, you have to do it twice, right? I'm saying that it sucks to have to do it on the frontend, and then you have to do it all over on the backend. Because I don't trust anything coming from the user, right? And so, purely for my benefit, do it all on the backend, but it's just not good UX, right? Because you've got to wait for the round trip, and then the whole thing, and it's just, you know, it's a giant pain that nobody likes, you know, as a consumer.
\n\nMIKE: So, you just have to kind of forget about the fact that there's another layer that's doing all this somewhere else, and just live in your own layer [laughs]. The other layers don't exist. Then, you don't have to stress about it because you didn't write the validation again. Somebody else did. Except you probably did because you're probably doing both [laughs].
\n\nWILL: Probably, you're doing both.
\n\nMIKE: [laughs]
\n\nWILL: And, at the very least, you have to come back, and you have to parse out the, you know, this is the error, and communicate that, you know, even if it doesn't necessarily fit in your form anymore. Anyway [inaudible [40:55]
\n\nKYLE: I was thinking, when Justin was talking, something that we haven't necessarily hit on is actually the testing side of this. And it is one of those things where if you get your business logic too close to your UI level, or if you get it too close to your data level, your matrix on your testing scenarios gets a lot higher, and it gets a lot harder to do. And so, if you're able to isolate your business logic, you can mock and stub a lot of what you need in order to test just your business logic and validate that. And that would be helpful, you know, regardless of whether or not it's QA or security, I would imagine. But that just kind of occurred to me. If we treat it as that separate layer, then we can just focus on that, and curate that, and then curate the controllers and stuff that we're using independently.
\n\nEDDY: You know, in the past, I probably would have agreed with you cold-heartedly. But I, more often than not, have wished I had integration testing because it turned out I didn't truly understand, you know, what I was actually touching. So, there is a layer to both.
\n\nKYLE: Well...yes.
\n\nMIKE: They can both be true, though. They can both be true. You can have integration tests that do full end-to-end.
\n\nKYLE: Yes.
\n\nMIKE: And they take a hundred times as long. And then, you have your unit tests that don't have to touch the data layer and actually go fast. They're separate concerns that are both important. And if you intermingle those, you'll get in trouble because if you try to do all your tests with integration tests, yeah, they'll never finish, ever [laughter]. And –-
\n\nEDDY: Unit tests are fine. You better be damn sure you know all of your branches. Like, that's the only thing. And it's bit us more than once, you know, at Acima [laughs]. And so, all I'm saying is past Eddy would have said, "No, dude, mock, stub, everything. It's fine. You're good." But if you're not actually, like, making calls, you have to be 100% sure, you know, like, you understand how that works, what the response is, everything.
\n\nMIKE: So, you know, I think coming back to the theme we're coalescing around here, from a security perspective, you want to have this middle layer that's had stuff validated before it gets there, right? From a testing perspective, you want to have a business layer that's able to be tested independently that's not all entangled with your data layers. Your test runs way slower [laughs]. And I wasn't kidding with 100x. That's probably actually low [chuckles]. It is way slower to have tests that have to go through [inaudible 43:38], and then they're fragile.
\n\nAnd from a code usability perspective, you don't want to have everything. It all pushes towards...and then, going back to your block of marble, your beautiful block of marble, it gives you some constraints. You've got to have a layer in the middle. You've got to have a layer in the middle. And it's kind of inescapable that that business layer should be somewhere in the middle and not in your interface layer and not in your data layer, but in between. It's important.
\n\nJUSTIN: I hate to bring this up at the end of the podcast, but I'm just wondering, have anyone had experience with any of the cases where they store the business logic in the database as data and then they load it into the middle business layer that way? And if it's stored in data in the database, you can do various things with it. But that dream is always more complicated to implement than people would imagine.
\n\nMIKE: I talked to somebody who worked for a company that spent a couple of years building this beautiful system that did that until they went bankrupt because it took so long to build it they never made a penny [laughter].
\n\nJUSTIN: So, I worked at a place that tried to do that, and it was painful for everyone involved. But I'm just wondering if other people have run into a success story because that's the ideal, right, is you just define it with words in a database, and there you go.
\n\nWILL: I think in terms of the program logic and stuff like that, eh, I think what you can do is sort of...you can have metadata. And one of the things that I've done is I've had sort of metadata around a record, which could be, you know, fairly sophisticated, I mean, really. Like, I'm trying to think if I could characterize this easily.
\n\nSo, I'll give you an example, right? So, I used to work on this series of fitness workout apps, right? So, everything was modeled as, you know, exercise. And, you know, it's like, okay, we're going to do chest exercise. We're going to do 20 reps, right? And it would coach you through that in a different way than it would be like, oh, we're going to do 20 minutes on the StairMaster, right, or something like that.
\n\nAnd so, like, the way it would communicate to you, the way it would log data, stuff like that, you could think of it like a style sheet, like a CSS style sheet. It would interpret things in this way or that way. It would do this thing in this way or that way. And so, it was metadata that did affect the way things are processed, but it wasn't really actual code. I think if you're writing actual code, I mean, because I've seen, you know, kind of PHP-type backends, where they're doing, you know, kind of weird stuff like that. Like, we have databases in databases in databases, you know, where everything is kind of Siamese twinned together.
\n\nAnd I find that stuff pretty...it's hard to work with. It's hard to think about. Sometimes there are sort of technical reasons, performance reasons, or sort of generality reasons that you would do something like that. But generally speaking, it's more of a means to an end to that goal, you know. I know if you go and you open up Core Data, which is, like, Apple's native mobile data layer, right? It's their version of, you know, SQL, or something like that, right? It shifts with all the iPhones. It's a SQLite database, and every row is the same, right? Every row contains all of the columns for all of the rows, right? And it'll populate, you know, these set of columns just based on the data type that it is, and that's just how they did it.
\n\nAnd I don't know the internal details around the technical basis for it, but I know some very smart people got paid a lot of money to write a hot, you know, SQLite interpreter for iOS. And I have every reason to believe they had good reasons for choosing what they chose. But if you ever look at it in a SQLite editor, it is just a mess [laughs], you know.
\n\nAnd so, I don't know, I try to keep it as dumb and as simple and as easy to read as I can, unless I can't, and then I do what I got to do.
\n\nEDDY: Well, I'd like to see that sometime.
\n\nWILL: No, you don't [laughter] [inaudible 48:34]
\n\nEDDY: Hey, just to be clear, I don't want to write it. I don't want to contribute to it, but I'd like to see it. It seems a bunch of spaghetti.
\n\nWILL: Well, I mean, it's exactly what you think. So, if you have, say, think of your random database schema, right? So, you have 10 different data types, right? Every row contains the columns for every data type and some metadata that says, "Oh, this is a product," right? So, it's going to have these columns in it, and they're going to be populated. Or, oh, it's a special sale, and it'll have these, you know, things. It's just a hash. But, I mean, you know, hey, whatever, man. That's the gig.
\n\nAnd they wrap it up in an only mildly hostile RM, like, you know, APIs, so that you don't have to know about that kind of stuff unless you really, really, really, hate, you know, yourself and what you were going to think about doing that day. Or, and this is what happened to me, something bad happened, and you need to figure out how to undo what you just did. Nobody --
\n\nJUSTIN: Hopefully, you can roll back that database update.
\n\nWILL: Exactly, exactly. Rolling back a database update that you screwed up in SQLite is...let's just say anybody who knows how to do that had a real bad day [laughter].
\n\nKYLE: [inaudible 49:59]
\n\nWILL: All right, well, I don't have anything to add. Should we wrap it up?
\n\nEDDY: Awesome. Oh yeah. This was a great conversation, like always. Super good. You guys are awesome. Thanks everyone for joining.
\n\nWILL: Thank you, gentlemen. Y'all have [inaudible 50:16]
\n\nEDDY: Thank you. Another great session of the Acima podcast. Bye, everyone.
","summary":"","date_published":"2024-11-27T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/c93db8ea-574f-4996-b175-d7dfe0e0d171.mp3","mime_type":"audio/mpeg","size_in_bytes":29900376,"duration_in_seconds":3034}]},{"id":"9c1f3567-b9cb-43ff-9626-5215b097e65f","title":"Episode 59: Infrastructure Tools","url":"https://acima-development.fireside.fm/59","content_text":"In this episode of the Acima Development Podcast, the panel dives into the complexities and consequences of choosing the right tools for software development and engineering. Justin opens with a story from his first job, where his team implemented an Oracle Customer Management System that ultimately led to disaster. The system, despite promises of extensive customizability and robust functionality, failed spectacularly due to performance issues, particularly with search speed, which took minutes per query. This failure, which ended in a costly rollback to the previous system, highlighted significant lessons about the importance of realistic testing, validating vendor claims independently, and having fallback plans for major tooling changes.\n\nAs the discussion progresses, the team shares additional insights on the risks associated with both large, established tech tools and smaller, emerging ones. They debate the pros and cons of \"buy vs. build,\" generally advocating for buying established solutions rather than building in-house, particularly when these tools fall outside the company’s core value proposition. However, they recognize that established tools, while more reliable, often become stagnant, and smaller, innovative companies may offer better solutions that come with risks, such as sustainability and long-term support. A balance is often difficult to strike, and each choice comes with potential downsides, whether it's cost, dependency, or eventual obsolescence.\n\nThe episode closes on a broader note about the inherent \"bitter lesson\" of technology: that simple algorithms powered by ample resources often outperform intricate, specialized solutions. This leads to a candid reflection on open-source contributions, corporate influence, and the evolving tech landscape, where many advancements are the result of unsustainable VC-backed ventures. The hosts humorously conclude with the advice that any tooling decision likely involves trade-offs and inevitable challenges, encouraging listeners to accept the imperfect nature of these choices.\n\nTranscript:\n\nEDDY: Hello and welcome to Acimas Dev Podcast. Today, we have an awesome crowd, right? We have Mike; we have Kyle; we have Justin, and Melina, right? And today we decided upon popular opinion, right? That we'd be talking about tooling, right? Should you be married to a tool, pros and cons of switching to a new tool, when to do it, why to do it. And Justin actually was talking off-air on having a horror story behind something that sort of segues into this. So, Justin, by all means. \n\nJUSTIN: All right. So, what I have is a story from my first real programming job, and it was the decision to move to Oracle. Boy, I don't even know what it was called, but it was an Oracle customer management system, the CMS. And, if you're a programmer, sometime in your career, you will either write or rewrite a customer management system. That is, like, a given. I was lucky enough to do it or unlucky enough to do it on my first job. And the decision was made at levels far above me that we were going to do Oracle’s customer management system, which was, you know, Oracle a huge company, huge corporation, and it had a tool for everything and, especially, it had a tool for managing customers that we had never used before. \n\nAnd the thing about it was is, like, they advertised it as, hey, you can use this tool, and you can customize it any way you like it because we have a field for everything, and you can add your own custom fields. And every field could be validated, and every field could be a search, and every customer can have any number of objects associated with the customer. And so, it was everything to everybody. And the VP in charge was like, oh, this is going to be awesome. \n\nAnd we were a medical company that did medical tests. And we had customers in the numbers of tens of thousands, if not pushing a hundred thousand. So, the order of magnitude was actually not that big. But as we went along, we got given a deadline saying, “Hey, we are releasing this day, do or die.” And by gosh, we did it. We released that day. And come to find out the next day that nobody could use it. It wasn't a login issue; rather, it was a performance issue. Every single search took upwards of five minutes. \n\nAnd it was just a horrible, horrible experience. And it slowed our customer relationship team down to a crawl. Phone calls couldn't be completed. Doctors couldn't update their customer fields and things like that. And for the next, I think it was week and a half, we tried to fix it. And then, the CEO came in and said, “Screw it. You guys are moving back to the old way.” \n\nAnd, ultimately, we ended up throwing that away. And it was a, I don't know, I think it was on the order of a 5 million project, which some people think that's huge. Some people think that's not that huge. But to us, it was months and months of work and licensing fees and data. And it's actually probably over a year of work, come to think of it.\n\nBut the key there was that it was an environment that nobody really knew how to do, an infrastructure that was new to folks. I mean, we'd done Oracle databases before, but, all of a sudden, we were asked to develop within the Oracle framework and using their tools, and it just sucked. And not only that, but our test environment was certainly not populated with a large enough data set to validate everything. And I believe that the fallout from that was the...I think that VP got fired. The rest of us just, you know, kept on going. And so, that's, like, the tale as old as time is, you know, some middle manager or upper middle manager gets canned because their project was a horrible implementation. \n\nEDDY: So, what's the underlying problem here? Was it lack of training? Is it the fact that you're developing in Java, or is it just Oracle in general [laughs]? \n\nJUSTIN: I don't know. There's probably plenty of blame to go around, right? But the lessons that I learned was the fact that you cannot depend on salespeople for the numbers that they give you. You have to prove it out yourself. And then, you have to test with as real production data as possible, and that includes complexity. That includes number of rows. That includes number of transactions, all of that. \n\nAnd you actually should have a rollout period where you have a beta with production data for X number of time because it basically shut the company down for a week and a half while we tried to make it work because they didn't have a fallback. And, luckily, they were able to fall back. They were able to roll back to the old way after a week and a half, but it was just...it just sucked. \n\nAnd, also, from the developer point of view, using the Oracle tools...because we had to use their packages. We had to use their architecture. Previously, we were just using their database as a data store. But now we were using their libraries. We were using their SDK a little bit. We were using their, you know, all these things, and it just sucked. Long story short, Oracle sucks, and use Postgres [laughs]. Even back then, Postgres was a thing, so... \n\nEDDY: I'm just surprised the company was willing to go a whole week with production being down until they finally decided, oh, you know what, cut the losses [laughs]. Let's go back to...\n\nJUSTIN: It's funny because different companies have different tolerances. This was a medical company. And so, when I say the whole company was shut down, I mean just, like, the customer side. We were still doing tests and things like that. And so, there was a certain amount of tolerance there for a couple of days. But the CEO was just like, you know, after a little while, he just couldn't take it anymore. \n\nKYLE: So, with that, were you privy to why they concluded on Oracle at all? And was there any competition why that tooling was selected? \n\nJUSTIN: That was all so far above me.\n\nKYLE: Far above you.\n\nJUSTIN: I was fresh out of college, but, man, it was a trial by fire. And just to follow up that a little bit, we were a development team of about 20. Over the course of the following year, I think they lost 15 of the engineers just because, you know, there were other problems with that organization, technology-wise. That was kind of the same time I left as well. \n\nMIKE: Yeah, I can say it's not always the big players. In my first job [laughs], we switched to a new customer management system, and it was built by, like, some guy in his garage. And it really was just somebody [laughs], I think, the CEO knew. And the entire thing, the entire system, was built around stored procedures in SQL Server because [laughs] they provide functionality to call out to externally compiled binaries, which, of course, you don't have the source code for that he had built. And there's no source code control, right? Because it's all just implemented straight inside the database. And there's no searching. You just have to know which store procedure to look at or look through them one by one until you find what you're looking for. And that was the entire system. \n\nAnd we bought it, and then, of course, the person who we bought it from wasn't available for assistance. So, it was on us to manage it ourselves. And we kept that tool [laughs] for as long as I was at that company, meaning I learned how [laughs] to navigate through every bit of that code in order to make it work. \n\nThere's a lesson here about how you provision tools at a company, I think. As a company, whoever you are, you're probably not a customer management system company. And if you're putting all of your efforts into building that in-house, you're diluting your expertise in what you’re probably supposed to specialize in, whether it be medical products, or some sort of medical services, or financial services, or whatever the case may be. You are focused on somewhere outside your area of core expertise, and that often goes badly. I am, in general, in favor of buying the tools that do the right thing, that do the right job. But there's some caveats in there, right? It's the right tools. You go through some processes that involve people actually using it. \n\nWILL: Yeah. I mean, you should never, I don’t know, you should never invest in a tool outside, in my opinion, I don't think, without an overwhelming reason, you should never invest in any kind of tooling that's outside your sort of core value proposition past a certain scale. Because there's people who've done stuff where Facebook basically rewrote PHP, which is ludicrous for anybody but Facebook. \n\nEDDY: They built their own framework, too, right? Like, it's insane. \n\nWILL: Yeah, yeah, absolutely. And building their own framework, I think that one's, ah, you know, like, how do I put it? I think that proposition is dubious. I think React might be stunting a little bit, which is because if they invested that amount of resources into one of the existing things and just fixed the problems that they had with it, would they really get a worse result? I bet not. But, eh, whatever, you know, probably [inaudible 10:31], you know, like, they have their thing, and it's really deep, and they did good, and they’re like, React Native is actually really dope these days, you know what I mean? For, like, cross-platform, mobile, like, that's it. That's the game. And they actually did it, and, like, it kind of sucks for web now, but that's fine. Anyway, that's a tangent. Yeah, but don't invest in tooling outside of your core value proposition. \n\nMIKE: You're saying buy, not build\n if it's –\n\nWILL: Always. Always. Always. Always. Always. Always buy, not build. Never. As an engineer, just...engineering's the worst. Just don't do it. \n\nJUSTIN: [laughs]\n\nEDDY: So, you're basically saying don't build my own AWS system, right?\n\nWILL: Is that a sub-tweet? Like, if you're discussing it, like [laughter], entirely, like, I'll be the hatchet man. They can't fire me. Literally can't. So, like, no [laughter]. \n\nMIKE: One nice thing about not being employed at Acima is you can speak your mind [laughter]. \n\nWILL: You know what, actually, you know what I mean? Like, an engineer, one of the core engineering mindsets is everything is a trade-off, right? Everything's a trade-off. And I'll say this, man, because another...it's not a requirement to be an engineer, but they [inaudible 11:52]. I'm a miserable cheap bastard, and AWS is expensive. These people have been tightening the screws pretty hard. I've been seeing some bills, and I've been like, how much does a rack cost these days [laughter], you know? Like, racks aren’t that bad. It's not so bad. I could plug cables. \n\nKYLE: Well, and a lot of the other cloud providers are up and coming, right? And they're kind of cheaper at the moment. So, yes, you get a lot of the large support from the Azures, the Googles, the Amazons. But there's others that, depending on what you're doing, they're completely viable.\n\nWILL: I mean, large support. I've never been large enough to get large support, so I don't give a ****.\n\nKYLE: Exactly.\n\nWILL: But I also, like, my experience with AWS is twisting their arm to fix something they broke in the first place. I was like, oh, man, us-east-1 is down again. I better email Amazon so they can tell me to go stuff it. I'm like, all right, cool. There it is, us-east-1 down again. What are we going to do about it? We'll get back to you. Cool. Thanks for the support.\n\nKYLE: And that kind of brings up a good point. You're relying on a tool to provide you a service, and you're running into a situation where you're like, hey, your product’s down in a certain zone. What are they recommending? Well, become Multi-AZ, then. Become multi-region. Buy more of our product. Use more of our services. And it's like, where do you define the line? And it's, okay, do you go into more regions? Do you invest more in their product? Or do you go multi-cloud, or do you go hybrid, or, you know, like, how do you solve that? Because is the right answer going multi-region and putting more money in their pockets at that point?\n\nEDDY: I think that -- \n\nWILL: Is the answer, like, is the answer, like, how many cancellations am I going to get really? Because, like, okay, we have to always be up. We have to always be up. And I'm like, actually, no. If you can't get a TV today, you'll be okay. You're going to be all right. It’s okay.\n\nEDDY: So, can you ever consider --\n\nWILL: But can you check that cap spreadsheet, you know what I mean, before I go on vacation? It's like, well, maybe you hit it from the plane. Like, a lot of this stuff isn't actually a life-or-death situation. And to the extent that it doesn't cause churn or cancellations or bottom-line stuff, you know, like, I know we're not allowed to say it out loud, and it's not the Will's boss podcast. So, again, I could just say what I want, but I mean, like, eh, [inaudible 14:52]. \n\nJUSTIN: It totally depends on what company you're working for. Because I worked at a FinTech firm that, the downtime was measured in millions per minute, and nobody was going to die, but it was literally millions per minute. \n\nWILL: I don't know, man. FinTech and downtime goes together like peanut butter and jelly [laughs]. \n\nJUSTIN: No, this --\n\nWILL: I have worked with a financial system before. Y'all people [laughs]. \n\nJUSTIN: Yeah, no, this...I’m trying to [crosstalk 15:28]\n\nWILL: ...Trading type stuff? \n\nJUSTIN: Yes. Yes. \n\nEDDY: I mean, I'd argue that part of the conversation that happens when switching tooling is cost, right? \n\nKYLE: Yeah, big time.\n\nEDDY: So, if at one point the tooling that you're using becomes way too expensive, either to maintain or to license, I think conversations will be had about switching to a different system, right? I always advocate to having a fallback, right? So, if you're using Amazon exclusively for your hosting service, if one of them goes down, like, one of the regions goes down, like, you're done. And so, conversations need to be had about what do you do in that scenario? Do you go to a different provider that's not Amazon? And if you do, what's the cost? What's the risks? I think that's something that needs to...\n\nKYLE: It's a conversation of expertise, too, because a lot of the time the company will invest not only in a cloud, but it will invest in engineers that are specialized in that cloud. And so, then, if you're going from Amazon to Google, well, now you got a bunch of Amazon cloud engineers. And what does it cost then to switch to Google Cloud? And that's sometimes a lot more costly than just eating the increased billing cost. \n\nWILL: And also, man, in all honesty, it's like a parallel algorithm. You might have to rewrite your whole thing to be like, oh yeah, that data center is down. It's like, oh, I'll just use the other one. Okay. Whoa! Whoa! Whoa! This database went out. What happened to all the transactions? And is that cool? That was...whoa! Whoa! Me and Mike spent, what, a year reading a book on that, and it was heavy duty, man [laughter]. \n\nJUSTIN: So, I think there are a couple of things that you need to look at when you are deciding which architecture you want to be. And I'm glad you brought up that Google Cloud versus AWS. If you can write your infrastructure as code, which, you know, you guys are, and we are, and most people are these days, you can be provider agnostic to a certain extent and be able to, you know, the migration from AWS to Google Cloud or to Azure would hopefully be less painful because you've got everything defined in your Terraform or, hopefully, using Terraform, maybe not CloudFront or whatever.\n\nBut as you go along, I think that is the key. You design your systems to be implementation agnostic. And thus you can, if something better comes along, you can make the switch as painlessly as possible. That's not to say that's easy, but I think that's the ideal. \n\nWILL: The eternal lie of cross-platform development [laughter], hmm, [inaudible 18:50] so much to do that.\n\nJUSTIN: Hey, I was a Flutter developer for four years. \n\nWILL: Oh, I'm so sorry --\n\nJUSTIN: And it actually worked out. It worked out. iOS and Android, it can happen [laughs]. \n\nWILL: Sure.\n\nEDDY: Just use Kotlin. \n\nKYLE: Just use Kotlin [laughs]? \n\nJUSTIN: Kotlin multi-platform isn't there yet, but it's getting better. Anyway... \n\nWILL: Nor will it be because iOS is actually, like, in the back end is actually...iOS is really stingy on the RAM. They don't tell you how much RAM an iPhone has, and that's not because the numbers are too good. \n\nJUSTIN: No, no [laughs], they aren't. iPhones suck that way [laughter].\n\nWILL: They really do. Well, I mean, you could say the iPhone sucks, or you could say the JVM. JVM, come on, buddy. \n\nJUSTIN: Oh, wow. \n\nWILL: Do you really need that much?\n\nEDDY: Which is why having open-source software is really important. \n\nWILL: Yes, absolutely. The operating system should be open source. No operating system in the world ever, ever, ever should be closed source. It shouldn't be allowed. It should not be allowed. But I don't think that is podcast for the day [laughter]. \n\nJUSTIN: No, but you look at the couple of other things that you have going on there in terms of what is running your actual system. And if you have everything dockerized, you have everything set up as infrastructure as code, you can have it all be pretty provider agnostic because you could run your Kubernetes on AWS. You can run that on Google Cloud. You can run that on Microsoft Azure. And the principles are mostly the same theoretically on this specific thing. I don't know. \n\nWILL: No, you're right. You're right. I was just busting. I was just busting balls. I mean, in the end, right? You need to have...in the end, it's different flavors of containerizing Linux, right? Except for Azure and those people. Whatever, man. There's a lot of .NET developers in the world, and they technically are people, too. Legally, they're humans. \n\nJUSTIN: They have high therapist bills. \n\nWILL: Yeah, yeah, Kubernetes and Docker and all that stuff, they can flavorize with different flavors of Linux pretty well. We can do cross-platform as long as we heavily water down what the notion of platform is, where it's like, hey, you can run both kinds of Linux, Alpine, no problem. You know what? You can even have Ubuntu. Suit yourself [laughter]. \n\nMIKE: You're hitting on a key point there. If you are using a pretty...and it goes back to what you said before about the operating system. If you use something that's standard underneath, and you're doing something that's really standard, that is, spinning up virtual machines within a cloud that provides compute, right? Then that is pretty commoditized. That's straightforward. But what if you want to do functions like AWS Lambda? \n\nJUSTIN: Lambdas?\n\nMIKE: Exactly. Is that going to exactly map from platform to platform? And the answer --\n\nJUSTIN: Nah, you shouldn't do...I've been burned too much by Lambdas [laughs]. I don't recommend them anymore. \n\nMIKE: I'm not speaking for or against. My argument is [laughs] that once you diverge from doing something that is extremely well-proven and straightforward on a standard platform, then it starts to get platform-specific, and then the costs start to skyrocket because then you have to...then you have to split, right? Now you're not really doing the same thing anymore, and it goes back to the cross-platform. Yeah, you can do the basics pretty straightforward, and then, all of the cost comes into everything that goes beyond the basics. And if you have to make it work across both sides, it's probably not going to. \n\nJUSTIN: So, is that the lesson you should take? Like, if you are straying from the path, that should be a gigantic code smell or architecture smell. And you should really analyze your requirements to see, are they really forcing me to go that way?\n\nWILL: My takeaway personally is the eternal lie of cross-platform development because, inevitably, developers are going to...it's like a game to them. They’re like animals. They can't help themselves. \n\nJUSTIN: [laughs]\n\nWILL: It’s a compulsion. It’s a sickness, a disease. They're going to find the edge of the map, every time. They're driven towards it like conquistadors. I don't know what pushes them, but they're always going to do it. And they're always going to find the edge of the map. And they're going to write some ****. And it can't go down. And then, you start again over and over.\n\nJUSTIN: Haskell. Haskell.\n\nWILL: You know what I mean? Some kind of thing, man. \n\nMIKE: Let me throw a metaphor out here. You're going to get married [laughter]. \n\nWILL: Oh, man. Oh, it’s getting hot. You’ve been trying to [inaudible 24:32].\n\nMIKE: You keep your finances separate. You carefully schedule times so that neither of you have any disruption to your schedule with your old friends. \n\nJUSTIN: [laughs] Why are you getting together again? \n\nMIKE: That's exactly where I'm going. Were you ever married? There's a tricky line here that sometimes if you're going to go to a provider, you have to accept that you're going with that provider. If you're going to go AWS, you're going to go Google Cloud. You're going to go Azure. There are some things you can probably do cross-platform, and there's other things that you probably can't. You've got to make a choice. Go back to the marriage [chuckles]. You've got to make a choice. If you're hedging and you haven't really committed yourself, it's probably not going to work out very well. I don't know. Thoughts? It's a metaphor. I don't know. \n\nWILL: Where does Larry Ellison as a divorced lawyer, like, fit into this equation? I'm trying to make the joke, and it's just not coming to me. \n\nKYLE: So, I'm thinking about this because I'm more of an Android fan and to the ecosystem talk here and, you know, considering that tooling. I have always looked at Apple and said, I don't want to be tied to an ecosystem. I don't want to be in that. I would prefer Android. Android allowed me that, like, what, 5, 10 years ago. Now you're either in the Google system. You're in the Samsung. \n\nLike, at some point, you do have to pick a marriage. It's not really, like, with all of our tooling, it feels like you're being pigeonholed into some type of a marriage, and you have to kind of accept it, at least I have, I feel like. Because if I want my watch to work with my phone, I got to pick a brand. I got to pick something. And what do you go with, and where do you settle? And yeah. \n\nWILL: I think that's maybe more of an interesting question than the eternal lie of cross-platform development, right? Like, how do you pick who you're going with? Because you are right. I'll say this straight up. Me, personally, in terms of back-end infrastructure, I'm a Linux ride-or-die. Whatever kind of server crap they've got, forget it. I'm not doing it. I won't. I won't do it. I also jumped on Apple, which I have misgivings about because I jumped on Apple, right? \n\nMaybe this is an illustrative example. I jumped on Apple because I was an indie app developer. And Android people don't pay anything, right? So, okay, so my choice was clear, right? I wanted to eat. And so, to have money to purchase food, I was going to have to do Apple instead of Android. And so, then I was stuck, and, philosophically, yeah, they rub me the wrong way. I believe in, like I said, I was rather militant in saying that all operating systems should be open source, without exception. I don't think anybody should have a closed-source operating system, and Apple ain't that way. And so, what’s a good way of choosing? Like, how do you pick the pony, you know, that you're going to ride? \n\nJUSTIN: So, I'd like to give you guys an example of what we're facing right now, and I'll pick your brains a little bit. Three advisors. So, we are trying to decide between JFrog Artifactory and CodeArtifact. JFrog, the big industry name, CodeArtifact, not so big, but still, they get the job done. We need some place to park our builds, and be available, and we can validate them and everything, right? And we can have them part of our build process, and we can do dependent libraries and all this and that. And so, there are a lot of questions about which way we should go. JFrog, obviously, is the big industry one, but they want 150,000 a year.\n\nWILL: Woooo.\n\nJUSTIN: Right? But all the tools work with it. \n\nWILL: I want to say two things, like, one, as a permanent JFrog user, JFrog sucks, and I hate them.\n\nJUSTIN: [laughs] I'm going to put that down on my con list. \n\nWILL: Yes. Two, this is really, like, meta, and it doesn't have a lot to do with engineering. It has, I think, more to do with finance and the rise and fall of empires. So, for me, I believe that every company kind of follows the same arc. Some people have a longer arc with better management. Some people have a shorter arc for various things, like, not going well, but every company eventually calcifies, you know what I mean? And then, like, the sort of the MBA managers take over, or a hedge fund buys them, or they're trying to make their quarterly results, and things like engineering get squeezed to death. And then, their feature set, and their agility, and stuff like that locks in place.\n\nNow, what's the upside to that? The upside to that is they're the standard, and everybody has to meet the standard. And they have to be the thing. They suck. They're going to continue to suck. They're going to get worse every year, forever, until they collapse because they've locked it, so the concrete is set. This is what you get. And every year, it will get worse. \n\nSo, what's the other side? You got these new, up-and-coming companies. And they're hungry, and they're modern, and they're building things better because the second time you build anything, you do a better job, right? What are the dangers there? The danger there is they don't make it, right? The danger there isn't support and tooling around them. The danger there is they, in turn, do not get to make their numbers for their IPO, and they get bought by private equity, and they fire everybody. And then, they are in turn setting concrete, right? And then, they start to, you know, their inevitable slow degradation. And so, you're sort of, like, jumping on a wave, right? \n\nThe new up and comer they're going to do a better job because they can avoid all the landmines that JFrog hit, right? They exist because they didn't screw up the same way that Artifactory did. If Artifactory did it right, these guys they'd have no sunlight. Like, they wouldn't have anything. So, the question becomes, well, all right, are they big enough to be viable at the scale you're at? And that is a question that I can't answer because I got to sign JFrog. And I think about this stuff the absolute bare minimum that I can, other than cursing JFrog's name when they do me, which happens quarterly.\n\nKYLE: That is something that we did go through, very similar story. Nexus is what we were using, and CodeArtifact was something that was on the table as well as JFrog. And we ultimately landed on the tooling that had the best support for our packages and had probably the best support for infrastructure as code, which happened to be JFrog. So, that's kind of what it came down to for us. What it comes down to for you guys, I don't know. I mean, we are a very vast, what, language base here at Acima, so we had to support a lot. \n\nMIKE: Will got down deep there, talking about the innovator's dilemma. Big companies get stagnant and then they get...an innovator comes in, and the big founding company laughs at them like, well, they don't offer any of the features we do [laughs]. But they're cheap, and they work well for the people who want to use them. And, surprisingly, there's a tipping point, and, eventually, the old company becomes obsolete. You know, there’s Standard Oil [laughs], you know, a lot of the railroad companies, you know, you think about it, they were huge. Enormous. And -- \n\nWILL: Standard Oil still exists, baby. They changed their nameplate, but they're still around. I forget which one they are. Like, are they Exxon? Are they...I think they're Exxon.\n\nJUSTIN: Going back to the tech world, you look at the rise of Wiz, like, specifically in the security space, Wiz was nothing until...I think the company was founded in, like, 2018, something like that. And it was a company that had to rapidly and cheaply connect to and identify all the processes that could exist on a cloud infrastructure, you know, multiple different kinds of services, multiple different versions, multiple different data stores, and everything else, and be able to present that in a great format in a cheap way. And they had to compete with the other scene companies or the existing security monitoring companies. \n\nBut, basically, this, what, six-year-old company turned down a 20-billion-dollar buyout offer from Google because they thought that they were worth more than that, so 6 years, 20-plus billion dollars. But it's a classic example of somebody, you know, coming in and just wiping the floor with existing competitors because turns out that those existing companies, they had a large feature set. But they didn't, you know, probably most of the people didn't use half their features that they had. The industry moved on. And Wiz was able to, you know, rather than try to maintain these old feature sets, Wiz was able to come in and build exactly what people wanted and do it in a cheap manner that attracted all of the industry folks to switch security monitoring systems. \n\nAnd, you know, it’s nuts in some ways. But I think it's a perfect example of somebody coming in and creating exactly what people need at a price point they need, and people recognizing for them, and yeah, so good on Wiz. And I feel bad for all the other companies in the space because they took a haircut, massive haircut. \n\nWILL: Yeah. And when you’re betting on sort of, like, startups and stuff like that, like, you're rolling the dice, right? I mean, you are rolling the dice to a large degree, right? I read a very interesting article about OpenAI and how they actually might be screwed. I don't know, you know, like, generative AI is not my deal, really. Like, I've used a bunch of it, right? I’m playing with all the toys as they come off the assembly line.\n\nBut, basically, what they were saying is the model stuff has achieved an asymptotic level of goodness, right? And Facebook is just giving their stuff away. They're pulling a page out of the standard big company playbook and saying, like, we'll just give it away for free because we make money on ads, but we could starve you out, and you'll just die, and then we win, which, okay, right? \n\nAnd so, generating the large language models that's asymptotically valueless, and everything is going to go around tooling and shaping the data, in such a way that it can be consumed by these models. It was an interesting concept but more broadly to what we're talking about, that you're betting on this startup, this new idea, right? And so, what are you going to bet on? I know I have some clients who are operating on OpenAI models. And I'll be like, “Hey [laughter], how much are you paying OpenAI? Is Llama 3 good enough? Because if Llama 3 is good enough, I bet you'd save some money paying me to swap you over because OpenAI ain't cheap, you know?”\n\nJUSTIN: So, I have a great example of that. Last month...it’s a Utah Java users’ group. They invite people to come present every month. A company CEO founder from a company called...what was it? Qualiti.ai. They do automated QA for companies. And, basically, they automatically create tests that will test your product end to end, and they will maintain themselves basically. And they spent...prior to, what was it, 2 years ago, they spent tons and tons of resources developing their own models. And all their resources went in to train their own models and everything, and that was the number one expense.\n\nAnd then, and it was like the thing that made them valuable for these other companies, their clients were these models that could go and create these things. And then, OpenAI comes in and, specifically, ChatGPT. And they came in with this general model, and with the general model, it wiped their...all the stuff that they made was useless because it was, like, next generation or two or three generations beyond what they were doing.\n\nAnd this guy, the CEO, looked at it, and he was like, “I've just spent the last six years of my life trying to make this work, and I made a mediocre product compared to what OpenAI was.” So, he had to make the really, really painful decision to examine what his company actually did. And what his company did was not train models; it was provide a way for companies to create automatic QA.\n\nSo, once he recognized that his value add wasn't the models, rather it was giving people these automatic tests, then he made the decision to throw away all the training that he did. And he basically contracted with OpenAI, and all the automated QA things are now just API calls into OpenAI. And he's doing his best to make that third-party agnostic. But it's just like, OpenAI was, like, head and shoulders above all the other competitors for his use case. So, it was just like...it goes back to, you know, what are you trying to do as an engineering org? And recognizing the value that you add and getting the best tool for the job when you're doing buy versus build.\n\nWILL: Right? Never build anything that isn't directly related to your core value add. Are you a computer scientist, you know what I mean, convolutional neural networks research company, and you're the best in the world at that? Or are you a QA company that uses these neural networks? Like, the neural network stuff, like, that's heavy-duty, man. Like, we're still in, you know, very, very early days with all that tooling and building all that stuff and stuff like that. \n\nLike, I was trying to get...and I'll tell you how I know it worked in early days because I was trying to get one of those image generation models running on my local computer. It was a real pain in the ass, and all the documentation sucked. When I find myself on a forum, like, if I find myself on a forum page looking for something, I'm like, oof, all right, look at me, Oregon trailing this thing. \n\nJUSTIN: [laughs] You're going to die of dysentery, man. \n\nWILL: Wouldn't be the first time. \n\nMIKE: Have you all read the...It's by Richard Sutton. He published something years ago called The Bitter Lesson. He had learned that a number of companies will spend years building this custom machine learning model to match their use case. And they'll come up with all these tricks and do everything just perfectly to eek out just a little bit more performance. And another company comes along that uses just a dumb algorithm. And they throw a bunch of compute and data at it, and it works better. Then [laughs] they were able to accomplish all these years of work. That's the bitter lesson. Then, in the end, a simple algorithm and a ton of compute and data win every time. \n\nWILL: Yeah, yeah. No doubt. No doubt. No arguments there. I think it's another topical tech in the news today. It's amazing how many amazing open-source projects, and products, and platforms, and such are really just the result of a VC-funded company blowing their budget and imploding in an altruistic manner [laughter]. It’s WordPress. WordPress, right? \n\nJUSTIN: WordPress.\n\nWILL: Automatic, right? Automatic. Invented WordPress. No. No. WordPress is a VC failure. They built this beautiful code temple, and then they just abandoned it. And good, old Matt he rolls in, inherits the whole thing, plants a flag. That's WordPress, baby, open source. But if you don't want to host your own thing, you can pay me, you know. WordPress was not...he didn't invent WordPress. Like, Ruby on Rails is actually one of very few, you know what I mean? Look at good, old Java. How's Sun doing? Not so good. \n\nJUSTIN: Oracle's doing fine. \n\nMIKE: [laughs]\n\nWILL: Oracle's doing...yeah, Oracle's doing fine because, well, yeah, anyway. Yeah, Oracle's lawyers are doing fine. \n\nJUSTIN: True story.\n\nWILL: I actually think Oracle, the technology company, is not so great, to be perfectly honest with you. I know there are Oracle databases in the world, and I know your bill goes up every year. But I don't know how many new Oracle databases are being spawned in the wild anymore. \n\nJUSTIN: No, everybody --\n\nWILL: I don't know how many people have paid for that Java license to be perfectly blunt.\n\nJUSTIN: Yeah, OpenJDK. \n\nKYLE: Something you kind of glazed over there, in the open-source community, too; it's kind of amazing how many of the end products by the larger companies are just wrappers of open-source products. Just for instance, today, I was looking at upgrading Packer only to find out that the Azure Image Builder is just a wrapper of the Packer software. That's like, so [laughs], I mean, everybody uses these smaller pieces, you know, in the open-source community, whether or not it's them hosting it themselves and having you pay for it, or just a tool that they provide you as, you know, a paid service. \n\nWILL: There you go.\n\nMIKE: We've talked a lot about tooling, and there really hasn't been one conclusion but a lot of different threads [chuckles]. There's not easy answers here. But sometimes you got to make a choice, and you might get it wrong. But you got to consider those trade-offs. \n\nWILL: Yeah, I feel like this is our least conclusive one to date. Honestly, you know what I mean, like, so, remember, kids, any choice you make is probably wrong and sucks, no matter what [laughter]. \n\nKYLE: If it doesn't suck now, it will later? \n\nWILL: Happy Friday! \n\n[laughter]\n\nMIKE: It's a bitter lesson, but an important one [laughs]. \n\nWILL: Thanks, comrades. All right, well, I'll go get started on the weekend drinking [laughter].\n\nMIKE: Until next time.","content_html":"In this episode of the Acima Development Podcast, the panel dives into the complexities and consequences of choosing the right tools for software development and engineering. Justin opens with a story from his first job, where his team implemented an Oracle Customer Management System that ultimately led to disaster. The system, despite promises of extensive customizability and robust functionality, failed spectacularly due to performance issues, particularly with search speed, which took minutes per query. This failure, which ended in a costly rollback to the previous system, highlighted significant lessons about the importance of realistic testing, validating vendor claims independently, and having fallback plans for major tooling changes.
\n\nAs the discussion progresses, the team shares additional insights on the risks associated with both large, established tech tools and smaller, emerging ones. They debate the pros and cons of "buy vs. build," generally advocating for buying established solutions rather than building in-house, particularly when these tools fall outside the company’s core value proposition. However, they recognize that established tools, while more reliable, often become stagnant, and smaller, innovative companies may offer better solutions that come with risks, such as sustainability and long-term support. A balance is often difficult to strike, and each choice comes with potential downsides, whether it's cost, dependency, or eventual obsolescence.
\n\nThe episode closes on a broader note about the inherent "bitter lesson" of technology: that simple algorithms powered by ample resources often outperform intricate, specialized solutions. This leads to a candid reflection on open-source contributions, corporate influence, and the evolving tech landscape, where many advancements are the result of unsustainable VC-backed ventures. The hosts humorously conclude with the advice that any tooling decision likely involves trade-offs and inevitable challenges, encouraging listeners to accept the imperfect nature of these choices.
\n\nTranscript:
\n\nEDDY: Hello and welcome to Acimas Dev Podcast. Today, we have an awesome crowd, right? We have Mike; we have Kyle; we have Justin, and Melina, right? And today we decided upon popular opinion, right? That we'd be talking about tooling, right? Should you be married to a tool, pros and cons of switching to a new tool, when to do it, why to do it. And Justin actually was talking off-air on having a horror story behind something that sort of segues into this. So, Justin, by all means.
\n\nJUSTIN: All right. So, what I have is a story from my first real programming job, and it was the decision to move to Oracle. Boy, I don't even know what it was called, but it was an Oracle customer management system, the CMS. And, if you're a programmer, sometime in your career, you will either write or rewrite a customer management system. That is, like, a given. I was lucky enough to do it or unlucky enough to do it on my first job. And the decision was made at levels far above me that we were going to do Oracle’s customer management system, which was, you know, Oracle a huge company, huge corporation, and it had a tool for everything and, especially, it had a tool for managing customers that we had never used before.
\n\nAnd the thing about it was is, like, they advertised it as, hey, you can use this tool, and you can customize it any way you like it because we have a field for everything, and you can add your own custom fields. And every field could be validated, and every field could be a search, and every customer can have any number of objects associated with the customer. And so, it was everything to everybody. And the VP in charge was like, oh, this is going to be awesome.
\n\nAnd we were a medical company that did medical tests. And we had customers in the numbers of tens of thousands, if not pushing a hundred thousand. So, the order of magnitude was actually not that big. But as we went along, we got given a deadline saying, “Hey, we are releasing this day, do or die.” And by gosh, we did it. We released that day. And come to find out the next day that nobody could use it. It wasn't a login issue; rather, it was a performance issue. Every single search took upwards of five minutes.
\n\nAnd it was just a horrible, horrible experience. And it slowed our customer relationship team down to a crawl. Phone calls couldn't be completed. Doctors couldn't update their customer fields and things like that. And for the next, I think it was week and a half, we tried to fix it. And then, the CEO came in and said, “Screw it. You guys are moving back to the old way.”
\n\nAnd, ultimately, we ended up throwing that away. And it was a, I don't know, I think it was on the order of a 5 million project, which some people think that's huge. Some people think that's not that huge. But to us, it was months and months of work and licensing fees and data. And it's actually probably over a year of work, come to think of it.
\n\nBut the key there was that it was an environment that nobody really knew how to do, an infrastructure that was new to folks. I mean, we'd done Oracle databases before, but, all of a sudden, we were asked to develop within the Oracle framework and using their tools, and it just sucked. And not only that, but our test environment was certainly not populated with a large enough data set to validate everything. And I believe that the fallout from that was the...I think that VP got fired. The rest of us just, you know, kept on going. And so, that's, like, the tale as old as time is, you know, some middle manager or upper middle manager gets canned because their project was a horrible implementation.
\n\nEDDY: So, what's the underlying problem here? Was it lack of training? Is it the fact that you're developing in Java, or is it just Oracle in general [laughs]?
\n\nJUSTIN: I don't know. There's probably plenty of blame to go around, right? But the lessons that I learned was the fact that you cannot depend on salespeople for the numbers that they give you. You have to prove it out yourself. And then, you have to test with as real production data as possible, and that includes complexity. That includes number of rows. That includes number of transactions, all of that.
\n\nAnd you actually should have a rollout period where you have a beta with production data for X number of time because it basically shut the company down for a week and a half while we tried to make it work because they didn't have a fallback. And, luckily, they were able to fall back. They were able to roll back to the old way after a week and a half, but it was just...it just sucked.
\n\nAnd, also, from the developer point of view, using the Oracle tools...because we had to use their packages. We had to use their architecture. Previously, we were just using their database as a data store. But now we were using their libraries. We were using their SDK a little bit. We were using their, you know, all these things, and it just sucked. Long story short, Oracle sucks, and use Postgres [laughs]. Even back then, Postgres was a thing, so...
\n\nEDDY: I'm just surprised the company was willing to go a whole week with production being down until they finally decided, oh, you know what, cut the losses [laughs]. Let's go back to...
\n\nJUSTIN: It's funny because different companies have different tolerances. This was a medical company. And so, when I say the whole company was shut down, I mean just, like, the customer side. We were still doing tests and things like that. And so, there was a certain amount of tolerance there for a couple of days. But the CEO was just like, you know, after a little while, he just couldn't take it anymore.
\n\nKYLE: So, with that, were you privy to why they concluded on Oracle at all? And was there any competition why that tooling was selected?
\n\nJUSTIN: That was all so far above me.
\n\nKYLE: Far above you.
\n\nJUSTIN: I was fresh out of college, but, man, it was a trial by fire. And just to follow up that a little bit, we were a development team of about 20. Over the course of the following year, I think they lost 15 of the engineers just because, you know, there were other problems with that organization, technology-wise. That was kind of the same time I left as well.
\n\nMIKE: Yeah, I can say it's not always the big players. In my first job [laughs], we switched to a new customer management system, and it was built by, like, some guy in his garage. And it really was just somebody [laughs], I think, the CEO knew. And the entire thing, the entire system, was built around stored procedures in SQL Server because [laughs] they provide functionality to call out to externally compiled binaries, which, of course, you don't have the source code for that he had built. And there's no source code control, right? Because it's all just implemented straight inside the database. And there's no searching. You just have to know which store procedure to look at or look through them one by one until you find what you're looking for. And that was the entire system.
\n\nAnd we bought it, and then, of course, the person who we bought it from wasn't available for assistance. So, it was on us to manage it ourselves. And we kept that tool [laughs] for as long as I was at that company, meaning I learned how [laughs] to navigate through every bit of that code in order to make it work.
\n\nThere's a lesson here about how you provision tools at a company, I think. As a company, whoever you are, you're probably not a customer management system company. And if you're putting all of your efforts into building that in-house, you're diluting your expertise in what you’re probably supposed to specialize in, whether it be medical products, or some sort of medical services, or financial services, or whatever the case may be. You are focused on somewhere outside your area of core expertise, and that often goes badly. I am, in general, in favor of buying the tools that do the right thing, that do the right job. But there's some caveats in there, right? It's the right tools. You go through some processes that involve people actually using it.
\n\nWILL: Yeah. I mean, you should never, I don’t know, you should never invest in a tool outside, in my opinion, I don't think, without an overwhelming reason, you should never invest in any kind of tooling that's outside your sort of core value proposition past a certain scale. Because there's people who've done stuff where Facebook basically rewrote PHP, which is ludicrous for anybody but Facebook.
\n\nEDDY: They built their own framework, too, right? Like, it's insane.
\n\nWILL: Yeah, yeah, absolutely. And building their own framework, I think that one's, ah, you know, like, how do I put it? I think that proposition is dubious. I think React might be stunting a little bit, which is because if they invested that amount of resources into one of the existing things and just fixed the problems that they had with it, would they really get a worse result? I bet not. But, eh, whatever, you know, probably [inaudible 10:31], you know, like, they have their thing, and it's really deep, and they did good, and they’re like, React Native is actually really dope these days, you know what I mean? For, like, cross-platform, mobile, like, that's it. That's the game. And they actually did it, and, like, it kind of sucks for web now, but that's fine. Anyway, that's a tangent. Yeah, but don't invest in tooling outside of your core value proposition.
\n\nMIKE: You're saying buy, not build
\n if it's –
WILL: Always. Always. Always. Always. Always. Always buy, not build. Never. As an engineer, just...engineering's the worst. Just don't do it.
\n\nJUSTIN: [laughs]
\n\nEDDY: So, you're basically saying don't build my own AWS system, right?
\n\nWILL: Is that a sub-tweet? Like, if you're discussing it, like [laughter], entirely, like, I'll be the hatchet man. They can't fire me. Literally can't. So, like, no [laughter].
\n\nMIKE: One nice thing about not being employed at Acima is you can speak your mind [laughter].
\n\nWILL: You know what, actually, you know what I mean? Like, an engineer, one of the core engineering mindsets is everything is a trade-off, right? Everything's a trade-off. And I'll say this, man, because another...it's not a requirement to be an engineer, but they [inaudible 11:52]. I'm a miserable cheap bastard, and AWS is expensive. These people have been tightening the screws pretty hard. I've been seeing some bills, and I've been like, how much does a rack cost these days [laughter], you know? Like, racks aren’t that bad. It's not so bad. I could plug cables.
\n\nKYLE: Well, and a lot of the other cloud providers are up and coming, right? And they're kind of cheaper at the moment. So, yes, you get a lot of the large support from the Azures, the Googles, the Amazons. But there's others that, depending on what you're doing, they're completely viable.
\n\nWILL: I mean, large support. I've never been large enough to get large support, so I don't give a ****.
\n\nKYLE: Exactly.
\n\nWILL: But I also, like, my experience with AWS is twisting their arm to fix something they broke in the first place. I was like, oh, man, us-east-1 is down again. I better email Amazon so they can tell me to go stuff it. I'm like, all right, cool. There it is, us-east-1 down again. What are we going to do about it? We'll get back to you. Cool. Thanks for the support.
\n\nKYLE: And that kind of brings up a good point. You're relying on a tool to provide you a service, and you're running into a situation where you're like, hey, your product’s down in a certain zone. What are they recommending? Well, become Multi-AZ, then. Become multi-region. Buy more of our product. Use more of our services. And it's like, where do you define the line? And it's, okay, do you go into more regions? Do you invest more in their product? Or do you go multi-cloud, or do you go hybrid, or, you know, like, how do you solve that? Because is the right answer going multi-region and putting more money in their pockets at that point?
\n\nEDDY: I think that --
\n\nWILL: Is the answer, like, is the answer, like, how many cancellations am I going to get really? Because, like, okay, we have to always be up. We have to always be up. And I'm like, actually, no. If you can't get a TV today, you'll be okay. You're going to be all right. It’s okay.
\n\nEDDY: So, can you ever consider --
\n\nWILL: But can you check that cap spreadsheet, you know what I mean, before I go on vacation? It's like, well, maybe you hit it from the plane. Like, a lot of this stuff isn't actually a life-or-death situation. And to the extent that it doesn't cause churn or cancellations or bottom-line stuff, you know, like, I know we're not allowed to say it out loud, and it's not the Will's boss podcast. So, again, I could just say what I want, but I mean, like, eh, [inaudible 14:52].
\n\nJUSTIN: It totally depends on what company you're working for. Because I worked at a FinTech firm that, the downtime was measured in millions per minute, and nobody was going to die, but it was literally millions per minute.
\n\nWILL: I don't know, man. FinTech and downtime goes together like peanut butter and jelly [laughs].
\n\nJUSTIN: No, this --
\n\nWILL: I have worked with a financial system before. Y'all people [laughs].
\n\nJUSTIN: Yeah, no, this...I’m trying to [crosstalk 15:28]
\n\nWILL: ...Trading type stuff?
\n\nJUSTIN: Yes. Yes.
\n\nEDDY: I mean, I'd argue that part of the conversation that happens when switching tooling is cost, right?
\n\nKYLE: Yeah, big time.
\n\nEDDY: So, if at one point the tooling that you're using becomes way too expensive, either to maintain or to license, I think conversations will be had about switching to a different system, right? I always advocate to having a fallback, right? So, if you're using Amazon exclusively for your hosting service, if one of them goes down, like, one of the regions goes down, like, you're done. And so, conversations need to be had about what do you do in that scenario? Do you go to a different provider that's not Amazon? And if you do, what's the cost? What's the risks? I think that's something that needs to...
\n\nKYLE: It's a conversation of expertise, too, because a lot of the time the company will invest not only in a cloud, but it will invest in engineers that are specialized in that cloud. And so, then, if you're going from Amazon to Google, well, now you got a bunch of Amazon cloud engineers. And what does it cost then to switch to Google Cloud? And that's sometimes a lot more costly than just eating the increased billing cost.
\n\nWILL: And also, man, in all honesty, it's like a parallel algorithm. You might have to rewrite your whole thing to be like, oh yeah, that data center is down. It's like, oh, I'll just use the other one. Okay. Whoa! Whoa! Whoa! This database went out. What happened to all the transactions? And is that cool? That was...whoa! Whoa! Me and Mike spent, what, a year reading a book on that, and it was heavy duty, man [laughter].
\n\nJUSTIN: So, I think there are a couple of things that you need to look at when you are deciding which architecture you want to be. And I'm glad you brought up that Google Cloud versus AWS. If you can write your infrastructure as code, which, you know, you guys are, and we are, and most people are these days, you can be provider agnostic to a certain extent and be able to, you know, the migration from AWS to Google Cloud or to Azure would hopefully be less painful because you've got everything defined in your Terraform or, hopefully, using Terraform, maybe not CloudFront or whatever.
\n\nBut as you go along, I think that is the key. You design your systems to be implementation agnostic. And thus you can, if something better comes along, you can make the switch as painlessly as possible. That's not to say that's easy, but I think that's the ideal.
\n\nWILL: The eternal lie of cross-platform development [laughter], hmm, [inaudible 18:50] so much to do that.
\n\nJUSTIN: Hey, I was a Flutter developer for four years.
\n\nWILL: Oh, I'm so sorry --
\n\nJUSTIN: And it actually worked out. It worked out. iOS and Android, it can happen [laughs].
\n\nWILL: Sure.
\n\nEDDY: Just use Kotlin.
\n\nKYLE: Just use Kotlin [laughs]?
\n\nJUSTIN: Kotlin multi-platform isn't there yet, but it's getting better. Anyway...
\n\nWILL: Nor will it be because iOS is actually, like, in the back end is actually...iOS is really stingy on the RAM. They don't tell you how much RAM an iPhone has, and that's not because the numbers are too good.
\n\nJUSTIN: No, no [laughs], they aren't. iPhones suck that way [laughter].
\n\nWILL: They really do. Well, I mean, you could say the iPhone sucks, or you could say the JVM. JVM, come on, buddy.
\n\nJUSTIN: Oh, wow.
\n\nWILL: Do you really need that much?
\n\nEDDY: Which is why having open-source software is really important.
\n\nWILL: Yes, absolutely. The operating system should be open source. No operating system in the world ever, ever, ever should be closed source. It shouldn't be allowed. It should not be allowed. But I don't think that is podcast for the day [laughter].
\n\nJUSTIN: No, but you look at the couple of other things that you have going on there in terms of what is running your actual system. And if you have everything dockerized, you have everything set up as infrastructure as code, you can have it all be pretty provider agnostic because you could run your Kubernetes on AWS. You can run that on Google Cloud. You can run that on Microsoft Azure. And the principles are mostly the same theoretically on this specific thing. I don't know.
\n\nWILL: No, you're right. You're right. I was just busting. I was just busting balls. I mean, in the end, right? You need to have...in the end, it's different flavors of containerizing Linux, right? Except for Azure and those people. Whatever, man. There's a lot of .NET developers in the world, and they technically are people, too. Legally, they're humans.
\n\nJUSTIN: They have high therapist bills.
\n\nWILL: Yeah, yeah, Kubernetes and Docker and all that stuff, they can flavorize with different flavors of Linux pretty well. We can do cross-platform as long as we heavily water down what the notion of platform is, where it's like, hey, you can run both kinds of Linux, Alpine, no problem. You know what? You can even have Ubuntu. Suit yourself [laughter].
\n\nMIKE: You're hitting on a key point there. If you are using a pretty...and it goes back to what you said before about the operating system. If you use something that's standard underneath, and you're doing something that's really standard, that is, spinning up virtual machines within a cloud that provides compute, right? Then that is pretty commoditized. That's straightforward. But what if you want to do functions like AWS Lambda?
\n\nJUSTIN: Lambdas?
\n\nMIKE: Exactly. Is that going to exactly map from platform to platform? And the answer --
\n\nJUSTIN: Nah, you shouldn't do...I've been burned too much by Lambdas [laughs]. I don't recommend them anymore.
\n\nMIKE: I'm not speaking for or against. My argument is [laughs] that once you diverge from doing something that is extremely well-proven and straightforward on a standard platform, then it starts to get platform-specific, and then the costs start to skyrocket because then you have to...then you have to split, right? Now you're not really doing the same thing anymore, and it goes back to the cross-platform. Yeah, you can do the basics pretty straightforward, and then, all of the cost comes into everything that goes beyond the basics. And if you have to make it work across both sides, it's probably not going to.
\n\nJUSTIN: So, is that the lesson you should take? Like, if you are straying from the path, that should be a gigantic code smell or architecture smell. And you should really analyze your requirements to see, are they really forcing me to go that way?
\n\nWILL: My takeaway personally is the eternal lie of cross-platform development because, inevitably, developers are going to...it's like a game to them. They’re like animals. They can't help themselves.
\n\nJUSTIN: [laughs]
\n\nWILL: It’s a compulsion. It’s a sickness, a disease. They're going to find the edge of the map, every time. They're driven towards it like conquistadors. I don't know what pushes them, but they're always going to do it. And they're always going to find the edge of the map. And they're going to write some ****. And it can't go down. And then, you start again over and over.
\n\nJUSTIN: Haskell. Haskell.
\n\nWILL: You know what I mean? Some kind of thing, man.
\n\nMIKE: Let me throw a metaphor out here. You're going to get married [laughter].
\n\nWILL: Oh, man. Oh, it’s getting hot. You’ve been trying to [inaudible 24:32].
\n\nMIKE: You keep your finances separate. You carefully schedule times so that neither of you have any disruption to your schedule with your old friends.
\n\nJUSTIN: [laughs] Why are you getting together again?
\n\nMIKE: That's exactly where I'm going. Were you ever married? There's a tricky line here that sometimes if you're going to go to a provider, you have to accept that you're going with that provider. If you're going to go AWS, you're going to go Google Cloud. You're going to go Azure. There are some things you can probably do cross-platform, and there's other things that you probably can't. You've got to make a choice. Go back to the marriage [chuckles]. You've got to make a choice. If you're hedging and you haven't really committed yourself, it's probably not going to work out very well. I don't know. Thoughts? It's a metaphor. I don't know.
\n\nWILL: Where does Larry Ellison as a divorced lawyer, like, fit into this equation? I'm trying to make the joke, and it's just not coming to me.
\n\nKYLE: So, I'm thinking about this because I'm more of an Android fan and to the ecosystem talk here and, you know, considering that tooling. I have always looked at Apple and said, I don't want to be tied to an ecosystem. I don't want to be in that. I would prefer Android. Android allowed me that, like, what, 5, 10 years ago. Now you're either in the Google system. You're in the Samsung.
\n\nLike, at some point, you do have to pick a marriage. It's not really, like, with all of our tooling, it feels like you're being pigeonholed into some type of a marriage, and you have to kind of accept it, at least I have, I feel like. Because if I want my watch to work with my phone, I got to pick a brand. I got to pick something. And what do you go with, and where do you settle? And yeah.
\n\nWILL: I think that's maybe more of an interesting question than the eternal lie of cross-platform development, right? Like, how do you pick who you're going with? Because you are right. I'll say this straight up. Me, personally, in terms of back-end infrastructure, I'm a Linux ride-or-die. Whatever kind of server crap they've got, forget it. I'm not doing it. I won't. I won't do it. I also jumped on Apple, which I have misgivings about because I jumped on Apple, right?
\n\nMaybe this is an illustrative example. I jumped on Apple because I was an indie app developer. And Android people don't pay anything, right? So, okay, so my choice was clear, right? I wanted to eat. And so, to have money to purchase food, I was going to have to do Apple instead of Android. And so, then I was stuck, and, philosophically, yeah, they rub me the wrong way. I believe in, like I said, I was rather militant in saying that all operating systems should be open source, without exception. I don't think anybody should have a closed-source operating system, and Apple ain't that way. And so, what’s a good way of choosing? Like, how do you pick the pony, you know, that you're going to ride?
\n\nJUSTIN: So, I'd like to give you guys an example of what we're facing right now, and I'll pick your brains a little bit. Three advisors. So, we are trying to decide between JFrog Artifactory and CodeArtifact. JFrog, the big industry name, CodeArtifact, not so big, but still, they get the job done. We need some place to park our builds, and be available, and we can validate them and everything, right? And we can have them part of our build process, and we can do dependent libraries and all this and that. And so, there are a lot of questions about which way we should go. JFrog, obviously, is the big industry one, but they want 150,000 a year.
\n\nWILL: Woooo.
\n\nJUSTIN: Right? But all the tools work with it.
\n\nWILL: I want to say two things, like, one, as a permanent JFrog user, JFrog sucks, and I hate them.
\n\nJUSTIN: [laughs] I'm going to put that down on my con list.
\n\nWILL: Yes. Two, this is really, like, meta, and it doesn't have a lot to do with engineering. It has, I think, more to do with finance and the rise and fall of empires. So, for me, I believe that every company kind of follows the same arc. Some people have a longer arc with better management. Some people have a shorter arc for various things, like, not going well, but every company eventually calcifies, you know what I mean? And then, like, the sort of the MBA managers take over, or a hedge fund buys them, or they're trying to make their quarterly results, and things like engineering get squeezed to death. And then, their feature set, and their agility, and stuff like that locks in place.
\n\nNow, what's the upside to that? The upside to that is they're the standard, and everybody has to meet the standard. And they have to be the thing. They suck. They're going to continue to suck. They're going to get worse every year, forever, until they collapse because they've locked it, so the concrete is set. This is what you get. And every year, it will get worse.
\n\nSo, what's the other side? You got these new, up-and-coming companies. And they're hungry, and they're modern, and they're building things better because the second time you build anything, you do a better job, right? What are the dangers there? The danger there is they don't make it, right? The danger there isn't support and tooling around them. The danger there is they, in turn, do not get to make their numbers for their IPO, and they get bought by private equity, and they fire everybody. And then, they are in turn setting concrete, right? And then, they start to, you know, their inevitable slow degradation. And so, you're sort of, like, jumping on a wave, right?
\n\nThe new up and comer they're going to do a better job because they can avoid all the landmines that JFrog hit, right? They exist because they didn't screw up the same way that Artifactory did. If Artifactory did it right, these guys they'd have no sunlight. Like, they wouldn't have anything. So, the question becomes, well, all right, are they big enough to be viable at the scale you're at? And that is a question that I can't answer because I got to sign JFrog. And I think about this stuff the absolute bare minimum that I can, other than cursing JFrog's name when they do me, which happens quarterly.
\n\nKYLE: That is something that we did go through, very similar story. Nexus is what we were using, and CodeArtifact was something that was on the table as well as JFrog. And we ultimately landed on the tooling that had the best support for our packages and had probably the best support for infrastructure as code, which happened to be JFrog. So, that's kind of what it came down to for us. What it comes down to for you guys, I don't know. I mean, we are a very vast, what, language base here at Acima, so we had to support a lot.
\n\nMIKE: Will got down deep there, talking about the innovator's dilemma. Big companies get stagnant and then they get...an innovator comes in, and the big founding company laughs at them like, well, they don't offer any of the features we do [laughs]. But they're cheap, and they work well for the people who want to use them. And, surprisingly, there's a tipping point, and, eventually, the old company becomes obsolete. You know, there’s Standard Oil [laughs], you know, a lot of the railroad companies, you know, you think about it, they were huge. Enormous. And --
\n\nWILL: Standard Oil still exists, baby. They changed their nameplate, but they're still around. I forget which one they are. Like, are they Exxon? Are they...I think they're Exxon.
\n\nJUSTIN: Going back to the tech world, you look at the rise of Wiz, like, specifically in the security space, Wiz was nothing until...I think the company was founded in, like, 2018, something like that. And it was a company that had to rapidly and cheaply connect to and identify all the processes that could exist on a cloud infrastructure, you know, multiple different kinds of services, multiple different versions, multiple different data stores, and everything else, and be able to present that in a great format in a cheap way. And they had to compete with the other scene companies or the existing security monitoring companies.
\n\nBut, basically, this, what, six-year-old company turned down a 20-billion-dollar buyout offer from Google because they thought that they were worth more than that, so 6 years, 20-plus billion dollars. But it's a classic example of somebody, you know, coming in and just wiping the floor with existing competitors because turns out that those existing companies, they had a large feature set. But they didn't, you know, probably most of the people didn't use half their features that they had. The industry moved on. And Wiz was able to, you know, rather than try to maintain these old feature sets, Wiz was able to come in and build exactly what people wanted and do it in a cheap manner that attracted all of the industry folks to switch security monitoring systems.
\n\nAnd, you know, it’s nuts in some ways. But I think it's a perfect example of somebody coming in and creating exactly what people need at a price point they need, and people recognizing for them, and yeah, so good on Wiz. And I feel bad for all the other companies in the space because they took a haircut, massive haircut.
\n\nWILL: Yeah. And when you’re betting on sort of, like, startups and stuff like that, like, you're rolling the dice, right? I mean, you are rolling the dice to a large degree, right? I read a very interesting article about OpenAI and how they actually might be screwed. I don't know, you know, like, generative AI is not my deal, really. Like, I've used a bunch of it, right? I’m playing with all the toys as they come off the assembly line.
\n\nBut, basically, what they were saying is the model stuff has achieved an asymptotic level of goodness, right? And Facebook is just giving their stuff away. They're pulling a page out of the standard big company playbook and saying, like, we'll just give it away for free because we make money on ads, but we could starve you out, and you'll just die, and then we win, which, okay, right?
\n\nAnd so, generating the large language models that's asymptotically valueless, and everything is going to go around tooling and shaping the data, in such a way that it can be consumed by these models. It was an interesting concept but more broadly to what we're talking about, that you're betting on this startup, this new idea, right? And so, what are you going to bet on? I know I have some clients who are operating on OpenAI models. And I'll be like, “Hey [laughter], how much are you paying OpenAI? Is Llama 3 good enough? Because if Llama 3 is good enough, I bet you'd save some money paying me to swap you over because OpenAI ain't cheap, you know?”
\n\nJUSTIN: So, I have a great example of that. Last month...it’s a Utah Java users’ group. They invite people to come present every month. A company CEO founder from a company called...what was it? Qualiti.ai. They do automated QA for companies. And, basically, they automatically create tests that will test your product end to end, and they will maintain themselves basically. And they spent...prior to, what was it, 2 years ago, they spent tons and tons of resources developing their own models. And all their resources went in to train their own models and everything, and that was the number one expense.
\n\nAnd then, and it was like the thing that made them valuable for these other companies, their clients were these models that could go and create these things. And then, OpenAI comes in and, specifically, ChatGPT. And they came in with this general model, and with the general model, it wiped their...all the stuff that they made was useless because it was, like, next generation or two or three generations beyond what they were doing.
\n\nAnd this guy, the CEO, looked at it, and he was like, “I've just spent the last six years of my life trying to make this work, and I made a mediocre product compared to what OpenAI was.” So, he had to make the really, really painful decision to examine what his company actually did. And what his company did was not train models; it was provide a way for companies to create automatic QA.
\n\nSo, once he recognized that his value add wasn't the models, rather it was giving people these automatic tests, then he made the decision to throw away all the training that he did. And he basically contracted with OpenAI, and all the automated QA things are now just API calls into OpenAI. And he's doing his best to make that third-party agnostic. But it's just like, OpenAI was, like, head and shoulders above all the other competitors for his use case. So, it was just like...it goes back to, you know, what are you trying to do as an engineering org? And recognizing the value that you add and getting the best tool for the job when you're doing buy versus build.
\n\nWILL: Right? Never build anything that isn't directly related to your core value add. Are you a computer scientist, you know what I mean, convolutional neural networks research company, and you're the best in the world at that? Or are you a QA company that uses these neural networks? Like, the neural network stuff, like, that's heavy-duty, man. Like, we're still in, you know, very, very early days with all that tooling and building all that stuff and stuff like that.
\n\nLike, I was trying to get...and I'll tell you how I know it worked in early days because I was trying to get one of those image generation models running on my local computer. It was a real pain in the ass, and all the documentation sucked. When I find myself on a forum, like, if I find myself on a forum page looking for something, I'm like, oof, all right, look at me, Oregon trailing this thing.
\n\nJUSTIN: [laughs] You're going to die of dysentery, man.
\n\nWILL: Wouldn't be the first time.
\n\nMIKE: Have you all read the...It's by Richard Sutton. He published something years ago called The Bitter Lesson. He had learned that a number of companies will spend years building this custom machine learning model to match their use case. And they'll come up with all these tricks and do everything just perfectly to eek out just a little bit more performance. And another company comes along that uses just a dumb algorithm. And they throw a bunch of compute and data at it, and it works better. Then [laughs] they were able to accomplish all these years of work. That's the bitter lesson. Then, in the end, a simple algorithm and a ton of compute and data win every time.
\n\nWILL: Yeah, yeah. No doubt. No doubt. No arguments there. I think it's another topical tech in the news today. It's amazing how many amazing open-source projects, and products, and platforms, and such are really just the result of a VC-funded company blowing their budget and imploding in an altruistic manner [laughter]. It’s WordPress. WordPress, right?
\n\nJUSTIN: WordPress.
\n\nWILL: Automatic, right? Automatic. Invented WordPress. No. No. WordPress is a VC failure. They built this beautiful code temple, and then they just abandoned it. And good, old Matt he rolls in, inherits the whole thing, plants a flag. That's WordPress, baby, open source. But if you don't want to host your own thing, you can pay me, you know. WordPress was not...he didn't invent WordPress. Like, Ruby on Rails is actually one of very few, you know what I mean? Look at good, old Java. How's Sun doing? Not so good.
\n\nJUSTIN: Oracle's doing fine.
\n\nMIKE: [laughs]
\n\nWILL: Oracle's doing...yeah, Oracle's doing fine because, well, yeah, anyway. Yeah, Oracle's lawyers are doing fine.
\n\nJUSTIN: True story.
\n\nWILL: I actually think Oracle, the technology company, is not so great, to be perfectly honest with you. I know there are Oracle databases in the world, and I know your bill goes up every year. But I don't know how many new Oracle databases are being spawned in the wild anymore.
\n\nJUSTIN: No, everybody --
\n\nWILL: I don't know how many people have paid for that Java license to be perfectly blunt.
\n\nJUSTIN: Yeah, OpenJDK.
\n\nKYLE: Something you kind of glazed over there, in the open-source community, too; it's kind of amazing how many of the end products by the larger companies are just wrappers of open-source products. Just for instance, today, I was looking at upgrading Packer only to find out that the Azure Image Builder is just a wrapper of the Packer software. That's like, so [laughs], I mean, everybody uses these smaller pieces, you know, in the open-source community, whether or not it's them hosting it themselves and having you pay for it, or just a tool that they provide you as, you know, a paid service.
\n\nWILL: There you go.
\n\nMIKE: We've talked a lot about tooling, and there really hasn't been one conclusion but a lot of different threads [chuckles]. There's not easy answers here. But sometimes you got to make a choice, and you might get it wrong. But you got to consider those trade-offs.
\n\nWILL: Yeah, I feel like this is our least conclusive one to date. Honestly, you know what I mean, like, so, remember, kids, any choice you make is probably wrong and sucks, no matter what [laughter].
\n\nKYLE: If it doesn't suck now, it will later?
\n\nWILL: Happy Friday!
\n\n[laughter]
\n\nMIKE: It's a bitter lesson, but an important one [laughs].
\n\nWILL: Thanks, comrades. All right, well, I'll go get started on the weekend drinking [laughter].
\n\nMIKE: Until next time.
","summary":"","date_published":"2024-11-13T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/9c1f3567-b9cb-43ff-9626-5215b097e65f.mp3","mime_type":"audio/mpeg","size_in_bytes":27421094,"duration_in_seconds":2768}]},{"id":"417a1030-565b-4d25-b25e-5b4e2c9eae40","title":"Episode 58: Feature Verification","url":"https://acima-development.fireside.fm/58","content_text":"In this episode of the Acima Development Podcast, Mike humorously shares his experiences with his three-year-old son’s unconventional love for books, recounting how his son physically devours them, forcing Mike to create an elaborate security system to protect the family’s book collection. This story transitions into a discussion about problem-solving and determination, linking it to testing and validation in software development. The team laughs about how motivated problem-solving, much like a child's persistence, can reveal gaps in security or design, paralleling the way developers must rigorously test software to uncover flaws.\n\nThe podcast delves into the importance of validating features beyond just passing unit tests, emphasizing that even bug-free code may fail if it doesn’t meet the right requirements. The conversation touches on the limitations of unit tests, pointing out that they are only as effective as the person who writes them and that they cannot catch misunderstandings in requirements. The hosts also discuss tools like Qualit.AI, which use AI to generate tests, but caution that even with advanced tools, ensuring correct specifications and validation is crucial to avoid costly errors in software.\n\nThe conversation expands into a broader discussion of testing methodologies, including dynamic application security testing (DAST), the value of cross-checking systems, and the challenges of relying solely on automated tools. The hosts highlight how important it is to approach validation from multiple angles, much like using \"belt and suspenders\" for security, to ensure robust software that can withstand different types of user interactions and vulnerabilities. The episode concludes by reaffirming the importance of rigorous validation processes, whether through unit tests, security scans, or AI-driven solutions, to catch errors and ensure the overall quality of the code.\n\nTranscript:\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I have here with me Eddy, Justin, Dave, and Kyle. \n\nI have a three-year-old, and he loves books, just absolutely loves books. He devours them. I can't tell you how many books he's been through. The problem is, I mean that literally [laughs]. He has eaten more books than I can count. He just loves the cardboard, chews it right up, removes the binding, tears into pieces. It is a real challenge [laughs]. [inaudible 00:41] the opportunity to read, but, you know, he definitely gets his fill of books, just not in the way that we intended [laughs]. It's the point where we have to take some security measures. \n\nIn my living room, I have some stairs. At the top of the stairs, there's a bathroom, but next to the bathroom, there is not a full room; it's just a loft. It's an area that's enclosed on three sides by the boundaries of the house and then a wall with the bathroom, but it's not enclosed along the railing. So, you can look out over the railing. And it's open. It's not a full room. And there's no door. You just turn left and walk into the space, and that's where we have our books. And, you know, we have a lot of books. We like books [laughs]. We're book lovers. We have lots of children's books, lots of shelves of books. And he'd go in there and just have a meal. So [laughter], that's a problem. \n\nSo, we started coming up with tactics to dissuade him from doing so. You know, we can always go in there, and grab a book, sit with him one on one. But we're trying to encourage him to appreciate books in a different way. We tried to child-gate. That didn't last long. He learned how to climb over it within weeks. So, we got rid of that. I put up a sheet of plywood and thought, well, this will dissuade him. That did dissuade him for a short amount of time. He figured out how to move that out of the way. I literally put an anvil in front of the sheet of plywood. And you know that if you're very determined, even if you're three years old, you can slide an anvil across the carpet, and he got in. \n\nAnd, eventually, the solution I had to do was to mount. I cut the plywood down a little lower. It's over a meter [laughter]. It's about...it's a little under five feet high probably, and, you know, I think, like a meter and a half. And I've got it mounted on hinges, hinges for a gate, so gate hinges. So, it means they can rock both ways. So, you can turn it, you know, 180 degrees. And I've got that mounted into the stud in that part of the railing. It's an enclosed railing, So, I've got it mounted into the stud, so it’s solid. And I’ve put a gate latch on the other side that it mounts into. \n\nAt first, we got this, and it worked. But pretty soon, he figured out how to undo the latch. So, we had to get a wire that had a screw class that held it together. He got through that, too. So, we have a padlock with a combination on it [laughter]. I hope that you get some sense of how impressive my son is [laughs]. \n\nDAVE: This is motivated problem-solving, absolutely. \n\nMIKE: Absolutely. Extremely motivated problem-solving. \n\nEDDY: Having a three-year-old being able to slide an anvil across the carpet is pretty impressive, just saying. \n\nMIKE: The truth is, he did that about a year ago. So [laughs], you know, he, yeah, he is strong and dedicated. I'm not going to go into all of the stories [laughs]. The other day, he saw a package on the front doorstep. So, he opened the window, pushed out the screen, jumped out the window, ran over, got the package, and came inside because he couldn't reach the latch on the door. \n\nEDDY: He'd make a really good QA member. \n\nMIKE: He would. And he'd make a great, well, he'd make a fantastic QA team member, which is the perfect segue into our topic today [laughs]. \n\nWe're going to talk about validation of our features. And there are lots of things that people talk about to make, you know, your code good. And, you know, we talk a lot about unit tests. We focus a lot on unit tests. We've had multiple podcasts talking about RSpec [laughs] and best practices in that particular library for testing, which is great. I love unit tests. They give me a ton of confidence. \n\nI've also had experiences in the past where I have written some code, written the unit tests, gone through testing, everything worked perfectly, got it deployed, and then realized that it didn't meet the requirements [laughs]. Regardless of how well it was written, it missed the point, right? It missed the mark. And that is completely outside of what RSpec can save you from. Unless you have...you just can't. Like, if your requirements are wrong, if you misunderstand the requirements, then your specifications are not going to catch you.\n\nEDDY: Well, RSpec is only as good, or a unit test is only as good as the author, right? It can only be as good as the person who writes it. \n\nDAVE: The problem behind the problem is you built the wrong thing. There's no amount of tooling that can save you from successfully building the wrong thing. \n\nJUSTIN: Well, I went to a presentation by a company called Qualit.AI. They have AI tests or their tests are generated by an AI. And it's actually pretty interesting. You can feed it the specs that are written by the product owner rather than engineer. And, theoretically, it will solve some of that problem. \n\nMIKE: But, again, if the specifications are written wrong, we have trouble, and there's a gap there. Now, you can only take that so far. You know, at some point, people have got to get it right. There's this really important component of creating the validation instructions to make sure that we get out the feature that we really want early on. And you can have bug-free code, technically bug-free, because it does exactly what you told it to do that is not the feature you wanted. \n\nFurther, unit tests live as a unit, right? They test a unit of code in isolation. By design, it makes them fast. It means you can run your test suite and validate your code quickly. They do not run an integrated test to make sure all the components run well together. And that's another prong of a testing strategy. There are also things like security tests, you know, penetration tests or probing for libraries with security holes. I mean, there are a whole range, a whole range of ways that things can go wrong. \n\nAnd the way that you validate your code is the way that my son does. He works on it until he gets to that book. And unless it's essentially impossible for him to get in, he's going to be eating that book. And sometimes, we don't have quite that attitude. Sometimes we think, well, you know, I think it passes the unit test. It must be good. You know, I've written good code here. And once we start to get a little lax there, we get ourselves in a lot of trouble. \n\nJUSTIN: This kind of goes into what type of testing you want to do. And the reason I bring this up is I'm in charge of the DAST testing at our company, and we use a tool called Rapid7. And one of the things that it does is it does, basically, you know, it scans the application, and it just shoots everything under the sun at the application, and it's not looking for functionality. It's not looking for usability. What it's looking for is vulnerability. And so, it's like, a specific type of thing that you're looking for, I mean, that kind of drives your testing, you know, what type of testing you're doing. And the test suite that Rapid7 uses takes basically two days to run. So, we always run it Friday at like, you know, 4:00 p.m.\n\nBut it's just kind of nuts because it throws everything under the sun at every single form parameter API that it can detect. And, you know, it gives you results, and you've got to parse through them and everything and, you know, kind of see if they were useful or not. But I think it goes back to, you know, you've got to test with intent and, you know, what you're looking for as a result of it depends on what type of test you're running. \n\nDAVE: You said DAS testing, that's dynamic application something, something testing? \n\nJUSTIN: Yeah, security testing?\n\nDAVE: Security testing, okay. \n\nJUSTIN: Yeah. So, it basically scans your application. It pulls all the endpoints, all the submits, all the things like that, all the gits. And then it just puts trash into every single parameter that I can figure out, and then it just looks at the results. And it's not like it's...like I said, it's not looking for UI results. It's not looking for usability. It's just looking at vulnerability results, which it has a limited, I mean, semi-limited set of expectations that reveals a vulnerability. It is something that can be automated, but it's like something that is, you know, thousands or tens of thousands of results that fit within, you know, that could reveal a vulnerability. \n\nMIKE: And that kind of captures an aspect of testing that we don't always think about. Sometimes we think that our attackers are really savvy, like, nation states [chuckles] that are going to come and break into your system. You know, honestly, I've read, you know, if a nation-state wants to scan your system, they probably will. And they have reason to keep it private, so [laughs] they may get in there and just lay low. What really is the kind of attack, you know, is not a sophisticated mastermind. It's like a horde of zombies. \n\n[laughter]\n\nJUSTIN: Are you calling our users zombies? [laughter]\n\nMIKE: I am not disparaging our users because it's not just our delivery users, you know, there's scripts out there. There are bots. But, you know, it's a way of thinking about the users, right? There are a lot of things that they do by accident. You give enough time; somebody's going to click that button [chuckles], whatever that button is. \n\nI had an experience somewhat recently where there was a button that had worked. Nobody had used it in a while. Somebody clicked the button, and the data set had gotten large, and so it put a lot more load on the system than it had historically. They probably didn't even mean to click the button [laughter]. But, you know, and they're curious. What happens if I click this one [laughs]? And, you know, you will have intelligent users who will come up with clever workarounds, absolutely. But you also have the accidents, the bumps, the shambling horde bouncing around on their keyboard [chuckles] through your application, knocking stuff down. And you have enough of that; if something can be broken, it will.\n\nAnd we get in a lot of trouble because we build this feature, and we think I’ve built this perfect feature, and this is exactly how it will be used. And the interface is perfect, and people are going to come and use it. And the first person comes, and they use it entirely differently and the thing blows up because you misunderstand the way that people use things. All of us like to explore the boundaries. We want to get and eat that book. \n\nDAVE: Delicious, delicious literature, yeah.\n\nJUSTIN: You know, when you went with that metaphor, I thought you were going to go developers wanting to get their code to production, and they'll figure out all the different paths that they can do [laughs] to get it without having to pass through the gates that you set up, including QA [laughs] and, like, automated scans and things like that. \n\nMIKE: Give a junior developer a path to deployment, and they will use it [chuckles] or a senior -- \n\nDAVE: Developers interpret IT as damage and route around it, like, 100%.\n\nJUSTIN: [laughs]\n\nDAVE: And it's not because IT is bad. It's because developers are...we optimize horrifically. There's a related thing. Richard Feynman was on the Manhattan Project, worked on the atom bomb in the 1940s. And he went out to Los Alamos, top-secret middle of White Sands, New Mexico. And, like, there was a scramble project. Like, we got to go invent the atom bomb. So, they had built this little shanty town. It was all super top secret. You couldn't go in and out. They had to put a fence around it.\n\nAnd they were building this camp while the scientists were trying to work in it, which meant they had a great big construction crew, and the construction crew wasn't allowed to be in front of the camp where the gate was. So, they put a great, big chain fence around it, and then they cut a hole in the back of the fence so the construction workers could get in and out. \n\nAnd Dr. Feynman's like, what? Guards, gates, guns, top secret, and there's this hundred-foot section of fence that's just missing on the base. And everyone he asked was like, “No, leave it alone, leave it alone, leave it alone. Don't ask questions.” And so, he's like, “Okay, here's the thing, if I walk in the front gate, you have to sign in.” And, like they take an inquiry of what you have with you on your way in and out. “If I sign in and then go out that hole in the gate and then sign in again, they will immediately arrest me for stealing stuff, for, like, exporting things off of the base. So, I did it the other way around.” \n\nHe walked in the base through the hole in the fence and then signed out, and then walked in through the base. And every time he's signing out, they're patting him down. He's got nothing. He says, “The fourth time through, they arrested me [chuckles], which is what they should have done.” And the next day, that hole in the fence was fixed. And it took him validating the security flaw before he could get anybody to take the security flaw seriously. And I want to say the construction camp also was allowed to move forward because they realized, oh yeah, we're strangling you guys. I don't think Dr. Feynman was popular with the construction crew after that. \n\n[laughter]\n\nSo, a real quick anecdote. This happened to me in 2010, which is a long time ago, but also way too recently for this noise to be happening. I had a developer, senior developer look me dead in the eye and say, “Every line of code has a chance of introducing a bug.” So, if you write as many lines of test as you have lines of code, you are doubling your chances of defects.\n\nAnd he was dead serious that you should not write test code because it doubles the chance of writing a defect. And like, yeah, there are facepalms going on in the cameras right now, yeah, 100%. And I was so stunned. I was so flabbergasted by this that I had no response, and he declared victory and moved the conversation on. I'm like, no, no, no, no, no, no, this is not the victory face that I'm making. \n\nI finally was able to come back and say, “Okay, here's where you went wrong. You are saying that every time you work a math problem, you might introduce an arithmetical error. You might forget to copy a zero or copy a five as, you know, as a seven, or something like this. What you are telling me is that if you take the test and then you check your work, you are twice as likely to write an arithmetical error, and that is true.\n\nYou had 40 problems. You're now working 80 problems because you're working every problem twice. But the error in one is unlikely to be reproduced in the other, and the chance of you getting a higher grade on your test is significantly higher because attentional errors don't happen on cue. Attentional errors happen randomly, and that's what checking your work will catch. And I keep that in my back pocket when I start thinking about good tests versus bad tests. \n\nGoodhart's Law says that as soon as a measure becomes the goal, it ceases to be a good measure, and code coverage is the same way. Like, when you turn in a PR, you must write a test. And there are times when the developer they wrote the code they just want. They want just enough tests to get their PR approved so they can get out the door. And you can tell, right? The RSpec context barely read like English. They don't string together coherently. They took the matrix of all things and just blotted it out into a big, old file. And, more importantly, if you change the source code, the test doesn't break. And if you change the test code, the source code may or may not relate to it, right?\n\nAnd the other side of this is that if you want to actually upgrade the code and change the architecture of it, the test breaks, like, tests outside of that code start to break because they've got their fingers reached in. This is that, this is the you took 40 problems, turned them into 80. And if any of those 80 has a problem, you get an F on the test. That's what that kind of testing is like. \n\nWhat makes a good test is when that test works as a cross-check. And, for me, and this speaks to validation, and I promise I won't spend much time on my soapbox, but I'm going to get on it. Write your tests first. You will write better code. You legitimately will write different code if you write your test first because the test will force you to write code that’s testable.\n\nNext time you're trying to test some code, you go, man, this is really hard to test; just look yourself in the mirror and say, “I did this to me,” because you didn't write your test first, right? One drives the other. The test must conform to the code versus the other way around. And if your tests declared their intent, it's very hard to copy the architecture and details of the how you did it if all the test says is what has to be done. But if you write the code first, oftentimes, you just want to get your code coverage up.\n\nSo, you write a test that just duplicates the how, and now you've got twice as many lines of how, and a bug in either one is going to slow you down. The maintainer can't maintain the code because the tests are going to fight because, yeah, it's terrible. \n\nAnd this gets me thinking about things where when any one of these things can fail. If the whole system goes down, you have a very delicate system. And if any one of these things can validate the system, you have a very strong validation system. Not to dive randomly down a weird crossed metaphor, but I'm going to say firearms because that's a topic that it's a little political but more importantly, it gets everyone going, “Wait, what?” And it gets everyone paying attention.\n\nThere's four rules to firearm safety. Always assume the gun is loaded. Never point your gun at something you don't intend to destroy. Keep your finger out of the trigger guard until you're ready to shoot. And always be sure of your target and what is beyond. Those four rules. Here's the thing: if you break any one of those rules, the other three will save you. If you break any three of those rules, the other one will save you. In order to injure someone with an accidental discharge or a negligent discharge, you have to break all four rules! Versus –\n\nEDDY: Did you mention the safety? Sorry, I was listening [inaudible 19:48]\n\nDAVE: Oh yeah, yeah. Sorry, I did not, and that's because I stated keep your finger off the trigger. Keep the gun on safe and your finger off the trigger until you're ready to shoot. Yep. You're right. Thank you.\n\nEDDY: That's kind of a huge gap. \n\nDAVE: Thank you. You phrased that...Yes. Yep. Yep. \n\nEDDY: [laughs]\n\nDAVE: Yeah, no, it's a good one and absolutely valid. And the thing is, you have to break all four of those rules before you can run into this problem. On the other hand, you'll see tests where if you don't do this thing, the whole system blows up. If you don't do this thing, the whole system blows up. If you don't write...all four of those things have to be true in order to keep people safe. That’s a very risky operation. \n\nAnd if you write your test after the code and they duplicate the how, it becomes every single line of test code must duplicate the implementation of the code, or the tests won't work. And if you want to modify the code, your test will fight you. But if they cross-check each other, then you can change the implementation and the tests are still happy because it still works, right? \n\nAnd you can update your tests without having to rewrite the code. Yeah, it's nice. It's not easy. I will freely grant people that are annoyed and frustrated by this the reason we don't do it is because you don't get taught how to do it, and learning how to do it after the fact is very hard to do. And it is so worth it. All right, I’m off my soap box. Thank you.\n\nMIKE: You got me thinking about some mathematical evidence of this. Has anybody here ever used a Kalman filter? \n\nDAVE: Sounds familiar. \n\nMIKE: Okay, so let me give some explanation. The math can get hairy, but the intuition is actually really simple. They use this in self-driving cars and vehicles of all kinds. Let's say you want to figure out where you're at, and you've got a few different sensors, and each of them is kind of iffy, right? It kind of can tell where you are. None of them are all that great. And if you think about how probability distributions work, they're often modeled with the bell curve, right? Gaussian curve. And if you have a really bad measurement, then that curve is going to be really flat and long, right? Because it can be kind of over a wide range. \n\nHere's the magic. If you have two of those two really wide, flat, Gaussian curves, and you think, what happens if you combine them? What happens if you multiply them together to get the combined distribution? It is a narrower distribution and with a higher spike every single time. And if you have four different sensors, they're giving you four different distributions. You're tightening that up until you have a really good idea of where you're at. Mathematically, if you combine those probability distributions, you end up with a much better awareness, you know, from most sensors as to what they're trying to sense. Here, we're talking about tests. \n\nDAVE: It’s genius.\n\nMIKE: You’ve said that you want to validate that you haven't broken something. And all of your validations have their own flaws. But if you combine them together, you have much greater assurance than if you use them independently. \n\nJUSTIN: So, how would you combine them together?\n\nDAVE: There's a thing that I heard about from the ‘80s. And the way you combine them, right? You don't want to have one dependent on the previous; depend on the previous because that extrapolates. Your error makes it worse. I want to say it's called Bayes’ Law? Don't quote me on that, but the story behind it is if you Google how many piano tuners are there in Chicago, that's the story that everyone tells with this. When you try to guess, I have no idea what it is, the more variables you can guess at, the more accurate...and you're completely guessing, right? \n\nWhat is the population of Chicago? I don't know, but let's guess. Let's say it's 10 million. Maybe it's 1 million. I could be completely wrong. It's probably not 450 million. That's more than there are people in the country. But some people are going to guess that. Most people are bad at estimation. If I had to guess, like, 8 or 9 billion of people are bad at it [laughter]. So, anyway. But if you guess too high on the population, your next guess is what percentage of those people have pianos, 10%? 1%? 50%? I don't know. I might be right. I might be wrong. But there's a 50% chance that my wrong is going to be in the other direction and that's column filtering.\n\nThe more things you can add, how many of those people, how long does it take to tune a piano, versus how much does it cost to tune a piano, versus how much money does a piano tuner need to make, you start throwing enough variables out at this, you start coming down with, well, you need to make this much money, which you’re going to have this much work, which you’re going to have this much lead time. That means the pool must be this big, which means there must be this many piano tuners in Chicago. \n\nAnd if you worked out with enough variables, you start getting spookily accurate, assuming that all your efforts are our best guesses and that you never make the mistake of saying, “Well, if there's a hundred piano tuners, they will have a thousand tools.” That's chaining. That's going to multiply your error. It's when your errors cross-check each other that it gets spooky and amazing. \n\nMIKE: Just so you know, it's kind of hard to find a piano tuner in Chicago [laughter] from personal experience.\n\nDAVE: Okay, that's another point of data, and we'll just put that in the [laughter] -- Is it easy, or is it hard? \n\nEDDY: So, are you telling me, Dave, that I should or should not buy a piano?\n\nDAVE: Yes, absolutely. Actually, no, the correct answer is no. \n\nJUSTIN: I know how to play the piano. I know how to, and I have the piano tools, but I've never been paid for it, unless I would pay myself. \n\nDAVE: There you go. Oh, that's a good point, yeah. That becomes another set of things. Is there a shade tree market for this, right? If piano tuners are really rare and really expensive, there's going to be a shade tree market for people doing it for free. You can go down that complete crazy raffle. It's fun. \n\nThere's a Numberphiles. Anybody here look at Numberphfile on YouTube, number P-H-I-L-E? It's a British channel. They get into math and science and stuff like this. There's one on estimating the number of tanks in Germany in World War II. There was one part of the transmission that had a serial number, and they knew the serial number started at one and that they incremented linearly, and they said, every time you blow up a tank, get us that number.\n\nAnd it turns out that if you have serial numbers selected at random, you can estimate how many total there are. With five or six guesses, you're within 1% of the actual total number. It is spooky. They had, like, 15 number samples, and they came back, and they said, “Germany's making 251 tanks per month,” and the actual number was, like, 249. They nailed it off of what looks like random numbers. And it's because of the column filtering. Every random number starts to exclude the extreme. \n\nMIKE: So, how do we use this to our benefit? \n\nDAVE: For me, it comes down to cross-checks versus that...depending extrapolation. What is a question that I can ask that will exclude the greatest number of things, and will that thing exclude valid data, right? I need to go look up a thing. Eddy and I had a conversation in private the other day that talked about...oh, it was about a comment. Okay, I realize this may not sound like validation, but Eddy had a comment about a comment that I wrote in the code because RuboCop demands that we comment our classes, right?\n\nSo, we get class transfer group, and RuboCop will say, “You must comment this class.” And the poor maintainer who's never seen this and they're just trying to document the code and satisfy RuboCop they'll write, “This is the transfer group class,” which is a completely useless comment, complete waste of time. \n\nWhat is the thing that you can say about this class that will communicate the most information that will be valid? I have to start saying things about, well, what is a transfer group? What does it represent? Well, it's this thing. I start talking about this business need. Well, that makes me nervous because if the business need changes, that transfer group it's now mislabeled. \n\nBut you can kind of look at what you wrote and start to see if that definition changes, like, somebody comes along later and says, “We're going to use transfer group to identify merchants that are related on this other access.” Well, that's not a transfer group anymore. That's a related merchant thing. And that comment, while now inaccurate, is going to immediately tell a maintainer, “I am now mislabeled.” And that's because this class is now incorrectly named because some future maintainer changed the meaning of what this class was. And that's a great time to re-document the class, or rename the class or both. \n\nEDDY: That’s assuming that the person --\n\nDAVE: And that's a long way of saying --\n\nEDDY: I was going to say that's just assuming that the person who happens to touch that class and alters it also reads the comment and remembers to do it.\n\nDAVE: That's true. Okay so --\n\nEDDY: So, documentation is only good if you still keep it up to date; that's all I'm saying. \n\nDAVE: So, I have two unfortunate facts for you. The first one is documentation is the first thing to go out of date every single time because you'll get a maintainer who's in a hurry, and they want to make it work. They'll come in, and they'll fix the bug. They won’t even read the comments. The other unfortunate fact is that when you are not familiar with the code, and you're reading through it, you will believe a comment over the code. I have literally; I kid you not; this was in Assembly language, so it was slightly encoded. But if the line of code was mov eax1, which means move a one into the AX register, the A register on the CPU, the comment was put zero in AX, which is the exact opposite of what that statement did. \n\nLanguage primary used to be 40 years ago; if you wanted to put a zero in a register, you don't move a zero. That takes two clock instructions. You can XOR a register against itself, and any number XOR itself is zero. So, you write XOR EAX comma EAX, one clock cycle you've got a zero in AX. Great. You're done. Somebody came along later and said...so, somebody had written, mov eax, zero, put a zero in it. They came along later and said XOR EAX with itself, and they commented it to say, “Put a zero in EAX, so that you'll know...” why are you XORing...oh, we're putting a zero in it. Great.\n\nA maintainer came along later. That needs to be a one, not a zero. They changed it back to mov, and they left the put a one or put a zero in AX. And that comment stood for 15 years because nobody dared remove the comment. People believe your comments. They are important. Please write good comments. And don't document what the code is doing. Document why the code does what it does; that way, that comment will last.\n\nJUSTIN: No, I ran into that exact situation earlier this week. There was a comment in the content of the security policy file. And I was like, is that still valid? And it took me, like, three or four hours to track down. And the comment was not valid anymore. It was giving people bad information. I was like, okay, now I got to go in and change this, remove this comment. \n\nDAVE: And when you have a comment in there that says, “Vendor X refuses to whitelist our server,” and then you've got this egregious violation of, like, hard-coded IP address or something like that, that's actually a good comment because it doesn't say “Hard code the IP.” If I write hard code the IP, I can see that. That's in the line of code where [inaudible 30:51] follows it. \n\nBut seven years from now, when vendor X doesn't even work with us anymore, and we don't need this whitelisted anymore, that comment of Vendor X doesn't whitelist us, you can then go, oh, we documented the intent. We documented the discussion. I can now validate without any extra help that this is garbage. This code is now suspect. But ten years from now, we have all kinds of code in our app, and it's not just us. Every place I've ever worked, you'll see code that's five years old that says, “Put a one in EAX, and the line of code below it puts a one in EAX,” and you don't need that one in EAX anymore. You haven't needed it in three years because you don't work with that vendor anymore. But the comment just documents what the code does, and that remains true, and it's useless. \n\nSo, the cross-check is, why do we want this? Some of you guys have heard me say, when you write up a Jira ticket, don't document the decision; document the discussion because, a year from now, that decision is going to be wrong. And you've thrown away the discussion that would help a future person say, “Oh, that discussion is still valid, and the decision is now different because of a dependent fact.”\n\nEDDY: Which is why I always push for, like, a more public open discussion.\n\nDAVE: Absolutely.\n\nEDDY: Any time any [inaudible 32:07] decision is being made, whether that's in a pull request, whether that's in a Jira ticket. It does not matter, right? Have it in a more open forum so that other people who stumble upon that same thing can be like, ah, that's why we decided to do it this way, instead of [inaudible 32:23]\n\nDAVE: 100%. 100%\n\nMIKE: I'd like to latch on to that a little bit. You just said the discussion in a public forum is an important tool for generating quality code and avoiding defects. There's no clear, like, linear relationship between those two that leads to this. But I think you're absolutely right. In fact, I think that may be the most important thing we can do to lead to quality code. Because something that's...what do you say? Sunshine is the best disinfectant? \n\nDAVE: Mm-hmm. Mm-hmm. So, I think it was Will was on with us. Will joined the call; by the way, partway through, people listening at home. It was Will that said he hates when people DM him a question that should be in the knowledge base. I don't want to put words in your mouth, Will. I think what you said was you want people to ask you in public so that the conversation is documented in the channel. \n\nWILL: Always. Always, always, always, always, always, always. DM me for personal stuff, for sensitive stuff, or whatever, but I don't like any technical discussion in DMs ever, ever. I can't think of an exception. \n\nEDDY: Can you dissect that a little bit? I think that's really important. Because I feel like, in practice, that's not really the case, and I'm wondering if that's something that can be implemented across the board.\n\nWILL: There's a couple of things going on. So, one thing is I work in a distributed team, right? I don't like the word remote; it's distributed, right? And so, some of that is particular to that sort of, like, that sort of workflow, in that, like, I've never been in a room with any of these people, and I probably never will be. So, a lot of implicit communication and scuttlebutt and, like, what's everybody, like, doing over here, you know what I mean? Like, if you just see a cluster of people freaking out on something, right, then you'll naturally gravitate to it, and there's an implicit communication there. So, like, you want to do that. And it's just visibility. You’re like, what's going on, and why, right? And I think that's really valuable. \n\nAnd the other one is like, as we said, sort of, like, documentation, it is, to a degree, self-documenting code. One habit that I've gotten into working in a big organization, you know, with a lot of different functional groups and a lot of different workflows, and everything's changing all the time, right? The documentation isn't the documentation. We have, like, a big Confluence Wiki, and that's fraudulent. It's hilariously bad. \n\nMIKE: [laughs]\n\nWILL: Like comically, a comic misrepresentation of someone's hopes, dreams, broken promises, et cetera. It's all garbage. With Slack, if you're a good Slack --\n\nDAVE: Confluence is where organizational knowledge goes to die.\n\nWILL: And/or Jira archaeologist, you could find the tea, you know what I mean? GitHub, Slack, and Jira. Because those things are all, you know what I mean, like, Jira's maybe the least accurate. But, like, everything that gets through had a ticket, right? So, somebody touched it. And then, Github is the word of God, right? Like, that's it. \n\nAnd then, Slack is just sort of useful for the things that didn't make it into a PR, where it's just like, oh yeah, the app broke because this symlink was wrong to this version of Python. Then you had to go in and hand-edit this thing. Well, yeah, I see you laughing, Justin. But you know just as well as I do that that problem right there, you've seen it, or variants of it, and that's going to stop your whole development team cold. You're dead in the water. Stone cold stopped. \n\nJUSTIN: Those data science team.\n\n[laughter]\n\nDAVE: Jerks. \n\nWILL: Yeah. And there's other stuff where it's just like, something will screw up. There'll be some stupid workflow that I need to know once a year. And, like, once a year, I'm frickin **** if I can't...oh, what was that? And it's not worth documenting. I mean, it is, but I can't justify it to myself. Anyway, so, I mean, that's my general philosophy on that. And I would say, like, you know, both, like, I encourage everyone, across the board, think really hard about doing this, and it will bear fruit over time. Even if it's stupid, man, because if you keep –- \n\nEDDY: I've had someone tell me that the code is the documentation. \n\nWILL: I mean, it is. \n\nEDDY: I mean, yes and no. Yes and no. \n\nDAVE: I'm just going to say no, not even yes and no, just no. \n\nEDDY: Yes and no.\n\nDAVE: That's like saying the product documents the workmanship. No. No, it doesn't. \n\nEDDY: [laughs]\n\nWILL: I broadly agree with the code as a documentation. Like, just get good, guys. Get good. Just read the freaking code. Just read the code. \n\nDAVE: Better is better, yeah. Better is better. That's tautological. Yeah. \n\nEDDY: The thing is, it would take me longer to look at a code to see what it does than if you just had something to tell me what it does.\n\nJUSTIN: You need a ChatGPT or something [laughs] to tell you what it does [laughter]. \n\nEDDY: Copy this whole class and ask it, “What does this class do?” \n\nJUSTIN: It's freaky. It works a lot of the time. But, anyway, that's kind of here nor there. \n\nDAVE: We're doing a Copilot demo. In the lesson, the presenter was saying, “If you ask Copilot, ‘What's your favorite flavor of ice cream?’ It will say, ‘I only want to talk about code.’” So, I immediately started trying to get Copilot to talk about ice cream with me. Like, well, okay, but if you did what would...and about the third time through, Copilot said. “You have SQL embedded in your Ruby code.” I'm like, okay, to be fair, that's more important than what I’m [inaudible 38:15] [laughter]. I thought that was hilarious. Like, okay, yeah, yeah, you're right. You're right. \n\nKYLE: I have found that it will work if you tell it what you're talking about is code; it'll talk with you. \n\nEDDY: Oh, I've never had to try to have a human conversation with AI. It's still too weird to me. I refuse to accept it. \n\nDAVE: I've been playing a lot of [crosstalk 38:38] lately, and it goes weird. It goes weird in some really interesting ways. Yeah. \n\nMIKE: [inaudible 38:44] that will tell me what your favorite kind of ice cream is. \n\nJUSTIN: So, my AI anecdote of the week was I was at a choir this week, and I wanted to know if I was singing off-key because we're in a choir, and sometimes it's hard to tell. And I asked Claude.ai, which is my favorite AI tool, “Write me a Flutter app that would use my phone's microphone and tell me if I was off-key or what note I was on.” \n\nAnd within a five-minute conversation, it gave me working code, and, you know, I could have run that at my house and had it running on my phone. And so, it's just like, that was my, you know, oh my goodness, holy smokes AI of the week, you know, using libraries I wasn't familiar with using, you know, other things, but they were the right...I mean, it was working. I don't know if it was like, I mean, it was okay from an architecture point of view, and it was, like, an easy solution for the tool that I was asking for. \n\nEDDY: Here's my problem with AI. It's like you have to speak to it like it's a toddler. Let me elaborate.\n\n[laughter]\n\nDAVE: They're getting better currently. I know what you mean. I know what you mean, yeah. \n\nEDDY: You can't just say, “Hey, go up the stairs.” You have to be like, “Hey, get up. Use your limbs. Use one after the other. Grab the railing on the side. Start with your right foot, then your left, then your right, then your left. Make sure you don't fall. Keep your balance. And then, when you make it on top, stop [chuckles],” You know what I mean? Like, you've got to be very, very specific for it to be good, right? Like, if you ask it very vague questions...it's getting a little better, but it still hallucinates. \n\nMIKE: Just like a toddler, also they ingest lots of books. \n\n[laughter] \n\nDAVE: Exactly. So, if you want to spook yourself, ask the hard question, but then start a conversation with the AI about the hard question. For example, I just asked ChatGPT because it's saving out old chats now, and I asked it just now while we were chatting, based on my conversational history, what do you think my favorite flavor of ice cream is? It got the right answer.\n\nEDDY: Vanilla.\n\nDAVE: Salted caramel.\n\nEDDY: Oh.\n\nDAVE: Like, legit.\n\nJUSTIN: Whoa, oddly specific.\n\nDAVE: Yeah, oddly specific. And it explained like, the AI it said, \"Based on our chat and your quirky sense of humor, it's going to be something oddly specific and nontraditional.\" So, it was like, espresso, salted caramel, and one other, like, bubble gum or something like that. And I'm like, second one, salted caramel. So, there's stuff in there. Have ChatGPT guess your age based on your chat style, on your writing style. It will decline at first because it doesn't want to, like, trigger you, or, you know, like [laughter], like, it's programmed [crosstalk 41:34]. Well, it's programmed to not say things that would get it canceled, right?\n\nEDDY: It's like, Dave, based on our history, I think that you're ten years old [laughs]. \n\nDAVE: Yeah, emotionally, you are 12.\n\nWILL: [inaudible 41:48]\n\nDAVE: But your writing style suggests you're 12 from the 1970s. And I'm like, yep, got me. Yep. \n\nEDDY: All I'm going to say is that have we all just tried eating books? Because he could be onto something, and books could just be really good. Just eating. \n\nMIKE: A wad of old, soggy cardboard in your mouth?\n\nEDDY: There could be something there. Have we all tried --\n\nJUSTIN: I've been to restaurants that, you know, have been worse than that.\n\n[laughter] \n\nDAVE: I almost said the name of a restaurant because there's a place here in American Fork in Utah. They cater to the blue hair brigade, to people over the age of 60 and 70. So, the food has no flavor whatsoever. And yeah, it's a joke in our family. So, you all know a place like that, right? \n\nKYLE: My immediate thought was to call [inaudible 42:37] pizzas, frozen pizzas \n\nEDDY: They're actually pretty good. They're pretty good. Don't [inaudible 42:44] on them. \n\nKYLE: Back in the day, they were.\n\n[laughter]\n\nEDDY: Back before I was married, they made good food. So, I have a question --\n\nDAVE: And then, there's other places that it's ketchup on a saltine. \n\nEDDY: We did touch a little bit in the AI. I'm wondering if anyone has had any experience to use AI as far as running validations. \n\nJUSTIN: Oh, I'm glad you brought that up. There is that company that I'd mentioned before at the beginning of this conversation, the Qualit.AI. And they have a lot of good clients. I mean, they're a fully functioning tech company that is taking in money and providing value by using AI to create tests for clients. And it's kind of freaky in some ways because it's like I've written tons of tests, unit tests. I've written tons of integration tests. I've written, you know, end-to-end tests. We've all done the, you know, hey, let's use Selenium to write all our web tests or whatever. \n\nAnd all of our tests are always brittle and, you know, and they're outdated in the next release. But it's like, you go in there with good intentions, and it turns out to require a lot of work to maintain that test suite. But, all of a sudden, you can take your application and your specs and throw it at this AI, and you may not have it perfect, but it gives enough value that people are willing to pay a lot of money for it. And it's interesting and it'll be even more interesting in a couple of years where the AI becomes even better at maintaining those. And you just, like, throw your documentation at it, and then your application endpoint, and, you know, you say, \"Hey, tell me if anything's wrong with this.\" and it comes back five minutes later.\n\nMIKE: I think there's something really pertinent here. We've talked about how AI makes mistakes. And so, now we're back in the exact same boat that we are in for ourselves in that I'm writing some code, and it might have some problems. So, what are all of the things I can do to validate this code to make sure that it works? And as we automate some of our code writing responsibilities, the job doesn't change [laughter]. Because our attitude is still, you know, our approach is how do I validate this code? \n\nDAVE: I just hit on a crazy synthesis of everything we've talked about up till now with this AI thing. One of the things about AI is that the neural networks are formed differently to the way humans build them, like, organically over time, which is why when you get an AI and teach it chess, it will do moves that no human has ever played, and then still win the game. Chess players have trained against existing patterns, and it's doing random things, right? \n\nSomething that I have noticed over the past month playing around with Copilot is that when the AI hallucinates, it's glaringly obvious to me. But when my co-worker hallucinates, I just accept it as a point of fact. And when you take those two networks and run them against each other, it's a cross-check instead of an extrapolated error. Oh, my head! Oh, I'm so glad I listened to the podcast today. Wow! \n\nEDDY: [laughs]\n\nDAVE: There's a blog post or two in that. Wow. Hey, you guys remember blogs? \n\nMIKE: [laughs]\n\nWILL: Yeah, sure. Copilot's great. [inaudible 46:07] the way down. \n\nEDDY: Copilot is particularly accurate, like, 95% of the time. It's really nice when it knows what you want, but when it doesn't, it's kind of annoying. \n\n[crosstalk 46:18]\n\nDAVE: But it's a useful annoying. That's what I'm saying. It's a useful annoying. \n\nEDDY: Yeah. It's like, good idea. I see what you did there, but no, that's not what I want. This is what I want. Be smarter next time. \n\nDAVE: That's my life goal. Honestly, like if I had a personal mission statement, it would be to be usefully annoying. \n\nEDDY: [laughs] \n\nWILL: You'll get there. \n\nDAVE: Just climbing up that useful tree [laughter]. Got the annoying nailed, so... \n\nMIKE: So, the recurring theme today, we make stuff that isn't perfect [laughs], and the way to find that is to take a multi-pronged, multi...\n\nJUSTIN: So, I'm glad you mentioned this. My co-worker, Dan, he says we take a belt and suspenders approach to security, and we do the same thing with testing. It's like, they do the same thing; they keep your pants up, but they support each other. They back each other up. A great example of this on the security side is, we have a number of gates in our automated CI, you know, which include a static code analysis, a dependency checker, a secrets analysis, among a couple of other things.\n\nAnd so, all those run, and then we also do, you know, we use Wiz to scan our containers, and then we use it to scan our deployed containers. And then, we also do...we pay an external company for a penetration test, and then we also do a DAS scan once a week or, you know. And so, all of those things are theoretically finding the same bugs. But the cost of having a security issue is so high that it's worth it to us to have all these tools checking the same code at multiple points of the SDLC that it's worth it to us to pay that, you know, to pay that thing. And it's kind of nuts, but that is the, you know, one of the costs of doing business in some cases, so...\n\nMIKE: Where you want to tighten that curve, right? \n\nJUSTIN: Yeah. But, like you said, David, it's like this and this, and then another dimension coming in on the intersection of all those things gives you a very high sense of confidence that the thing you are doing is correct. \n\nEDDY: It's so funny that you mentioned the suspenders also help [laughs] keep your pants up. I don't remember the last time I've seen anyone wear suspenders. So, is that really a reliable thing [laughs]? \n\nDAVE: Get off my lawn, you kids. I've seen them. \n\n[laughter]\n\nJUSTIN: I was going to see you pull out your suspenders, David. \n\nDAVE: What cracks me up is I've actually seen somebody hook their suspenders to their belt, and it's a perfect example of extrapolating your errors because if your belt fails, your suspenders are going to go with them. They're giving you nothing except for something to put on your shoulders, right? \n\nEDDY: [laughs]\n\nJUSTIN: And I'm glad you mentioned that, too, because if you are depending or you're testing the wrong thing, you create a false sense of security or a false assurance. So, writing tests for tests, you know, just to have a test there is not very useful, and that’s --\n\nDAVE: It's almost negative. \n\nJUSTIN: Yeah, it's almost negative because, all of a sudden, you have to support this extra code. And so that is a, I mean, that's a really important thing is to, like, test with deliberation, with intent. And be aware of everything that's in your pipeline and know why you're doing it. \n\nWILL: See, I came late, and I think I kind of almost want to offer, like, a little bit of a different perspective on the whole testing thing; I mean, in that, like, I don't really see testing as a tool for finding bugs. I've found very few bugs as a result of testing, writing tests, right? Because I write the tests around my understanding of how the thing is going to work. And if I thought of a bug that I would catch with a test, then I would like, well, you know what I mean? Just sort of like a developer verification or validation of, like what I've written, you know what I mean? Very few things, you know what I mean? Because I just push the button and make sure, you know, pops up with something right before I send it off to QA. And I'm just like, good luck suckers, you know, because it's just like, it's just a waste of everybody's time, and I hate redoing work.\n\nAnd so, where I get value out of testing and where I think an organization gets value out of testing is in a really formal specification of how this thing is supposed to work. And so, when assumptions around how this thing is supposed to work change, then you have your test suite, God willing, just raising their hand and saying, “Excuse me, what?” So, I was dealing with a team that manages pricing for products across this thing. So, like, pricing is kind of like the last line of defense, right? Like, we have old, old pages, decades old, you know, decades-old pages, right?\n\nBut they're still getting money. They're still getting traffic. People are still, like, going there and being like, oh, what about a TV? What was a cool TV to buy in 1995? Well, I don't know. I want to know. All right, fine, whatever. That will be a thousand dollars if I can even find one, whatever. And so, they have this ongoing layer upon layer upon layer upon layer like the rings of a tree. Every iteration of our sort of pricing platform that they need to support, right?\n\nAnd so, they have, like, easily a half a dozen different ways of slapping a price label on a product. And they all have to work because it's literally millions of dollars, right? Some of these long tail links they still convert, you know. And if we screw them up, we can hear about it. \n\nAnd so, the test suite for that team, and I think a lot of teams, it's just like, if I changed, if I have this new, great idea, that test suite is like a formal specification of, like, these are the wickets that you have to hit, you know, these are the hoops you have to jump through. It's got to work here and here and here and here and here, or else it's no good. And that's where your test suite is going to save you because nobody could think of all these oddball, you know what I mean, oddball corner cases and situations.\n\nYou build up the test suite to make sure that, like, when I make this change, and I tested it, and I verified it, and, like, QA verified it, and everything is good to go, you're still, you know, you haven't forgotten anything. And so, I think of it more of like a...I think of like a ...talk about like documentation, returning to that concept. I think of the test suite as the for really real documentation of, like, what the requirements for this piece of code are, not telling you whether you're right or wrong. But, like, this is what it has to look like in the end. \n\nAnd it is a sort of a self-enforcing, self-updating documentation in that, if it fails, well, then you're going to have to get right with it one way or the other and say, like, \"Okay, well, okay, it’s not like that anymore. Not really.” Or, you know, oh, oh my, you know. But it's neither necessary nor sufficient to ensure that your code is right today, right? It's this long-term institutional memory that's formally specified, pretty formally specified, right? But it isn't, like, did I ship a bug? Maybe, you know. Maybe. \n\nMIKE: We did touch on this earlier in the call before you joined, but we went into a lot more depth on the weakness. \n\nWILL: Well, then, yeah, ignore my child-like interruptions.\n\nDAVE: No, I think this was valid. I think so. I had a great discussion with somebody about unit testing addition. Like, why would you do this? Everybody knows how addition works. And I actually pulled out two examples from RSpec, and I said, if you use lets and you put them up and you say, expect x plus y to equal z, if you can't find x, y, and z, you have no idea what that test does. If it passes, you have no idea. It has told you nothing about what the application actually does.\n\nBut if I have a test that says, expect three plus two to equal five, okay, it does integers great, but in the very next line, if you see expect Bob plus car to equal Bob car, I just taught you that this thing will concatenate strings using the integer operator, and that is useful knowledge that's outside of what you might expect a system to do, especially if it's a currency adder. Like, why would the cash machine add strings, right? And that would start a good conversation. And that's a cross-check at that point, instead of just a dependent extrapolation. \n\nEDDY: Will, you hit on something that kind of resonated with me, where you said there's very little times where your test will keep you honest and find a bug in your code. But I'd argue that that's what made writing the test worth it. It's those small moments that catch your error that make your unit testing worth it.\n\nDAVE: There's a whole conversation about that, but I've had a conversation of, like, when do you delete tests, and there's stuff where I will write, expect three plus two to equal five ratchet, ratchet, ratchet. And those tests are useless to anybody, except what it is; I've got so many things in play that I just want to lock down every piece until I get to the end. And when I'm done, all those tests document how the system does what it does; I will delete those because they're not useful to any...they're useful to me as an incremental developer to make sure I'm not going to get blindsided by this thing, you know, flapping loose. But it doesn't document what the system should do. So, when I'm done, I delete it, and I'm left with the original spec, which was more of a context integration-level spec. \n\nEDDY: So long as you run your tests with a format and the context and it blocks are really descriptive, that documents itself. That's all I'm going to say. \n\nDAVE: I had a very happy day when Tad said that when you say, rspec dash fd, we all just assume that means format for Dave because I always want people to run with your format turned on. And you can tell which developers just get green dots because they do not write tests that read like sentences. And the people who do, their tests read like sentences.\n\nMIKE: We've talked a lot about, you know, multi-modal sort of testing. Do your unit test, but that is not going to save you. You've got to have an attitude that you're going to try this any way you can. You're going to drag the anvil out of the way [laughs] and get in there. And if we approach our tests that way, you know, we could just get so much more. \n\nAnd when I say test, it's validation, right? And this applies to a much broader thing than just unit tests. Making sure that things work is more than just one thing. I think that's the key takeaway here is that it's more than just one thing. Hopefully, you can put some of this knowledge to use. \n\nAnd till next time [chuckles] on the Acima Development Podcast. ","content_html":"In this episode of the Acima Development Podcast, Mike humorously shares his experiences with his three-year-old son’s unconventional love for books, recounting how his son physically devours them, forcing Mike to create an elaborate security system to protect the family’s book collection. This story transitions into a discussion about problem-solving and determination, linking it to testing and validation in software development. The team laughs about how motivated problem-solving, much like a child's persistence, can reveal gaps in security or design, paralleling the way developers must rigorously test software to uncover flaws.
\n\nThe podcast delves into the importance of validating features beyond just passing unit tests, emphasizing that even bug-free code may fail if it doesn’t meet the right requirements. The conversation touches on the limitations of unit tests, pointing out that they are only as effective as the person who writes them and that they cannot catch misunderstandings in requirements. The hosts also discuss tools like Qualit.AI, which use AI to generate tests, but caution that even with advanced tools, ensuring correct specifications and validation is crucial to avoid costly errors in software.
\n\nThe conversation expands into a broader discussion of testing methodologies, including dynamic application security testing (DAST), the value of cross-checking systems, and the challenges of relying solely on automated tools. The hosts highlight how important it is to approach validation from multiple angles, much like using "belt and suspenders" for security, to ensure robust software that can withstand different types of user interactions and vulnerabilities. The episode concludes by reaffirming the importance of rigorous validation processes, whether through unit tests, security scans, or AI-driven solutions, to catch errors and ensure the overall quality of the code.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I have here with me Eddy, Justin, Dave, and Kyle.
\n\nI have a three-year-old, and he loves books, just absolutely loves books. He devours them. I can't tell you how many books he's been through. The problem is, I mean that literally [laughs]. He has eaten more books than I can count. He just loves the cardboard, chews it right up, removes the binding, tears into pieces. It is a real challenge [laughs]. [inaudible 00:41] the opportunity to read, but, you know, he definitely gets his fill of books, just not in the way that we intended [laughs]. It's the point where we have to take some security measures.
\n\nIn my living room, I have some stairs. At the top of the stairs, there's a bathroom, but next to the bathroom, there is not a full room; it's just a loft. It's an area that's enclosed on three sides by the boundaries of the house and then a wall with the bathroom, but it's not enclosed along the railing. So, you can look out over the railing. And it's open. It's not a full room. And there's no door. You just turn left and walk into the space, and that's where we have our books. And, you know, we have a lot of books. We like books [laughs]. We're book lovers. We have lots of children's books, lots of shelves of books. And he'd go in there and just have a meal. So [laughter], that's a problem.
\n\nSo, we started coming up with tactics to dissuade him from doing so. You know, we can always go in there, and grab a book, sit with him one on one. But we're trying to encourage him to appreciate books in a different way. We tried to child-gate. That didn't last long. He learned how to climb over it within weeks. So, we got rid of that. I put up a sheet of plywood and thought, well, this will dissuade him. That did dissuade him for a short amount of time. He figured out how to move that out of the way. I literally put an anvil in front of the sheet of plywood. And you know that if you're very determined, even if you're three years old, you can slide an anvil across the carpet, and he got in.
\n\nAnd, eventually, the solution I had to do was to mount. I cut the plywood down a little lower. It's over a meter [laughter]. It's about...it's a little under five feet high probably, and, you know, I think, like a meter and a half. And I've got it mounted on hinges, hinges for a gate, so gate hinges. So, it means they can rock both ways. So, you can turn it, you know, 180 degrees. And I've got that mounted into the stud in that part of the railing. It's an enclosed railing, So, I've got it mounted into the stud, so it’s solid. And I’ve put a gate latch on the other side that it mounts into.
\n\nAt first, we got this, and it worked. But pretty soon, he figured out how to undo the latch. So, we had to get a wire that had a screw class that held it together. He got through that, too. So, we have a padlock with a combination on it [laughter]. I hope that you get some sense of how impressive my son is [laughs].
\n\nDAVE: This is motivated problem-solving, absolutely.
\n\nMIKE: Absolutely. Extremely motivated problem-solving.
\n\nEDDY: Having a three-year-old being able to slide an anvil across the carpet is pretty impressive, just saying.
\n\nMIKE: The truth is, he did that about a year ago. So [laughs], you know, he, yeah, he is strong and dedicated. I'm not going to go into all of the stories [laughs]. The other day, he saw a package on the front doorstep. So, he opened the window, pushed out the screen, jumped out the window, ran over, got the package, and came inside because he couldn't reach the latch on the door.
\n\nEDDY: He'd make a really good QA member.
\n\nMIKE: He would. And he'd make a great, well, he'd make a fantastic QA team member, which is the perfect segue into our topic today [laughs].
\n\nWe're going to talk about validation of our features. And there are lots of things that people talk about to make, you know, your code good. And, you know, we talk a lot about unit tests. We focus a lot on unit tests. We've had multiple podcasts talking about RSpec [laughs] and best practices in that particular library for testing, which is great. I love unit tests. They give me a ton of confidence.
\n\nI've also had experiences in the past where I have written some code, written the unit tests, gone through testing, everything worked perfectly, got it deployed, and then realized that it didn't meet the requirements [laughs]. Regardless of how well it was written, it missed the point, right? It missed the mark. And that is completely outside of what RSpec can save you from. Unless you have...you just can't. Like, if your requirements are wrong, if you misunderstand the requirements, then your specifications are not going to catch you.
\n\nEDDY: Well, RSpec is only as good, or a unit test is only as good as the author, right? It can only be as good as the person who writes it.
\n\nDAVE: The problem behind the problem is you built the wrong thing. There's no amount of tooling that can save you from successfully building the wrong thing.
\n\nJUSTIN: Well, I went to a presentation by a company called Qualit.AI. They have AI tests or their tests are generated by an AI. And it's actually pretty interesting. You can feed it the specs that are written by the product owner rather than engineer. And, theoretically, it will solve some of that problem.
\n\nMIKE: But, again, if the specifications are written wrong, we have trouble, and there's a gap there. Now, you can only take that so far. You know, at some point, people have got to get it right. There's this really important component of creating the validation instructions to make sure that we get out the feature that we really want early on. And you can have bug-free code, technically bug-free, because it does exactly what you told it to do that is not the feature you wanted.
\n\nFurther, unit tests live as a unit, right? They test a unit of code in isolation. By design, it makes them fast. It means you can run your test suite and validate your code quickly. They do not run an integrated test to make sure all the components run well together. And that's another prong of a testing strategy. There are also things like security tests, you know, penetration tests or probing for libraries with security holes. I mean, there are a whole range, a whole range of ways that things can go wrong.
\n\nAnd the way that you validate your code is the way that my son does. He works on it until he gets to that book. And unless it's essentially impossible for him to get in, he's going to be eating that book. And sometimes, we don't have quite that attitude. Sometimes we think, well, you know, I think it passes the unit test. It must be good. You know, I've written good code here. And once we start to get a little lax there, we get ourselves in a lot of trouble.
\n\nJUSTIN: This kind of goes into what type of testing you want to do. And the reason I bring this up is I'm in charge of the DAST testing at our company, and we use a tool called Rapid7. And one of the things that it does is it does, basically, you know, it scans the application, and it just shoots everything under the sun at the application, and it's not looking for functionality. It's not looking for usability. What it's looking for is vulnerability. And so, it's like, a specific type of thing that you're looking for, I mean, that kind of drives your testing, you know, what type of testing you're doing. And the test suite that Rapid7 uses takes basically two days to run. So, we always run it Friday at like, you know, 4:00 p.m.
\n\nBut it's just kind of nuts because it throws everything under the sun at every single form parameter API that it can detect. And, you know, it gives you results, and you've got to parse through them and everything and, you know, kind of see if they were useful or not. But I think it goes back to, you know, you've got to test with intent and, you know, what you're looking for as a result of it depends on what type of test you're running.
\n\nDAVE: You said DAS testing, that's dynamic application something, something testing?
\n\nJUSTIN: Yeah, security testing?
\n\nDAVE: Security testing, okay.
\n\nJUSTIN: Yeah. So, it basically scans your application. It pulls all the endpoints, all the submits, all the things like that, all the gits. And then it just puts trash into every single parameter that I can figure out, and then it just looks at the results. And it's not like it's...like I said, it's not looking for UI results. It's not looking for usability. It's just looking at vulnerability results, which it has a limited, I mean, semi-limited set of expectations that reveals a vulnerability. It is something that can be automated, but it's like something that is, you know, thousands or tens of thousands of results that fit within, you know, that could reveal a vulnerability.
\n\nMIKE: And that kind of captures an aspect of testing that we don't always think about. Sometimes we think that our attackers are really savvy, like, nation states [chuckles] that are going to come and break into your system. You know, honestly, I've read, you know, if a nation-state wants to scan your system, they probably will. And they have reason to keep it private, so [laughs] they may get in there and just lay low. What really is the kind of attack, you know, is not a sophisticated mastermind. It's like a horde of zombies.
\n\n[laughter]
\n\nJUSTIN: Are you calling our users zombies? [laughter]
\n\nMIKE: I am not disparaging our users because it's not just our delivery users, you know, there's scripts out there. There are bots. But, you know, it's a way of thinking about the users, right? There are a lot of things that they do by accident. You give enough time; somebody's going to click that button [chuckles], whatever that button is.
\n\nI had an experience somewhat recently where there was a button that had worked. Nobody had used it in a while. Somebody clicked the button, and the data set had gotten large, and so it put a lot more load on the system than it had historically. They probably didn't even mean to click the button [laughter]. But, you know, and they're curious. What happens if I click this one [laughs]? And, you know, you will have intelligent users who will come up with clever workarounds, absolutely. But you also have the accidents, the bumps, the shambling horde bouncing around on their keyboard [chuckles] through your application, knocking stuff down. And you have enough of that; if something can be broken, it will.
\n\nAnd we get in a lot of trouble because we build this feature, and we think I’ve built this perfect feature, and this is exactly how it will be used. And the interface is perfect, and people are going to come and use it. And the first person comes, and they use it entirely differently and the thing blows up because you misunderstand the way that people use things. All of us like to explore the boundaries. We want to get and eat that book.
\n\nDAVE: Delicious, delicious literature, yeah.
\n\nJUSTIN: You know, when you went with that metaphor, I thought you were going to go developers wanting to get their code to production, and they'll figure out all the different paths that they can do [laughs] to get it without having to pass through the gates that you set up, including QA [laughs] and, like, automated scans and things like that.
\n\nMIKE: Give a junior developer a path to deployment, and they will use it [chuckles] or a senior --
\n\nDAVE: Developers interpret IT as damage and route around it, like, 100%.
\n\nJUSTIN: [laughs]
\n\nDAVE: And it's not because IT is bad. It's because developers are...we optimize horrifically. There's a related thing. Richard Feynman was on the Manhattan Project, worked on the atom bomb in the 1940s. And he went out to Los Alamos, top-secret middle of White Sands, New Mexico. And, like, there was a scramble project. Like, we got to go invent the atom bomb. So, they had built this little shanty town. It was all super top secret. You couldn't go in and out. They had to put a fence around it.
\n\nAnd they were building this camp while the scientists were trying to work in it, which meant they had a great big construction crew, and the construction crew wasn't allowed to be in front of the camp where the gate was. So, they put a great, big chain fence around it, and then they cut a hole in the back of the fence so the construction workers could get in and out.
\n\nAnd Dr. Feynman's like, what? Guards, gates, guns, top secret, and there's this hundred-foot section of fence that's just missing on the base. And everyone he asked was like, “No, leave it alone, leave it alone, leave it alone. Don't ask questions.” And so, he's like, “Okay, here's the thing, if I walk in the front gate, you have to sign in.” And, like they take an inquiry of what you have with you on your way in and out. “If I sign in and then go out that hole in the gate and then sign in again, they will immediately arrest me for stealing stuff, for, like, exporting things off of the base. So, I did it the other way around.”
\n\nHe walked in the base through the hole in the fence and then signed out, and then walked in through the base. And every time he's signing out, they're patting him down. He's got nothing. He says, “The fourth time through, they arrested me [chuckles], which is what they should have done.” And the next day, that hole in the fence was fixed. And it took him validating the security flaw before he could get anybody to take the security flaw seriously. And I want to say the construction camp also was allowed to move forward because they realized, oh yeah, we're strangling you guys. I don't think Dr. Feynman was popular with the construction crew after that.
\n\n[laughter]
\n\nSo, a real quick anecdote. This happened to me in 2010, which is a long time ago, but also way too recently for this noise to be happening. I had a developer, senior developer look me dead in the eye and say, “Every line of code has a chance of introducing a bug.” So, if you write as many lines of test as you have lines of code, you are doubling your chances of defects.
\n\nAnd he was dead serious that you should not write test code because it doubles the chance of writing a defect. And like, yeah, there are facepalms going on in the cameras right now, yeah, 100%. And I was so stunned. I was so flabbergasted by this that I had no response, and he declared victory and moved the conversation on. I'm like, no, no, no, no, no, no, this is not the victory face that I'm making.
\n\nI finally was able to come back and say, “Okay, here's where you went wrong. You are saying that every time you work a math problem, you might introduce an arithmetical error. You might forget to copy a zero or copy a five as, you know, as a seven, or something like this. What you are telling me is that if you take the test and then you check your work, you are twice as likely to write an arithmetical error, and that is true.
\n\nYou had 40 problems. You're now working 80 problems because you're working every problem twice. But the error in one is unlikely to be reproduced in the other, and the chance of you getting a higher grade on your test is significantly higher because attentional errors don't happen on cue. Attentional errors happen randomly, and that's what checking your work will catch. And I keep that in my back pocket when I start thinking about good tests versus bad tests.
\n\nGoodhart's Law says that as soon as a measure becomes the goal, it ceases to be a good measure, and code coverage is the same way. Like, when you turn in a PR, you must write a test. And there are times when the developer they wrote the code they just want. They want just enough tests to get their PR approved so they can get out the door. And you can tell, right? The RSpec context barely read like English. They don't string together coherently. They took the matrix of all things and just blotted it out into a big, old file. And, more importantly, if you change the source code, the test doesn't break. And if you change the test code, the source code may or may not relate to it, right?
\n\nAnd the other side of this is that if you want to actually upgrade the code and change the architecture of it, the test breaks, like, tests outside of that code start to break because they've got their fingers reached in. This is that, this is the you took 40 problems, turned them into 80. And if any of those 80 has a problem, you get an F on the test. That's what that kind of testing is like.
\n\nWhat makes a good test is when that test works as a cross-check. And, for me, and this speaks to validation, and I promise I won't spend much time on my soapbox, but I'm going to get on it. Write your tests first. You will write better code. You legitimately will write different code if you write your test first because the test will force you to write code that’s testable.
\n\nNext time you're trying to test some code, you go, man, this is really hard to test; just look yourself in the mirror and say, “I did this to me,” because you didn't write your test first, right? One drives the other. The test must conform to the code versus the other way around. And if your tests declared their intent, it's very hard to copy the architecture and details of the how you did it if all the test says is what has to be done. But if you write the code first, oftentimes, you just want to get your code coverage up.
\n\nSo, you write a test that just duplicates the how, and now you've got twice as many lines of how, and a bug in either one is going to slow you down. The maintainer can't maintain the code because the tests are going to fight because, yeah, it's terrible.
\n\nAnd this gets me thinking about things where when any one of these things can fail. If the whole system goes down, you have a very delicate system. And if any one of these things can validate the system, you have a very strong validation system. Not to dive randomly down a weird crossed metaphor, but I'm going to say firearms because that's a topic that it's a little political but more importantly, it gets everyone going, “Wait, what?” And it gets everyone paying attention.
\n\nThere's four rules to firearm safety. Always assume the gun is loaded. Never point your gun at something you don't intend to destroy. Keep your finger out of the trigger guard until you're ready to shoot. And always be sure of your target and what is beyond. Those four rules. Here's the thing: if you break any one of those rules, the other three will save you. If you break any three of those rules, the other one will save you. In order to injure someone with an accidental discharge or a negligent discharge, you have to break all four rules! Versus –
\n\nEDDY: Did you mention the safety? Sorry, I was listening [inaudible 19:48]
\n\nDAVE: Oh yeah, yeah. Sorry, I did not, and that's because I stated keep your finger off the trigger. Keep the gun on safe and your finger off the trigger until you're ready to shoot. Yep. You're right. Thank you.
\n\nEDDY: That's kind of a huge gap.
\n\nDAVE: Thank you. You phrased that...Yes. Yep. Yep.
\n\nEDDY: [laughs]
\n\nDAVE: Yeah, no, it's a good one and absolutely valid. And the thing is, you have to break all four of those rules before you can run into this problem. On the other hand, you'll see tests where if you don't do this thing, the whole system blows up. If you don't do this thing, the whole system blows up. If you don't write...all four of those things have to be true in order to keep people safe. That’s a very risky operation.
\n\nAnd if you write your test after the code and they duplicate the how, it becomes every single line of test code must duplicate the implementation of the code, or the tests won't work. And if you want to modify the code, your test will fight you. But if they cross-check each other, then you can change the implementation and the tests are still happy because it still works, right?
\n\nAnd you can update your tests without having to rewrite the code. Yeah, it's nice. It's not easy. I will freely grant people that are annoyed and frustrated by this the reason we don't do it is because you don't get taught how to do it, and learning how to do it after the fact is very hard to do. And it is so worth it. All right, I’m off my soap box. Thank you.
\n\nMIKE: You got me thinking about some mathematical evidence of this. Has anybody here ever used a Kalman filter?
\n\nDAVE: Sounds familiar.
\n\nMIKE: Okay, so let me give some explanation. The math can get hairy, but the intuition is actually really simple. They use this in self-driving cars and vehicles of all kinds. Let's say you want to figure out where you're at, and you've got a few different sensors, and each of them is kind of iffy, right? It kind of can tell where you are. None of them are all that great. And if you think about how probability distributions work, they're often modeled with the bell curve, right? Gaussian curve. And if you have a really bad measurement, then that curve is going to be really flat and long, right? Because it can be kind of over a wide range.
\n\nHere's the magic. If you have two of those two really wide, flat, Gaussian curves, and you think, what happens if you combine them? What happens if you multiply them together to get the combined distribution? It is a narrower distribution and with a higher spike every single time. And if you have four different sensors, they're giving you four different distributions. You're tightening that up until you have a really good idea of where you're at. Mathematically, if you combine those probability distributions, you end up with a much better awareness, you know, from most sensors as to what they're trying to sense. Here, we're talking about tests.
\n\nDAVE: It’s genius.
\n\nMIKE: You’ve said that you want to validate that you haven't broken something. And all of your validations have their own flaws. But if you combine them together, you have much greater assurance than if you use them independently.
\n\nJUSTIN: So, how would you combine them together?
\n\nDAVE: There's a thing that I heard about from the ‘80s. And the way you combine them, right? You don't want to have one dependent on the previous; depend on the previous because that extrapolates. Your error makes it worse. I want to say it's called Bayes’ Law? Don't quote me on that, but the story behind it is if you Google how many piano tuners are there in Chicago, that's the story that everyone tells with this. When you try to guess, I have no idea what it is, the more variables you can guess at, the more accurate...and you're completely guessing, right?
\n\nWhat is the population of Chicago? I don't know, but let's guess. Let's say it's 10 million. Maybe it's 1 million. I could be completely wrong. It's probably not 450 million. That's more than there are people in the country. But some people are going to guess that. Most people are bad at estimation. If I had to guess, like, 8 or 9 billion of people are bad at it [laughter]. So, anyway. But if you guess too high on the population, your next guess is what percentage of those people have pianos, 10%? 1%? 50%? I don't know. I might be right. I might be wrong. But there's a 50% chance that my wrong is going to be in the other direction and that's column filtering.
\n\nThe more things you can add, how many of those people, how long does it take to tune a piano, versus how much does it cost to tune a piano, versus how much money does a piano tuner need to make, you start throwing enough variables out at this, you start coming down with, well, you need to make this much money, which you’re going to have this much work, which you’re going to have this much lead time. That means the pool must be this big, which means there must be this many piano tuners in Chicago.
\n\nAnd if you worked out with enough variables, you start getting spookily accurate, assuming that all your efforts are our best guesses and that you never make the mistake of saying, “Well, if there's a hundred piano tuners, they will have a thousand tools.” That's chaining. That's going to multiply your error. It's when your errors cross-check each other that it gets spooky and amazing.
\n\nMIKE: Just so you know, it's kind of hard to find a piano tuner in Chicago [laughter] from personal experience.
\n\nDAVE: Okay, that's another point of data, and we'll just put that in the [laughter] -- Is it easy, or is it hard?
\n\nEDDY: So, are you telling me, Dave, that I should or should not buy a piano?
\n\nDAVE: Yes, absolutely. Actually, no, the correct answer is no.
\n\nJUSTIN: I know how to play the piano. I know how to, and I have the piano tools, but I've never been paid for it, unless I would pay myself.
\n\nDAVE: There you go. Oh, that's a good point, yeah. That becomes another set of things. Is there a shade tree market for this, right? If piano tuners are really rare and really expensive, there's going to be a shade tree market for people doing it for free. You can go down that complete crazy raffle. It's fun.
\n\nThere's a Numberphiles. Anybody here look at Numberphfile on YouTube, number P-H-I-L-E? It's a British channel. They get into math and science and stuff like this. There's one on estimating the number of tanks in Germany in World War II. There was one part of the transmission that had a serial number, and they knew the serial number started at one and that they incremented linearly, and they said, every time you blow up a tank, get us that number.
\n\nAnd it turns out that if you have serial numbers selected at random, you can estimate how many total there are. With five or six guesses, you're within 1% of the actual total number. It is spooky. They had, like, 15 number samples, and they came back, and they said, “Germany's making 251 tanks per month,” and the actual number was, like, 249. They nailed it off of what looks like random numbers. And it's because of the column filtering. Every random number starts to exclude the extreme.
\n\nMIKE: So, how do we use this to our benefit?
\n\nDAVE: For me, it comes down to cross-checks versus that...depending extrapolation. What is a question that I can ask that will exclude the greatest number of things, and will that thing exclude valid data, right? I need to go look up a thing. Eddy and I had a conversation in private the other day that talked about...oh, it was about a comment. Okay, I realize this may not sound like validation, but Eddy had a comment about a comment that I wrote in the code because RuboCop demands that we comment our classes, right?
\n\nSo, we get class transfer group, and RuboCop will say, “You must comment this class.” And the poor maintainer who's never seen this and they're just trying to document the code and satisfy RuboCop they'll write, “This is the transfer group class,” which is a completely useless comment, complete waste of time.
\n\nWhat is the thing that you can say about this class that will communicate the most information that will be valid? I have to start saying things about, well, what is a transfer group? What does it represent? Well, it's this thing. I start talking about this business need. Well, that makes me nervous because if the business need changes, that transfer group it's now mislabeled.
\n\nBut you can kind of look at what you wrote and start to see if that definition changes, like, somebody comes along later and says, “We're going to use transfer group to identify merchants that are related on this other access.” Well, that's not a transfer group anymore. That's a related merchant thing. And that comment, while now inaccurate, is going to immediately tell a maintainer, “I am now mislabeled.” And that's because this class is now incorrectly named because some future maintainer changed the meaning of what this class was. And that's a great time to re-document the class, or rename the class or both.
\n\nEDDY: That’s assuming that the person --
\n\nDAVE: And that's a long way of saying --
\n\nEDDY: I was going to say that's just assuming that the person who happens to touch that class and alters it also reads the comment and remembers to do it.
\n\nDAVE: That's true. Okay so --
\n\nEDDY: So, documentation is only good if you still keep it up to date; that's all I'm saying.
\n\nDAVE: So, I have two unfortunate facts for you. The first one is documentation is the first thing to go out of date every single time because you'll get a maintainer who's in a hurry, and they want to make it work. They'll come in, and they'll fix the bug. They won’t even read the comments. The other unfortunate fact is that when you are not familiar with the code, and you're reading through it, you will believe a comment over the code. I have literally; I kid you not; this was in Assembly language, so it was slightly encoded. But if the line of code was mov eax1, which means move a one into the AX register, the A register on the CPU, the comment was put zero in AX, which is the exact opposite of what that statement did.
\n\nLanguage primary used to be 40 years ago; if you wanted to put a zero in a register, you don't move a zero. That takes two clock instructions. You can XOR a register against itself, and any number XOR itself is zero. So, you write XOR EAX comma EAX, one clock cycle you've got a zero in AX. Great. You're done. Somebody came along later and said...so, somebody had written, mov eax, zero, put a zero in it. They came along later and said XOR EAX with itself, and they commented it to say, “Put a zero in EAX, so that you'll know...” why are you XORing...oh, we're putting a zero in it. Great.
\n\nA maintainer came along later. That needs to be a one, not a zero. They changed it back to mov, and they left the put a one or put a zero in AX. And that comment stood for 15 years because nobody dared remove the comment. People believe your comments. They are important. Please write good comments. And don't document what the code is doing. Document why the code does what it does; that way, that comment will last.
\n\nJUSTIN: No, I ran into that exact situation earlier this week. There was a comment in the content of the security policy file. And I was like, is that still valid? And it took me, like, three or four hours to track down. And the comment was not valid anymore. It was giving people bad information. I was like, okay, now I got to go in and change this, remove this comment.
\n\nDAVE: And when you have a comment in there that says, “Vendor X refuses to whitelist our server,” and then you've got this egregious violation of, like, hard-coded IP address or something like that, that's actually a good comment because it doesn't say “Hard code the IP.” If I write hard code the IP, I can see that. That's in the line of code where [inaudible 30:51] follows it.
\n\nBut seven years from now, when vendor X doesn't even work with us anymore, and we don't need this whitelisted anymore, that comment of Vendor X doesn't whitelist us, you can then go, oh, we documented the intent. We documented the discussion. I can now validate without any extra help that this is garbage. This code is now suspect. But ten years from now, we have all kinds of code in our app, and it's not just us. Every place I've ever worked, you'll see code that's five years old that says, “Put a one in EAX, and the line of code below it puts a one in EAX,” and you don't need that one in EAX anymore. You haven't needed it in three years because you don't work with that vendor anymore. But the comment just documents what the code does, and that remains true, and it's useless.
\n\nSo, the cross-check is, why do we want this? Some of you guys have heard me say, when you write up a Jira ticket, don't document the decision; document the discussion because, a year from now, that decision is going to be wrong. And you've thrown away the discussion that would help a future person say, “Oh, that discussion is still valid, and the decision is now different because of a dependent fact.”
\n\nEDDY: Which is why I always push for, like, a more public open discussion.
\n\nDAVE: Absolutely.
\n\nEDDY: Any time any [inaudible 32:07] decision is being made, whether that's in a pull request, whether that's in a Jira ticket. It does not matter, right? Have it in a more open forum so that other people who stumble upon that same thing can be like, ah, that's why we decided to do it this way, instead of [inaudible 32:23]
\n\nDAVE: 100%. 100%
\n\nMIKE: I'd like to latch on to that a little bit. You just said the discussion in a public forum is an important tool for generating quality code and avoiding defects. There's no clear, like, linear relationship between those two that leads to this. But I think you're absolutely right. In fact, I think that may be the most important thing we can do to lead to quality code. Because something that's...what do you say? Sunshine is the best disinfectant?
\n\nDAVE: Mm-hmm. Mm-hmm. So, I think it was Will was on with us. Will joined the call; by the way, partway through, people listening at home. It was Will that said he hates when people DM him a question that should be in the knowledge base. I don't want to put words in your mouth, Will. I think what you said was you want people to ask you in public so that the conversation is documented in the channel.
\n\nWILL: Always. Always, always, always, always, always, always. DM me for personal stuff, for sensitive stuff, or whatever, but I don't like any technical discussion in DMs ever, ever. I can't think of an exception.
\n\nEDDY: Can you dissect that a little bit? I think that's really important. Because I feel like, in practice, that's not really the case, and I'm wondering if that's something that can be implemented across the board.
\n\nWILL: There's a couple of things going on. So, one thing is I work in a distributed team, right? I don't like the word remote; it's distributed, right? And so, some of that is particular to that sort of, like, that sort of workflow, in that, like, I've never been in a room with any of these people, and I probably never will be. So, a lot of implicit communication and scuttlebutt and, like, what's everybody, like, doing over here, you know what I mean? Like, if you just see a cluster of people freaking out on something, right, then you'll naturally gravitate to it, and there's an implicit communication there. So, like, you want to do that. And it's just visibility. You’re like, what's going on, and why, right? And I think that's really valuable.
\n\nAnd the other one is like, as we said, sort of, like, documentation, it is, to a degree, self-documenting code. One habit that I've gotten into working in a big organization, you know, with a lot of different functional groups and a lot of different workflows, and everything's changing all the time, right? The documentation isn't the documentation. We have, like, a big Confluence Wiki, and that's fraudulent. It's hilariously bad.
\n\nMIKE: [laughs]
\n\nWILL: Like comically, a comic misrepresentation of someone's hopes, dreams, broken promises, et cetera. It's all garbage. With Slack, if you're a good Slack --
\n\nDAVE: Confluence is where organizational knowledge goes to die.
\n\nWILL: And/or Jira archaeologist, you could find the tea, you know what I mean? GitHub, Slack, and Jira. Because those things are all, you know what I mean, like, Jira's maybe the least accurate. But, like, everything that gets through had a ticket, right? So, somebody touched it. And then, Github is the word of God, right? Like, that's it.
\n\nAnd then, Slack is just sort of useful for the things that didn't make it into a PR, where it's just like, oh yeah, the app broke because this symlink was wrong to this version of Python. Then you had to go in and hand-edit this thing. Well, yeah, I see you laughing, Justin. But you know just as well as I do that that problem right there, you've seen it, or variants of it, and that's going to stop your whole development team cold. You're dead in the water. Stone cold stopped.
\n\nJUSTIN: Those data science team.
\n\n[laughter]
\n\nDAVE: Jerks.
\n\nWILL: Yeah. And there's other stuff where it's just like, something will screw up. There'll be some stupid workflow that I need to know once a year. And, like, once a year, I'm frickin **** if I can't...oh, what was that? And it's not worth documenting. I mean, it is, but I can't justify it to myself. Anyway, so, I mean, that's my general philosophy on that. And I would say, like, you know, both, like, I encourage everyone, across the board, think really hard about doing this, and it will bear fruit over time. Even if it's stupid, man, because if you keep –-
\n\nEDDY: I've had someone tell me that the code is the documentation.
\n\nWILL: I mean, it is.
\n\nEDDY: I mean, yes and no. Yes and no.
\n\nDAVE: I'm just going to say no, not even yes and no, just no.
\n\nEDDY: Yes and no.
\n\nDAVE: That's like saying the product documents the workmanship. No. No, it doesn't.
\n\nEDDY: [laughs]
\n\nWILL: I broadly agree with the code as a documentation. Like, just get good, guys. Get good. Just read the freaking code. Just read the code.
\n\nDAVE: Better is better, yeah. Better is better. That's tautological. Yeah.
\n\nEDDY: The thing is, it would take me longer to look at a code to see what it does than if you just had something to tell me what it does.
\n\nJUSTIN: You need a ChatGPT or something [laughs] to tell you what it does [laughter].
\n\nEDDY: Copy this whole class and ask it, “What does this class do?”
\n\nJUSTIN: It's freaky. It works a lot of the time. But, anyway, that's kind of here nor there.
\n\nDAVE: We're doing a Copilot demo. In the lesson, the presenter was saying, “If you ask Copilot, ‘What's your favorite flavor of ice cream?’ It will say, ‘I only want to talk about code.’” So, I immediately started trying to get Copilot to talk about ice cream with me. Like, well, okay, but if you did what would...and about the third time through, Copilot said. “You have SQL embedded in your Ruby code.” I'm like, okay, to be fair, that's more important than what I’m [inaudible 38:15] [laughter]. I thought that was hilarious. Like, okay, yeah, yeah, you're right. You're right.
\n\nKYLE: I have found that it will work if you tell it what you're talking about is code; it'll talk with you.
\n\nEDDY: Oh, I've never had to try to have a human conversation with AI. It's still too weird to me. I refuse to accept it.
\n\nDAVE: I've been playing a lot of [crosstalk 38:38] lately, and it goes weird. It goes weird in some really interesting ways. Yeah.
\n\nMIKE: [inaudible 38:44] that will tell me what your favorite kind of ice cream is.
\n\nJUSTIN: So, my AI anecdote of the week was I was at a choir this week, and I wanted to know if I was singing off-key because we're in a choir, and sometimes it's hard to tell. And I asked Claude.ai, which is my favorite AI tool, “Write me a Flutter app that would use my phone's microphone and tell me if I was off-key or what note I was on.”
\n\nAnd within a five-minute conversation, it gave me working code, and, you know, I could have run that at my house and had it running on my phone. And so, it's just like, that was my, you know, oh my goodness, holy smokes AI of the week, you know, using libraries I wasn't familiar with using, you know, other things, but they were the right...I mean, it was working. I don't know if it was like, I mean, it was okay from an architecture point of view, and it was, like, an easy solution for the tool that I was asking for.
\n\nEDDY: Here's my problem with AI. It's like you have to speak to it like it's a toddler. Let me elaborate.
\n\n[laughter]
\n\nDAVE: They're getting better currently. I know what you mean. I know what you mean, yeah.
\n\nEDDY: You can't just say, “Hey, go up the stairs.” You have to be like, “Hey, get up. Use your limbs. Use one after the other. Grab the railing on the side. Start with your right foot, then your left, then your right, then your left. Make sure you don't fall. Keep your balance. And then, when you make it on top, stop [chuckles],” You know what I mean? Like, you've got to be very, very specific for it to be good, right? Like, if you ask it very vague questions...it's getting a little better, but it still hallucinates.
\n\nMIKE: Just like a toddler, also they ingest lots of books.
\n\n[laughter]
\n\nDAVE: Exactly. So, if you want to spook yourself, ask the hard question, but then start a conversation with the AI about the hard question. For example, I just asked ChatGPT because it's saving out old chats now, and I asked it just now while we were chatting, based on my conversational history, what do you think my favorite flavor of ice cream is? It got the right answer.
\n\nEDDY: Vanilla.
\n\nDAVE: Salted caramel.
\n\nEDDY: Oh.
\n\nDAVE: Like, legit.
\n\nJUSTIN: Whoa, oddly specific.
\n\nDAVE: Yeah, oddly specific. And it explained like, the AI it said, "Based on our chat and your quirky sense of humor, it's going to be something oddly specific and nontraditional." So, it was like, espresso, salted caramel, and one other, like, bubble gum or something like that. And I'm like, second one, salted caramel. So, there's stuff in there. Have ChatGPT guess your age based on your chat style, on your writing style. It will decline at first because it doesn't want to, like, trigger you, or, you know, like [laughter], like, it's programmed [crosstalk 41:34]. Well, it's programmed to not say things that would get it canceled, right?
\n\nEDDY: It's like, Dave, based on our history, I think that you're ten years old [laughs].
\n\nDAVE: Yeah, emotionally, you are 12.
\n\nWILL: [inaudible 41:48]
\n\nDAVE: But your writing style suggests you're 12 from the 1970s. And I'm like, yep, got me. Yep.
\n\nEDDY: All I'm going to say is that have we all just tried eating books? Because he could be onto something, and books could just be really good. Just eating.
\n\nMIKE: A wad of old, soggy cardboard in your mouth?
\n\nEDDY: There could be something there. Have we all tried --
\n\nJUSTIN: I've been to restaurants that, you know, have been worse than that.
\n\n[laughter]
\n\nDAVE: I almost said the name of a restaurant because there's a place here in American Fork in Utah. They cater to the blue hair brigade, to people over the age of 60 and 70. So, the food has no flavor whatsoever. And yeah, it's a joke in our family. So, you all know a place like that, right?
\n\nKYLE: My immediate thought was to call [inaudible 42:37] pizzas, frozen pizzas
\n\nEDDY: They're actually pretty good. They're pretty good. Don't [inaudible 42:44] on them.
\n\nKYLE: Back in the day, they were.
\n\n[laughter]
\n\nEDDY: Back before I was married, they made good food. So, I have a question --
\n\nDAVE: And then, there's other places that it's ketchup on a saltine.
\n\nEDDY: We did touch a little bit in the AI. I'm wondering if anyone has had any experience to use AI as far as running validations.
\n\nJUSTIN: Oh, I'm glad you brought that up. There is that company that I'd mentioned before at the beginning of this conversation, the Qualit.AI. And they have a lot of good clients. I mean, they're a fully functioning tech company that is taking in money and providing value by using AI to create tests for clients. And it's kind of freaky in some ways because it's like I've written tons of tests, unit tests. I've written tons of integration tests. I've written, you know, end-to-end tests. We've all done the, you know, hey, let's use Selenium to write all our web tests or whatever.
\n\nAnd all of our tests are always brittle and, you know, and they're outdated in the next release. But it's like, you go in there with good intentions, and it turns out to require a lot of work to maintain that test suite. But, all of a sudden, you can take your application and your specs and throw it at this AI, and you may not have it perfect, but it gives enough value that people are willing to pay a lot of money for it. And it's interesting and it'll be even more interesting in a couple of years where the AI becomes even better at maintaining those. And you just, like, throw your documentation at it, and then your application endpoint, and, you know, you say, "Hey, tell me if anything's wrong with this." and it comes back five minutes later.
\n\nMIKE: I think there's something really pertinent here. We've talked about how AI makes mistakes. And so, now we're back in the exact same boat that we are in for ourselves in that I'm writing some code, and it might have some problems. So, what are all of the things I can do to validate this code to make sure that it works? And as we automate some of our code writing responsibilities, the job doesn't change [laughter]. Because our attitude is still, you know, our approach is how do I validate this code?
\n\nDAVE: I just hit on a crazy synthesis of everything we've talked about up till now with this AI thing. One of the things about AI is that the neural networks are formed differently to the way humans build them, like, organically over time, which is why when you get an AI and teach it chess, it will do moves that no human has ever played, and then still win the game. Chess players have trained against existing patterns, and it's doing random things, right?
\n\nSomething that I have noticed over the past month playing around with Copilot is that when the AI hallucinates, it's glaringly obvious to me. But when my co-worker hallucinates, I just accept it as a point of fact. And when you take those two networks and run them against each other, it's a cross-check instead of an extrapolated error. Oh, my head! Oh, I'm so glad I listened to the podcast today. Wow!
\n\nEDDY: [laughs]
\n\nDAVE: There's a blog post or two in that. Wow. Hey, you guys remember blogs?
\n\nMIKE: [laughs]
\n\nWILL: Yeah, sure. Copilot's great. [inaudible 46:07] the way down.
\n\nEDDY: Copilot is particularly accurate, like, 95% of the time. It's really nice when it knows what you want, but when it doesn't, it's kind of annoying.
\n\n[crosstalk 46:18]
\n\nDAVE: But it's a useful annoying. That's what I'm saying. It's a useful annoying.
\n\nEDDY: Yeah. It's like, good idea. I see what you did there, but no, that's not what I want. This is what I want. Be smarter next time.
\n\nDAVE: That's my life goal. Honestly, like if I had a personal mission statement, it would be to be usefully annoying.
\n\nEDDY: [laughs]
\n\nWILL: You'll get there.
\n\nDAVE: Just climbing up that useful tree [laughter]. Got the annoying nailed, so...
\n\nMIKE: So, the recurring theme today, we make stuff that isn't perfect [laughs], and the way to find that is to take a multi-pronged, multi...
\n\nJUSTIN: So, I'm glad you mentioned this. My co-worker, Dan, he says we take a belt and suspenders approach to security, and we do the same thing with testing. It's like, they do the same thing; they keep your pants up, but they support each other. They back each other up. A great example of this on the security side is, we have a number of gates in our automated CI, you know, which include a static code analysis, a dependency checker, a secrets analysis, among a couple of other things.
\n\nAnd so, all those run, and then we also do, you know, we use Wiz to scan our containers, and then we use it to scan our deployed containers. And then, we also do...we pay an external company for a penetration test, and then we also do a DAS scan once a week or, you know. And so, all of those things are theoretically finding the same bugs. But the cost of having a security issue is so high that it's worth it to us to have all these tools checking the same code at multiple points of the SDLC that it's worth it to us to pay that, you know, to pay that thing. And it's kind of nuts, but that is the, you know, one of the costs of doing business in some cases, so...
\n\nMIKE: Where you want to tighten that curve, right?
\n\nJUSTIN: Yeah. But, like you said, David, it's like this and this, and then another dimension coming in on the intersection of all those things gives you a very high sense of confidence that the thing you are doing is correct.
\n\nEDDY: It's so funny that you mentioned the suspenders also help [laughs] keep your pants up. I don't remember the last time I've seen anyone wear suspenders. So, is that really a reliable thing [laughs]?
\n\nDAVE: Get off my lawn, you kids. I've seen them.
\n\n[laughter]
\n\nJUSTIN: I was going to see you pull out your suspenders, David.
\n\nDAVE: What cracks me up is I've actually seen somebody hook their suspenders to their belt, and it's a perfect example of extrapolating your errors because if your belt fails, your suspenders are going to go with them. They're giving you nothing except for something to put on your shoulders, right?
\n\nEDDY: [laughs]
\n\nJUSTIN: And I'm glad you mentioned that, too, because if you are depending or you're testing the wrong thing, you create a false sense of security or a false assurance. So, writing tests for tests, you know, just to have a test there is not very useful, and that’s --
\n\nDAVE: It's almost negative.
\n\nJUSTIN: Yeah, it's almost negative because, all of a sudden, you have to support this extra code. And so that is a, I mean, that's a really important thing is to, like, test with deliberation, with intent. And be aware of everything that's in your pipeline and know why you're doing it.
\n\nWILL: See, I came late, and I think I kind of almost want to offer, like, a little bit of a different perspective on the whole testing thing; I mean, in that, like, I don't really see testing as a tool for finding bugs. I've found very few bugs as a result of testing, writing tests, right? Because I write the tests around my understanding of how the thing is going to work. And if I thought of a bug that I would catch with a test, then I would like, well, you know what I mean? Just sort of like a developer verification or validation of, like what I've written, you know what I mean? Very few things, you know what I mean? Because I just push the button and make sure, you know, pops up with something right before I send it off to QA. And I'm just like, good luck suckers, you know, because it's just like, it's just a waste of everybody's time, and I hate redoing work.
\n\nAnd so, where I get value out of testing and where I think an organization gets value out of testing is in a really formal specification of how this thing is supposed to work. And so, when assumptions around how this thing is supposed to work change, then you have your test suite, God willing, just raising their hand and saying, “Excuse me, what?” So, I was dealing with a team that manages pricing for products across this thing. So, like, pricing is kind of like the last line of defense, right? Like, we have old, old pages, decades old, you know, decades-old pages, right?
\n\nBut they're still getting money. They're still getting traffic. People are still, like, going there and being like, oh, what about a TV? What was a cool TV to buy in 1995? Well, I don't know. I want to know. All right, fine, whatever. That will be a thousand dollars if I can even find one, whatever. And so, they have this ongoing layer upon layer upon layer upon layer like the rings of a tree. Every iteration of our sort of pricing platform that they need to support, right?
\n\nAnd so, they have, like, easily a half a dozen different ways of slapping a price label on a product. And they all have to work because it's literally millions of dollars, right? Some of these long tail links they still convert, you know. And if we screw them up, we can hear about it.
\n\nAnd so, the test suite for that team, and I think a lot of teams, it's just like, if I changed, if I have this new, great idea, that test suite is like a formal specification of, like, these are the wickets that you have to hit, you know, these are the hoops you have to jump through. It's got to work here and here and here and here and here, or else it's no good. And that's where your test suite is going to save you because nobody could think of all these oddball, you know what I mean, oddball corner cases and situations.
\n\nYou build up the test suite to make sure that, like, when I make this change, and I tested it, and I verified it, and, like, QA verified it, and everything is good to go, you're still, you know, you haven't forgotten anything. And so, I think of it more of like a...I think of like a ...talk about like documentation, returning to that concept. I think of the test suite as the for really real documentation of, like, what the requirements for this piece of code are, not telling you whether you're right or wrong. But, like, this is what it has to look like in the end.
\n\nAnd it is a sort of a self-enforcing, self-updating documentation in that, if it fails, well, then you're going to have to get right with it one way or the other and say, like, "Okay, well, okay, it’s not like that anymore. Not really.” Or, you know, oh, oh my, you know. But it's neither necessary nor sufficient to ensure that your code is right today, right? It's this long-term institutional memory that's formally specified, pretty formally specified, right? But it isn't, like, did I ship a bug? Maybe, you know. Maybe.
\n\nMIKE: We did touch on this earlier in the call before you joined, but we went into a lot more depth on the weakness.
\n\nWILL: Well, then, yeah, ignore my child-like interruptions.
\n\nDAVE: No, I think this was valid. I think so. I had a great discussion with somebody about unit testing addition. Like, why would you do this? Everybody knows how addition works. And I actually pulled out two examples from RSpec, and I said, if you use lets and you put them up and you say, expect x plus y to equal z, if you can't find x, y, and z, you have no idea what that test does. If it passes, you have no idea. It has told you nothing about what the application actually does.
\n\nBut if I have a test that says, expect three plus two to equal five, okay, it does integers great, but in the very next line, if you see expect Bob plus car to equal Bob car, I just taught you that this thing will concatenate strings using the integer operator, and that is useful knowledge that's outside of what you might expect a system to do, especially if it's a currency adder. Like, why would the cash machine add strings, right? And that would start a good conversation. And that's a cross-check at that point, instead of just a dependent extrapolation.
\n\nEDDY: Will, you hit on something that kind of resonated with me, where you said there's very little times where your test will keep you honest and find a bug in your code. But I'd argue that that's what made writing the test worth it. It's those small moments that catch your error that make your unit testing worth it.
\n\nDAVE: There's a whole conversation about that, but I've had a conversation of, like, when do you delete tests, and there's stuff where I will write, expect three plus two to equal five ratchet, ratchet, ratchet. And those tests are useless to anybody, except what it is; I've got so many things in play that I just want to lock down every piece until I get to the end. And when I'm done, all those tests document how the system does what it does; I will delete those because they're not useful to any...they're useful to me as an incremental developer to make sure I'm not going to get blindsided by this thing, you know, flapping loose. But it doesn't document what the system should do. So, when I'm done, I delete it, and I'm left with the original spec, which was more of a context integration-level spec.
\n\nEDDY: So long as you run your tests with a format and the context and it blocks are really descriptive, that documents itself. That's all I'm going to say.
\n\nDAVE: I had a very happy day when Tad said that when you say, rspec dash fd, we all just assume that means format for Dave because I always want people to run with your format turned on. And you can tell which developers just get green dots because they do not write tests that read like sentences. And the people who do, their tests read like sentences.
\n\nMIKE: We've talked a lot about, you know, multi-modal sort of testing. Do your unit test, but that is not going to save you. You've got to have an attitude that you're going to try this any way you can. You're going to drag the anvil out of the way [laughs] and get in there. And if we approach our tests that way, you know, we could just get so much more.
\n\nAnd when I say test, it's validation, right? And this applies to a much broader thing than just unit tests. Making sure that things work is more than just one thing. I think that's the key takeaway here is that it's more than just one thing. Hopefully, you can put some of this knowledge to use.
\n\nAnd till next time [chuckles] on the Acima Development Podcast.
","summary":"","date_published":"2024-10-30T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/417a1030-565b-4d25-b25e-5b4e2c9eae40.mp3","mime_type":"audio/mpeg","size_in_bytes":35845301,"duration_in_seconds":3508}]},{"id":"b2e907cd-f139-4806-8ee7-faa54afd8464","title":"Episode 57: How to Learn","url":"https://acima-development.fireside.fm/57","content_text":"In this episode of the Acima Developer Podcast, Dave Brady, along with panelists Eddy, Kyle, Ramses, and Will, discuss the various ways people learn, sharing personal anecdotes and insights. Dave kicks off with a humorous story about learning to swim by being thrown into a lake, which sparks a broader conversation about how some people thrive when thrown into challenging situations, while others prefer a more structured approach. Will identifies with the former, explaining how he learns by setting impossible goals and pushing himself to figure things out, often attributing his approach to an undiagnosed ADHD coping mechanism. Eddy contrasts this with his preference for having safety nets in place when learning, underscoring the diversity in learning styles.\n\nThe discussion also touches on the importance of incremental learning, with Will emphasizing the strategy of \"debugging from the known to the unknown.\" He shares advice from his engineer father, explaining how building knowledge step by step can help navigate new problems. They also dive into how experience in multiple programming languages helps make learning new ones easier, but caution against assuming that all programming languages follow the same rules or paradigms. The group explores how learning through experimentation, much like playing music, can lead to deeper understanding, yet each new tool or language requires its own dedicated study.\n\nThe conversation wraps up with a reflection on the importance of continuing education for software developers. Will argues that the industry often neglects training, which leads to burnout and inefficiency, as engineers are left to constantly catch up on their own time. Dave adds that knowledge is crucial to a developer's career longevity, stressing the need for ongoing learning even if employers don't invest in it. The episode highlights the parallels between music, programming, and learning in general, emphasizing the importance of both structured and self-driven approaches.\n\nTranscript:\n\nDAVE: Hello and welcome to the Acima Developer Podcast. I'm your host, Dave Brady. Today, we've got Eddy, and Kyle, and Ramses, and Will. We've got a really great panel today. We're talking about learning. And Mike usually likes to start with a story, and I don't have a good...I've got too many stories about learning, and I don't want this to be the David Brady talks about his life story again show.\n\nI’ll just start with one of the stories from my childhood, which is that a lot of times, I learned the hard way. My dad taught me to swim by throwing me in the lake. And the hard part wasn't learning how to dog paddle. The hard part was getting the knot untied from inside the sack. \n\nWILL: [laughs]\n\nDAVE: So --\n\nEDDY: The joke is that you were destined to fail because you weren't given the proper...gotcha.\n\nDAVE: Yeah. Except, a lot of times...for the people listening at home, about 30 seconds before we started this call, I told Eddy that he should host, and he said, “No, no, no, no.” And I was like; I'm this close to just making him do it because the best way somebody [inaudible 01:07] that they can swim is just throw him in the lake. And it feels like you're tied up in a sack because you don't feel like you're maximally competent. You are minimally competent. That's what beginning is. And so, yeah, all right, so we took the joke. We overexplained it, and then we turned it into a metaphor. Why not? \n\nEDDY: I will say, David, it's funny because I've met some people in my life who learn best by being thrown in a bag and tied in a knot, and some of them prefer that. They like to just be tossed in the deep and figure it out, you know? I know that there's very little people in the world that learn that way, but I do know that there's a lot of people who actually excel being in a [inaudible 01:46].\n\nDAVE: And, for those people, skydiving and working with cobras is probably not a good career. \n\nEDDY: Will, I saw you raise your hand. Are you one of those people? \n\nWILL: [laughs] It's me. Like, I am that person. Like, I have tried, like, so many times in my life, you know, so many times in my life, to be like, you don't have to do it that way, do you? Not that way. Not again. Again? But how I learn is I get myself in over my head. I assign myself crazy goals, impossible deadlines, crazy projects. I have no idea what I'm doing, and I don't know; I’ve figured it out. I pull it off [laughs]. \n\nEDDY: Is it because you want to tear things open? Like, if they assign you something and they're like, “Hey, Will, get this done,” you prefer to be proactive and undig and, you know, be...\n\nWILL: I think it's, I mean, as I learn more about sort of mental health and, you know, work styles and stuff like that, I think it's just a...I think it's an undiagnosed ADHD coping mechanism that that's the root of it. But, man, I don't know, I mean, like, I think there's a certain level of, like, if I may pat myself on the back a little bit, the breadth of things that I've done pretty successfully over the course of my career is significant. \n\nAnd I don't know a lot of people that have covered as much ground, and I don't know...it's hard to summon up the requisite psychic energy to really push yourself in a completely non-toxic fashion. Jet fuel is deadly poison, but it'll...you put a big enough pile of it under your butt and set the fuse, and you're going somewhere, you know [laughs]? \n\nDAVE: There's a YouTube guitarist named Rhett Shull, and his slogan is, there is no plan B. Like, he will actively destroy plan B. If he wants Plan A to work, he cannot have a Plan B in his pocket, or he'll fall back on it every time. And so, that's literally his channel slogan is, remember, there is no Plan B. \n\nEDDY: I will say I learn way different than you, Will. Like, if you throw me in the deep end and I don't know how to swim, I expect to have a lifesaver somewhere, like a jacket, or floaties, or whatever. It's like, cool, yeah, like, I'll put you in there, but you at least have a safe haven where you can fall back on in case you can't figure out how to swim. That's my personality. However, if you don't give me floaties and you don't give me a life jacket or a vest or anything, I can at least learn how to float [laughs], you know, stay afloat, you know, like, I won't drown entirely. It's just not the ideal spot you want to be in. \n\nWILL: I mean, it's not like I won't ask for help. It's not like I won't ask for clarification or anything like that. I just, I don't know; I mean, that's just how I do it. I need a certain amount of fire under my butt to do my best work. \n\nEDDY: That brings up a really interesting point, though. Like, what are some of those techniques that you do then? If you get put in that situation to learn, what are some of the things that you gravitate to that sort of help you? \n\nWILL: When I'm in it? Yeah, it's one of the best pieces of advice I ever got was from my dad, a capital E engineer, and he always said, “Debug from the known to the unknown,” right? And so, what you always want to do is you want to sort of expand what you're doing, expand your knowledge from a functional state, from a working state, and it doesn't matter how petty, and trivial, and stupid. So, if I was like, let's say I'm going to do a brand-new thing, right? I'm going to write a thing in a brand-new language, right? \n\nLike, I've said this on this podcast multiple times, and you haven't heard the last of it after I get this one out, is start as small as you need to get a functional kernel, a nucleus of something that you can do and then expand from there, which is the easy thing to say, but it's a hard thing to do because the space of a new problem, a new technique, a new territory is big. You don't even know where the edge of the map is. You don't know where you are. \n\nAnd so, you need to collapse down to something functional and then sort of build out from there. And that's, you know, that's the best way that I know to do it. And when you approach it like that, I mean, it really can be a very simple mechanical kind of a thing. \n\nEDDY: I like that. \n\nWILL: I was actually listening to a podcast. It’s the Andrew Huberman Podcast. He was talking about, like, literally, like, a process of learning, right? If I could paraphrase, like, a podcast that I only finished half of, the learning technique, the science that he was sort of describing was saying...he’s like, the key to learning is not so much learning; it's preventing the natural process of forgetting. Your brain is ---\n\nDAVE: Neural pruning. \n\nWILL: Well, your brain's taking in information all the time, right? You're constantly bombarded, flooded with data, and most of it gets thrown out because it's not useful. Your brain is actually really efficient at flushing that cache out. And so, what you want to do is try as hard as you can to establish it, and you build those hooks, tie it in with other things that you already know. \n\nLike, I've gotten really good at picking up languages because I've picked up a lot of languages. And it's just like, you know, somebody who learns seven languages, the eighth one will be easy. Well, if you know seven programming languages, then the eighth one isn't going to be so bad. And so, we're getting new techniques. We’re sort of attaching techniques onto things that you already know how to do. \n\nIf you wanted to write...let's say you didn't know Java, but you knew Ruby pretty well, running a web server in Java, you would have a theoretical construct, a matrix to think about things. It's like, oh, well, I know about, you know, routes in Rails. You know, does my Apache Server have routes the same way? It sure does. Or, I mean, Apache is not the right one, but anyway, I forget, Spring Boot server. And so, you can connect things. So, it's like, oh, Ruby has an array. Java's got an array. It's got a vector, right? \n\nSo, I mean, like, okay, so we've got this and this. Do we both have a hash? Okay, we both have hashes, right? So, we have maps going back and forth each way. And then, hey, you're actually going, right? Like, the wheels are turning. Things are moving for you. And there's not that many new ideas under the sun. You know, like, once you've gotten your hands deep into something, picking up the next thing's not so bad, you know? \n\nDAVE: You sparked a turning thing to what you just said, which is really interesting. I ran into an interesting thing where I started in Visual Basic, and then I moved into C++, and then into C, and then Assembly. I moved backwards, like, down the tech tree, down to where I was like...literally to the point where I was soldering transistors on a board, and then came back up to a high level and very high-level languages. And as I was coming...like, I got a job moving from PHP into Java, and I'd done C++ and da da da da. And I was just like, just tell me where the braces and semicolons go. All languages are the same. \n\nAnd I was talking with a grizzled, old hacker, and he said, “Go learn Lisp.” And I'm like, okay, whatever. And I really struggled with it, and I couldn't figure out why. And, honestly, I bounced. I went and looked at Scheme, and I went, okay, yeah, this is like really, really tight versions of, you know, semicolons and whatnot, but okay, fine. \n\nIt wasn't until I tried to learn Elixir, which is Ruby on the Erlang BEAM, right? On the Erlang virtual machine, and I struggled and struggled and struggled. And this language just kicked my butt, like, nothing would work. And, finally, somebody sat down and said, “You're thinking bols,” B-O-L-S, block-oriented, lexically scoped languages. C++, Java, Python, Perl, PHP, all of these are block-oriented lexically scoped languages, and Lisp isn't, Closure, Scheme aren't. I mean, those are all Lisps. Erlang and Elixir aren't, Smalltalk as well. They live in completely different paradigms, and block-oriented lexically scoped does not translate.\n\nSo, when people say, “What language should I learn?” I'll tell 'em, “You know, go learn...” You know, actually, JavaScript is the perfect example of this because JavaScript is not a block-oriented lexically scoped languages. It looks like people look at it, and they think, oh, this is Java, or this is, you know, C++. It’s not. It’s not even an object-oriented language. It's a prototype-based language, and it will behave like an OO language for, like, 98%. And then, you get this weird bug. Where the heck is this coming from? Well, it's because there's not actually any inheritance in this language. You're just layering a prototype. And there's a key point where the language goes into [inaudible 10:51].\n\nSo, knowing...I 100% agree that seven languages makes the 8th language easy, but you have to be careful when you step into that 8th language to go, is this going to be easy because I know 95% of it, or is this going to be easy because there are some huge differences in [inaudible 11:10]? And follow them very, very carefully. With Smalltalk, it's like, send a message to an object. You don't, you know, don't try to...it's rigidly OO. And if you try to write imperatively like you can in C, it will kick your butt. And it's fantastic [crosstalk 11:23] \n\nEDDY: I will [inaudible 11:23], Dave, because you mentioned something that I think is actually kind of interesting. You said that there was a hindrance because you already had prior knowledge to a language or different languages, and it was a whole different dichotomy. So, do you think that had you gone in without any prior knowledge to any language and had to learn, would it have been easier for you to pick up? Because then you weren't translating any bad habits that didn’t --\n\nDAVE: Let me qualify the term easy because I bounced off of Lisp so hard. I would categorize my first two years of Lisp as failing completely, utterly completely, because I was trying to make the language act like Perl, Ruby, Python, Java, C++. And because I refused to see the languages behaving differently than...I mean, I’d come from Assembly language. Everything was ones and zeros. So, obviously, I know how it's going to act at the high level, right? I didn't. I had no concept of this. And it's because I refused...and this will be a thing that we'll probably touch on a lot, but the map is not the terrain. \n\nSometimes, there's a difference between the map and the terrain. And you can watch people get locked up when the map and the terrain don't match, and they will hammer that terrain until it matches the fricking map. Or they will just circle that part of the map and say, “Here be dragons; don't go there.” And, no, just update the map. That's all you need to do. \n\nAnd so, random 10-second one-sentence thing. The best parenting advice I ever heard was, take the time to get to know your kid because your kid is a different person than you are. And the idea of treating a child...like, I grew up in a generation where children were meant to be seen and not heard. Children were meant to be input only. You're not a transmit. We don't want to hear anything out of you. Taking the time to actually interact with another human being validates them and turns them into a very different person than...right? \n\nI realize that's a really weird analogy, but it's the same architectural pattern. Listening to something that you think you can just transmit nonstop, to learning that you can listen to that is a huge power-up. Sometimes, pay attention to the terrain rather than the map. Did that make sense? Did any of that make sense? \n\nEDDY: [laughs] I like the analogy where you said all your kids are different, right? And you can't treat them the same. And then, you can probably force them to act a way, but then it's not going to be as fluid. It's not as natural because that's not the way the kid is designed.\n\nWILL: Well, let me ask you this, though, because I think you'll probably agree with me, but we'll see. I still think you would pick it up faster, even, like, having some sort of, like, you know, a little bit of blocks, right? Like, mental blocks around stuff.\n\nDAVE: Yes. Oh, 100%. \n\nWILL: I still think you got there faster than if you started from zero. \n\nDAVE: Yes. Oh, yeah, yeah, because once I figured out that I was bouncing off this language, once I realized, oh, it's the map, and the terrain don't match, I was able to go, oh, and then, all of a sudden, that 95% match was able to apply again. And, yeah, and then other things, like, one of the best things I heard in the twenty-teens was, if you want to be really good at Ruby, go learn Lisp because it will make you a better Ruby programmer. And I've meditated on that a lot, right? It's like, why would you learn this archaic language that nobody uses? Because it'll make you a better programmer. \n\nBecause there are things that you will learn that we don't ever use over here, unless you've come from Lisp, if that makes any sense at all. It's kind of like taking a data structures class, you know, or an algorithms class. The first time you learn about Big O Notation, and, all of a sudden, you realize why that database query is taking so long. You don't cover databases in the Big O Notation class, right? You usually are covering algorithms and processing time. And then, all of a sudden, everything around you, like, people lining up at the DMV, you realize this is a Big O Notation problem. And being able to apply the structures to it, yeah, hugely, hugely beneficial.\n\nEDDY: Dave, actually, the reason to my previous question was because I wanted to lead to eventually that final hypothesis, where it's like, yeah, even though a language that you are avid in is completely different on the way it behaves than a new language, you have still trained your brain, you know, to be proactive and resourceful and think like a programmer, to think like a computer, right? And that sort of thing is kind of hard to learn if it's your first time, right?\n\nWILL: I have a only mildly unfair amount of skepticism around programmers that really only know one language well, you know? Like, if you're like, “I'm a Java guy.” I'm like, “Well, do you know, like, Ruby or Python?” “Nah, nah.” “Do you know JavaScript?” “Nah.” “Lisp?” “Nah. Nah, I just do Java or Kotlin, you know, both of them.” And I’m just like, you know, you're not necessarily dumb, but, you know, it's like you open up a toolbox, and it's just hammers, you know what I mean? \n\nDAVE: Yeah. There's two types of seniors that I've seen to do that. First of all, a junior who only knows one language, I'm kind of okay with that, right? \n\nWILL: Yeah, it’s fine. \n\nDAVE: And if you've spent five years without learning another language, that's when I'm going to tap you on the shoulder and say, “You need to go learn another language. You need to get out. You're starting to rut in, right? \n\nBut I've seen a programmer with 30 years under his belt who was just C, not even C++, just C. And he was really, really, really good at programming firmware. Like, this man knew his hardware inside and out. So, he was basically using this language to do his career. His career was not programming, if that makes sense. \n\nThis guy, man, he knew graphics cards, and he knew things about like, “Oh, yeah, the 3D chip is probably going to be in a bad mood when the bit blit comes in off the 2D pipe.” And you're like, “How do you know? Like, they don't have moods.” And he’s like, “If I tell you it's a mood, it's easier than spending a week with you explaining the histories to states on da da da da.” You’re like, “How do you know this?” “Just keep doing the same thing for 30 years.” \n\nBut, for him, it was a career, and it was a tool. And if you are a programmer, first and foremost, especially if you're in the tech economy where you're changing jobs every two years, you better be fluent in seven languages because that is your career. \n\nEDDY: So, Dave, let me ask you this then. If someone is saying, “Hey, I'm a senior developer,” what is a fair rule of thumb for that person as far as how much diverse they are in other languages and how fluent they are? Like, what would you think is a proper and fair expectation for someone who considers a senior? \n\nDAVE: I am going to give you an answer that's going to sound like a mystic senior kind of answer, which is no.\n\nWILL: [laughs]\n\nDAVE: When I interview somebody for a programming job, I don't want to know how many languages. It's good to know. If you tell me you know 17 languages, or you know seven languages and you know 3 of them really, really well, that gives me a one-sentence idea of the shape of your mind and your career. If you've gone 15 years and you've only learned one language, that tells me something about who you are.\n\nWhen I interview a senior developer, I don't care. I expect you to be fluent in some languages, but I don't need you to be fluent in Ruby. I don't even necessarily need...and if you're a junior, I don't even need you to be fluent as...I'm saying this badly. If you come work for me, I need to know if you can think; that's what I'm trying to say. I want to know if you can think. I cannot teach you to think. \n\nBut if you've been doing this job for 15 years and you've only learned one language and you don't have a really good reason for only learning one language, you've just told me how you think, which is kind of crusty and, you know, resistant to learning. And for my personality and the way I like to work, that's going to be a problem. For other people, that might be great, I don't know. So, I use language fluency and capacity and facility with language as a proxy for your ability to think and learn over time. \n\nWILL: You know, I don't think I've ever asked or particularly cared about someone's language background. I think it's never really come up for me, past, like, you know what I mean, like, if I have a specific job, I need to know that you could do, you know, that specific job with some facility. But, I mean, generally speaking, I'll talk. I'll ask about projects you've done and things you've done. And, honestly, if you have a sort of a diversity of like, oh, I worked on this for a while, and then they need some help over here, so I did that, and then, they need some over here, so I did that, and I just picked up this thing, then it's almost a natural kind of thing. \n\nAnd so, if you have kind of, like, a diversity of like, oh, I've worked in a couple of different jobs, a couple of different projects, a couple of different teams, you know, then you'll just get it. I mean, it'll just...you would have to be working pretty hard not to do it. Like, the only way I think you could really reasonably work on a good diversity of projects and not pick up just various languages would be if you were working maybe a long term, like, a long-term employee of a company that was fairly rigid in terms of, like, how they do things, you know. \n\nLike, I could see somebody being good, who's doing good work and taking on diversity of work and is, like, thinking, well, you know, but they just happen to be in this environment. Although I will not lie to you, like, it would factor into my evaluation in that I would need to make a judgment call as to whether this person could, you know, spread their wings and fly outside of this, you know, particular corporate ecosystem. \n\nDAVE: Yeah. And if somebody's had...if they've been in five different places over the last eight years and we ask them, you know, “So, tell me about this...” and you very quickly you start to...they all like, “Well, at this place, the team worked on this, and at this place...” and you start realizing it sounds like you were in the backseat there, and okay, so you're a backseat person who waits for things to happen around you.\n\nAnd then, you get other people that are just like, “Oh, I did here. Man, we did this, and we went over here, and we did this.” And even if they didn't sound like they were in the front seat, you can tell that they're leaning forward. They're like, I want to know what's coming down the pipe next, and I want to engage. That's a pretty interesting...we've been talking about learning, but we've now kind of diverted into, like, how do you measure somebody's personality? But you get a feel for this. And, honestly, I think your willingness to learn...I'm worried that this is going to –-\n\nWILL: [laughs]\n\nDAVE: Please, please don't let this turn into a political thing. I'm going to say this.\n\nWILL: Uh-oh.\n\nDAVE: I used to operate off of the old-school definitions of conservatives and liberals. Old school conservative is somebody who does not like progress because there are good things in the existing system. And they understand that if you change something, we might lose some of the good things.\n\nOld-school liberals are people who say there are flaws in the existing system, and if we don't change something, we'll never get to the even better things. So, that's the old school of this, whether you're averse to loss or whether you're averse to failure to grow, and they're both really valid, and they do well in this.\n\nAnd I think a lot of learning falls into that, right? The jump in, get thrown into the lake, you know, light a fire under your butt. That's a very kind of, I mean, lowercase l. These are not political terms. These are attitudinal terms, right? Lowercase l. Progressive-minded people are going to want to just jump in and flail and get to it.\n\nBut if you're programming pacemakers, we want somebody that's a little bit conservative-minded. If you're doing SecOps or, you know, other security stuff or stuff where failure can be catastrophic...I don't know if I've told this story here. I've told this story on Ruby Rogues a bunch of times. I once got a bug report that started with the sentence, “Fortunately, no one was killed, but... And that will stop the conversation in a room, right? \n\nWe had things that could shake big, heavy things. Toyota was using it to shake cars to try and rattle the welds to see where the resonances were to find out if the car was going to rattle apart on the road. And we had a bug, and we punched one of the thrusters maximum, from zero to maximum instantly. And we launched a Camry across their fab. And everyone wore their brown pants that day. Yeah, so when you send the frame of a car, it’s scary.\n\nEDDY: I will say that you got my attention immediately when you started your sentence [laughs] [inaudible 24:04].\n\nDAVE: Yeah, yeah, fortunately, no one was killed. \n\nEDDY: [laughs]\n\nDAVE: But, yeah, yeah, that's...right? So, if you're programming a pacemaker, that's an issue. My neighbor just bought a Tesla, and I am boggled by the fact that the cars that don't have the auto drive still have all of the servos and linkages and stuff like this, to, you know...And oh, it’s so that you can purchase this upgrade, you know, right from the dash of your car. And I'm like, yeah, but they put 20,000 worth of servos in the motors that if there was an SE Model that never was going to have auto drive, they could have saved half the price on manufacturing the vehicle. Why would you do that? And he said something that scared me. He says, “I'm not actually certain there's a linkage mechanically from the steering wheel to the steering column,” And I’m like --\n\nWILL: There isn’t.\n\nDAVE: What happens if the computer crashes on the road? Like, safety engineering is like, if you brick this car at 70 miles an hour, you have to be able to get stopped without dying. And I'm sure the smarter people than me have an answer for this that there's probably some way that the car will keep you from, you know, dying in a fireball, but you have to think of that. Pacemakers have the same problem.\n\nWILL: Listen, I don't want to take the podcast for a turn, but all I will say is Tesla has a different risk management envelope than the large automakers. And if you want to see the level of operational risk that they're comfortable with, you could type in “Autopilot fails” in YouTube.\n\nDAVE: [chuckles]\n\nWILL: And you're going to see some things that Toyota would not ship, and that is a decision that they make for themselves and also me, who is driving next to them with my children. \n\nDAVE: Yeah. And there's some issues with that, yeah. It's like when the Ford Pinto...just Google, “Ford Pinto class action lawsuit,” or whatever it was, $4 part. They had a memo. Somebody said, “We can save 10 million by not upgrading this part with a recall. We'll just pay out the class action suits because if they get rear-ended, they will burst into flames, and people will burn to death. But we'll just pay. We'll just settle them.” They figured it would be cheaper. And that's a poor...I would have rather had a conservative or a pessimist, there we go, optimist pessimist that's probably a better word than liberal conservative. \n\nSo, we get somebody who is risk-loss averse because there's times when you want that, right? Marty Seligman's book, “Authentic Happiness,” he talks about there's times when you want a pessimist because a pilot who is an optimist will try to take off when the wings might be still icy. A pessimist will stop. Your plane is going to be late. Everyone's going to be...it's going to cost all kinds of extra operational costs, but they won't crash and burn and kill everyone aboard. And that's kind of a feature that we actually kind of want. So, sometimes you want a pessimist in those places. If you're programming pacemakers, you want somebody who's like, okay, number one, we have to not kill you, and then anything we do has to build on that. We can't violate that constraint. \n\nEDDY: Gotcha. And that's how we learn, right, Dave [laughs]? \n\nDAVE: Well, okay, so, how does this apply to learning? The optimist learns by getting thrown in the lake, and, you know, as long as they're not tied up in a sack, then they're going to learn to swim. Music. Pick up a guitar and just start banging on it. Find the music that's within you. That's a fantastic, optimistic way to do it. \n\nI was, as a kid, trained by a conservative/pessimist who basically said, “That's not the way Bach wrote it, and you must [vocalization]. You must do it exactly.” And they sucked all the joy out of music. But anybody who's going to go to Carnegie Hall needs that teacher because somebody who learns optimistically they might be the most soulful blues player in the world, but they're never going to have the articulation and the perfectionism necessary for a specific type of performance recital. \n\nSo, how do you want to learn? Some people want that way to learn. Some people want to be taught, you know, sit down, do this, do this, do this, lead me by the nose, and don't do this. Don't do that. If you deviate from perfection, right? You want both, right? In the end, the way you learn to play music is to have 30,000 hours of just banging on the instrument, and you –-\n\nEDDY: Well, Dave, you kind of hit on music, and I think that's kind of interesting because I wanted to add to that and say, I'm the kind of person that learns but based on just grabbing a guitar, right? Strum a couple of things until something sounds all right, and I'm like, oh, that sounds pretty good. Let me see if I can replicate that, right? And I'll try it again, and I'll try to add to that. And I'm like, cool, I think this is awesome. I think this sounds great. You know, I have no basis on it, on why it sounds great. It just sounds good, right? But it's fun. It's fun to learn that way because you get to experiment, right? Get your hands dirty.\n\nI've also played with musicians where they learn by learning the craft, like, the roots, like, the internals of like, oh, I've got to know what notes are. I got to know how composition works because I have to dissect it before I even begin to touch it. And I'm like, God, that's so boring. Like, why are you doing all this research? Just play. That's, like, the fun. The harmony of it is just the experiment, not the research and development, right? \n\nWILL: That was the problem. That was the problem with me and Ruby, right? I struggled with Ruby for a couple of years because I had a mental block around not the functional parts of it, right? Because I came from ML, like, you know what I mean? This was no big deal. I could do functional programming, which is fine. \n\nThe problem was the loosey-goosey, funky syntax and all the magic pixie dust sprinkled throughout it because I came from C, you know what I mean? Where like, if you wanted to know how that sausage got made, it would tell you in excruciating detail every single thing. And ML, ML had a nasty type system, but your types were right, or you weren't doing nothing. You know, there was no ambiguity. \n\nThere was no like, ah, you know, it just kind of works. It's like, if it looks like a duck, quack, quack, baby, you know, like, uh-uh, none of that, none of that. Like, is it a duck? What kind of duck? What is the species? What is the gender? What's its age? These were all...and so, I struggled with that. Like, I needed to know how things were going. \n\nDAVE: I struggled coming into Ruby and Java from C++ because destructors fire the instant the object goes out of scope. Like, the way the compiler does it when that object is going to be...when we're done with it, the compiler executes the finalized code. And so, I had written a class called, you know, clogger that would say, “I've entered this scope, and I'm going to do this thing.” And its destructor would log the exit message.\n\nAnd I ported that to Ruby, and it didn't work. I had things that were exiting, and then nothing. And then, my program exited, and I got 15 out of my 20, and then 5 of them just never happened. And it's because finalize happens on garbage collection, not when the object exits scope. And, like, yeah, that sucked. \n\nWILL: Yeah, but your [inaudible 31:44] can happen anytime, you know what I mean? Like, your access after free, that can happen anytime, today, tomorrow, in a week, a year, like, oops, you're [inaudible 31:58]\n\nDAVE: Yeah. So, in C++, the destructor is something that the system does for you at a specific point in time that you can then leverage for your operational details. In Java and garbage-collected languages, the destructor happens for the resource. It's going to free that thing up so that somebody else can use it, or it's going to, you know, if you've got a handle that you have to dispose of correctly, it's for that resource. It's not for you. It's for you in that we don't let your hard drive fill up or that we don't let you run out of memory. But it's not for you. It's not synchronous, where in C++, it was very deterministic, yeah. \n\nWILL: Yeah, destructors, C++. Lots of fancy lies up there with your destructors. \n\nEDDY: I want to add to something just because I want to take advantage that we have Mike on this call; by the way, Mike joined us.\n\nDAVE: Yeah, Mike just joined the call. Welcome. \n\nEDDY: I kind of want to dive in a little bit. I want to circle back a little bit to music because Mike is a musician, right Mike? Like, you compose music, right? \n\nMIKE: Sure.\n\nEDDY: So, if someone were to ask you, “Hey, Mike, you're a musician. We need someone to write music for us. Here's an instrument that you have no knowledge or context about how to write.” How do you learn? Knowing that you do understand how composition works, right? Just not the instrument. Like, what is your take? \n\nMIKE: Well, as talking before about how you've been with musicians who want to understand structure and that [inaudible 33:26]. I think it goes the other way. You give a kid...you have a toolbox, you know, they get the hammer, and they'll hammer everything. They'll just be joyful hammering on everything. And there's nothing wrong with that, right? I mean, there's a lot you can do with a hammer. It's a useful tool.\n\nBut after a while, sometimes, you want something that is more nuanced, more specific, a special-purpose tool. Maybe you need a chisel, for example. It's hard to do with a hammer what you can do with a chisel. In fact, you need a hammer to use a chisel. You kind of need them both. It's a collaborative sort of thing.\n\nWILL: Hammer's all the way down. \n\nMIKE: Having more tools in your toolbox is really useful. And I think the people who pursue music longer when they discover the broader toolbox, I’m thinking about Dave saying, oh, yeah, it's just a hammer. That's not a box sounds like. And he plays guitar, like, hey, I can do this differently. But, man, having a bigger toolbox, whether that's being able to do more improvisation or being able to think, well, maybe a, you know, five, seven chords, is going to resolve really well down to my root, and that sounds really nice, you know, is really useful to know because it allows you to kind of visualize the structure, have some bigger, more...I say bigger, more specialized tools so you know what you might use in that spot. \n\nI would say that if I had to do something for a new instrument, and I've thought about this before, you know, what would I do with some random instrument? I would have to go and study what the range of that music is, or the instrument, right? What's possible. Because you probably still have a sense of what's...you certainly know what's possible with harmony, right? With how pitches are going to sound together. But you might not know what's possible to do with that instrument. \n\nSo, you're going to have to study and from a very technical perspective, you know, all the dull parts [laughs]. What is the range of this instrument? But you still have the joy of the music creating because you're like, well, I know how it sounds, that, I get, and I can put these two together. And you actually can, I think, get some pleasure out of discovering what this new tool can do.\n\nHey, I just gave you a new, I think, plumb bob. If anybody's ever used a plumb bob...I think it's my favorite name [laughs] of a useful tool. But, you know, you have this very specific tool that maybe most people haven't even heard of. And what does it do? What could I use this for? And you start envisioning, well, what could I do with this? And so, just the way of thinking about it changes. It's not that you're not still enjoying that process of creation, whether that be music or whatever it is, but you're thinking about it from a different part, you know, from a different area, coming at it from a different direction and, you know, working on the other side. \n\nWILL: So, I mean, like, I like the music analogy in terms of learning because it's a little bit decoupled from the day-to-day nuts and bolts of what we do. And so, if I was going to sit down and I was going to teach somebody an instrument, because, first, I've got kids, and I also am a musician, and I would love it if they were musicians, too. And I'm not going to, like, you know what I mean? Because they’re my kids, right? My oldest is just barely getting old enough, so whether it's a possibility for him. \n\nSo, what would I do? Number one, I would find something that he had some interest in, like a musical instrument that he gravitated to on some level, whether it's the flute, or the saxophone, or the drums, or the guitar, or the bass, whatever. Find something that he likes the sound of, like, he's drawn to on some way. Two, I would get one for him, right? I mean, which, you know, okay, it sounds obvious, but it can't be overstated, some platform with which he could practice on. Three, I would find them some instruction, some in-person instruction.\n\nI know, Eddy, you mentioned, like, you know, playing guitar and learning guitar and stuff like that. And, man, I’ll tell you, like, the biggest piece of advice that I give to beginning musicians, that is almost universally ignored in this day and age, it's like, it takes some lessons, man. It takes some lessons. You'll get so much better, so much faster. \n\nAnd then, the last one is I would put him in an ensemble, right? An ensemble so that they can play music in a group to get the fun, the joy of, like –- \n\nDAVE: Together, to jam.\n\nWILL: Hanging out and not just playing music yourself, playing music within the context of other people to get that joy. It's much like, hmm, I'm not going to make that dirty joke, but [chuckles] think about stuff that’s fun you can do by yourself and how much funner it could be --\n\nDAVE: With people, yes. \n\nWILL: And so, like, how do you analogize that to, you know, learning engineering, software development, stuff like that, you know? You could get all those things in together, and any sort of formalized method of training, be it a bootcamp or a bachelor's degree or, you know what I mean, anything, is going to incorporate all of that in, right? But it's a lot harder to do by yourself. \n\nEDDY: I'm actually kind of curious; if someone were to ask you like, they give you the directions, says, “Hey, I know you know how to play guitar, but I need you to learn to play bass.” And the response is, “I can make my guitar sound like a bass. I don't need to learn bass [laughs].” \n\nWILL: You can't, and that's only spoken. Only somebody who doesn't know what they're talking about would say that. \n\nEDDY: [laughs]\n\nDAVE: There's more [inaudible 39:18] to that, right? There’s -- \n\nEDDY: So, it’s like, we need to build this feature, and someone says, “Oh yeah, I'll do this in Ruby,” and you're like, “No, no, no, no, but Ruby isn't the equipped language to do this, what we need to do.” And he's like, “Oh, but I can make it do that. Like, I can make it bend the way it's not meant or designed to,” right? \n\nDAVE: There's a beautiful distinction between Turing completeness and the idea of a Turing tar-pit. A Turing tar-pit is where everything is possible, but everything is a pain, right? You can play bass on a guitar. The White Stripes, the big song, Seven Nation Army, everyone thinks it's on a...no, he's playing on the guitar, on the low E string with an octave drop pedal, right? Okay, yeah, you can do it. \n\nThere's two sides to this; one is, music comes from the musician, not from the instrument. So, if you take somebody who's an excellent bassist and you hand them a three-string guitar, they're going to be okay. It's not going to sound like a bass guitar. And if you tell them, “Sit in on this ensemble as the bassist,” and you hand them, you know, a soprano ukulele, it's not going to work. \n\nSo, there's the idea of, like, I can make anything fit here because that's who I am. And then, there's the converse idea, which is, can you make anything fit into this round hole? Not necessarily. Sometimes, you’re going to have to find the right thing. Mike was talking about the tools. And something I wrote on a blog years and years ago is always use the right tool for the job. I was standing there, hammering screws into a board with a wrench, and my dad came over and smacked me and said, “Use the right tool for the job. Use a hammer to pound screws into a board.” And it's like, wait, it's still the wrong tool, right? It's the right tool. \n\nWe keep talking about music, and I love that because the conservatory nerds are going to say, you know, it's like, there's only 12 notes and, you know, on a heptatonic scale, there's only 7. And you have to be perfectly inbound this. And then, you could talk to the jazz musicians, and they will tell you there are no wrong notes. You're just not confident enough. And I'm like, wait, but surely not everybody can think that way. \n\nAnd then, you go back, and you listen to country music, and you realize the twang of, you know, [vocalization], that [vocalization], that they're literally bending the string into a half sharp minor note, or a half flat, whatever it is. But they're literally bending the string to a note way halfway between. It is not on any out of key, out of tune, out of everything. And it's on purpose, and it sounds perfect because it belongs there. It's this ugly, sour note. And you need it to make the rest of the consonant notes sound great. \n\nWILL: Sure. Sure. I mean, like, non-western music uses a lot of microtones that are not...they're not even in the 12-note scale, you know, and, like, they're not accidental, and they don't sound bad either. I mean, it's just a different way of thinking about music. But I do want to pull it back to engineering. And what I would say is I talked about this sort of like, you know, this baseline, get an instrument. Get a teacher. Get an ensemble. And then, make sure you're making it fun. Make sure it's structured. Like, all that stuff that's great. And, like I said, like, anybody who's given any thought to teaching how to do a thing is going to have all of those aspects.\n\nYou're going to have a theory. You're going to have personal projects, and then you're going to have group projects, you know, have the whole thing. However, once you get thrown out into the industry, you get nothing. It's just like, “Hey, man, like, it'd be cool if this...hey, our Go servers crashed, and the guy quit, so you know Go now.” “I don't know, Go.” “Like, yeah, you do. Get to work,” you know? And that's the gig. \n\nOr, you know, even worse than that, you're scraping together hours in your free time where it's just like, yeah, man, I don't know if, like, I don't know if, what is it, .NET? I don't know if .NET programming is for me. Maybe I'd like to learn Ruby. And now you're sort of trying to claw together nights and weekends and stuff like that. And I think that is a substantial driver of burnout and sort of like, I don't know, it uses engineers up. And so, how do you engineer that stuff for yourself when there's nobody who's going to do it for you? But it doesn't become less, you know, less relevant to maintaining a career. \n\nDAVE: Yeah. There's a thing that...we keep bouncing off these contrasts between overprescription and under-leading insufficiently. Like, sometimes you pick up the guitar, and you're like...or you stand on the panel, and you don't know what to do. You can't jam in a group if you don't know the key that we're going to play in, right?\n\nAnd I wanted to circle back to this a little bit. One of the things that was super powerful to me early on my career was the discovery of a concept of mentoring, where a mentor is somebody who knows many, many, many, many, many things. They’ve forgotten seven ways to solve any problem that you're going to deal with, but they won't overprescribe. They will show you one way to do it, or they'll say...ah, my guitar teacher, I could not get this chord change, and he said, “Maybe try switching to this finger.” And all of a sudden, I could go from this chord to that chord, and I would just pivot. And it was easy and ergonomic. \n\nAnd finding a mentor can help you really accelerate both because the mentor can say, “I'm not going to tell you the 73 ways you can do this and force you to learn all 73 of them before I let you do any of them. I'm just going to give you one to try, and I'm going to debug...oh, you're struggling here because of this. And there's this problem that you don't know that, you know, do this and, all of a sudden, your program just works.” And the first few times, you don't know why, right? Because your mentor knows [inaudible 45:25]\n\nWILL: I wish we had time to get into the continuing education aspect of this thing. Because I think this is where, like, in my opinion, this is one of the great sins of the industry, in that, like, technology is moving so fast, all the time, so fast all the time. I do feel like it's slowing down a little bit, which is nice for me. But -- \n\nDAVE: Is it slowing down, or has the frenzied, fresh, cutting-edge moved away from where you're focusing? I'm running into that. There's as many forest fires to fight every single day. I just don't see them. And I walked into, like, the AI stuff, and I got to run so hard just to stay at the back of the pack. \n\nWILL: I'm not sure. I'm not sure. I'm not sure. I don't know. You know, I just don't know enough about AI to really know, like, what all is going on. Although, I mean, I will say that, like, it doesn't seem like, I don't know, who knows? That's a different, separate tangent. But -- \n\nDAVE: Yeah, the idea is the sigmoid pattern, right? Things that are on fire tend to taper off over time. Yeah, yeah. \n\nWILL: Well, exactly. So, the question, I don't know, I mean, the one thing that I wish we could have gotten into a little bit deeper is continuing education for engineers and how to keep things going, you know, because, like, it isn't...the problem with, you know, engineering education isn't so much that we don't know how to do it, you know, when we can be bothered to. \n\nThe issue we run into is, can we be bothered, you know, can we be troubled to keep these things going? And I think it's shockingly wasteful. We burn a lot of engineers, they're perfectly good engineers, just because we can't bother to be training them on the new stuff. And, I mean, if you compare that to other industries, other professions, other career development stuff, nobody does it like this. It's really crazy the way things are going. But it's still incumbent on us as practitioners, as craftsmen to keep that stuff going. And if your boss won't do it, if it isn't part of the industry, then you just have to work it out yourself. \n\nDAVE: Yeah, your knowledge portfolio [inaudible 47:45] career, and if your boss isn't investing in it, you're dying. You need to invest in it. \n\nWILL: Yeah. Yeah, precisely. I mean, you know, I mean, they'd be happy to get rid of all of us and replace us with new grads for half the money. \n\nDAVE: Yeah, until they find out that what they needed for that server fire last week was an engineer who has forgotten 19 different ways to solve that problem. All right. It's great to have a team full of people that can solve any problem first principles, but it's kind of a pain when your entire team has to solve everything from first principles. \n\nEDDY: I think basically just coming back and having a [inaudible 48:25] is basically is there's different ways to learn, and it just depends on the personality of the individual. And it's funny how we keep coming back to music, unironically, from other sessions. Like, there's a parallel between music and programming. It's great. \n\nDAVE: Music, linguistics, and programming has one of the most creepily off-the-charts, oddly specific overlaps. Get a musician, a linguist [inaudible 48:58], a programmer, just every time. Yep. \n\nWILL: Interesting. \n\nEDDY: Yeah, it's awesome. I'd like to see that study. It'd be great. \n\nWILL: All right, well. \n\nDAVE: It was just anecdotal, so... But so, now we've got our next...this is turning into the podcast where we tell people, let's do a part two of this, and then we never do the part two of this. Someday, we'll get around to part two, so...we hope. \n\nWILL: Well, thanks, y'all. \n\nDAVE: I think this has been a really good chat. Yeah, thanks for coming. Thanks for listening if you're at home. And if you're not at home, go home, and then, thanks for listening at home.","content_html":"In this episode of the Acima Developer Podcast, Dave Brady, along with panelists Eddy, Kyle, Ramses, and Will, discuss the various ways people learn, sharing personal anecdotes and insights. Dave kicks off with a humorous story about learning to swim by being thrown into a lake, which sparks a broader conversation about how some people thrive when thrown into challenging situations, while others prefer a more structured approach. Will identifies with the former, explaining how he learns by setting impossible goals and pushing himself to figure things out, often attributing his approach to an undiagnosed ADHD coping mechanism. Eddy contrasts this with his preference for having safety nets in place when learning, underscoring the diversity in learning styles.
\n\nThe discussion also touches on the importance of incremental learning, with Will emphasizing the strategy of "debugging from the known to the unknown." He shares advice from his engineer father, explaining how building knowledge step by step can help navigate new problems. They also dive into how experience in multiple programming languages helps make learning new ones easier, but caution against assuming that all programming languages follow the same rules or paradigms. The group explores how learning through experimentation, much like playing music, can lead to deeper understanding, yet each new tool or language requires its own dedicated study.
\n\nThe conversation wraps up with a reflection on the importance of continuing education for software developers. Will argues that the industry often neglects training, which leads to burnout and inefficiency, as engineers are left to constantly catch up on their own time. Dave adds that knowledge is crucial to a developer's career longevity, stressing the need for ongoing learning even if employers don't invest in it. The episode highlights the parallels between music, programming, and learning in general, emphasizing the importance of both structured and self-driven approaches.
\n\nTranscript:
\n\nDAVE: Hello and welcome to the Acima Developer Podcast. I'm your host, Dave Brady. Today, we've got Eddy, and Kyle, and Ramses, and Will. We've got a really great panel today. We're talking about learning. And Mike usually likes to start with a story, and I don't have a good...I've got too many stories about learning, and I don't want this to be the David Brady talks about his life story again show.
\n\nI’ll just start with one of the stories from my childhood, which is that a lot of times, I learned the hard way. My dad taught me to swim by throwing me in the lake. And the hard part wasn't learning how to dog paddle. The hard part was getting the knot untied from inside the sack.
\n\nWILL: [laughs]
\n\nDAVE: So --
\n\nEDDY: The joke is that you were destined to fail because you weren't given the proper...gotcha.
\n\nDAVE: Yeah. Except, a lot of times...for the people listening at home, about 30 seconds before we started this call, I told Eddy that he should host, and he said, “No, no, no, no.” And I was like; I'm this close to just making him do it because the best way somebody [inaudible 01:07] that they can swim is just throw him in the lake. And it feels like you're tied up in a sack because you don't feel like you're maximally competent. You are minimally competent. That's what beginning is. And so, yeah, all right, so we took the joke. We overexplained it, and then we turned it into a metaphor. Why not?
\n\nEDDY: I will say, David, it's funny because I've met some people in my life who learn best by being thrown in a bag and tied in a knot, and some of them prefer that. They like to just be tossed in the deep and figure it out, you know? I know that there's very little people in the world that learn that way, but I do know that there's a lot of people who actually excel being in a [inaudible 01:46].
\n\nDAVE: And, for those people, skydiving and working with cobras is probably not a good career.
\n\nEDDY: Will, I saw you raise your hand. Are you one of those people?
\n\nWILL: [laughs] It's me. Like, I am that person. Like, I have tried, like, so many times in my life, you know, so many times in my life, to be like, you don't have to do it that way, do you? Not that way. Not again. Again? But how I learn is I get myself in over my head. I assign myself crazy goals, impossible deadlines, crazy projects. I have no idea what I'm doing, and I don't know; I’ve figured it out. I pull it off [laughs].
\n\nEDDY: Is it because you want to tear things open? Like, if they assign you something and they're like, “Hey, Will, get this done,” you prefer to be proactive and undig and, you know, be...
\n\nWILL: I think it's, I mean, as I learn more about sort of mental health and, you know, work styles and stuff like that, I think it's just a...I think it's an undiagnosed ADHD coping mechanism that that's the root of it. But, man, I don't know, I mean, like, I think there's a certain level of, like, if I may pat myself on the back a little bit, the breadth of things that I've done pretty successfully over the course of my career is significant.
\n\nAnd I don't know a lot of people that have covered as much ground, and I don't know...it's hard to summon up the requisite psychic energy to really push yourself in a completely non-toxic fashion. Jet fuel is deadly poison, but it'll...you put a big enough pile of it under your butt and set the fuse, and you're going somewhere, you know [laughs]?
\n\nDAVE: There's a YouTube guitarist named Rhett Shull, and his slogan is, there is no plan B. Like, he will actively destroy plan B. If he wants Plan A to work, he cannot have a Plan B in his pocket, or he'll fall back on it every time. And so, that's literally his channel slogan is, remember, there is no Plan B.
\n\nEDDY: I will say I learn way different than you, Will. Like, if you throw me in the deep end and I don't know how to swim, I expect to have a lifesaver somewhere, like a jacket, or floaties, or whatever. It's like, cool, yeah, like, I'll put you in there, but you at least have a safe haven where you can fall back on in case you can't figure out how to swim. That's my personality. However, if you don't give me floaties and you don't give me a life jacket or a vest or anything, I can at least learn how to float [laughs], you know, stay afloat, you know, like, I won't drown entirely. It's just not the ideal spot you want to be in.
\n\nWILL: I mean, it's not like I won't ask for help. It's not like I won't ask for clarification or anything like that. I just, I don't know; I mean, that's just how I do it. I need a certain amount of fire under my butt to do my best work.
\n\nEDDY: That brings up a really interesting point, though. Like, what are some of those techniques that you do then? If you get put in that situation to learn, what are some of the things that you gravitate to that sort of help you?
\n\nWILL: When I'm in it? Yeah, it's one of the best pieces of advice I ever got was from my dad, a capital E engineer, and he always said, “Debug from the known to the unknown,” right? And so, what you always want to do is you want to sort of expand what you're doing, expand your knowledge from a functional state, from a working state, and it doesn't matter how petty, and trivial, and stupid. So, if I was like, let's say I'm going to do a brand-new thing, right? I'm going to write a thing in a brand-new language, right?
\n\nLike, I've said this on this podcast multiple times, and you haven't heard the last of it after I get this one out, is start as small as you need to get a functional kernel, a nucleus of something that you can do and then expand from there, which is the easy thing to say, but it's a hard thing to do because the space of a new problem, a new technique, a new territory is big. You don't even know where the edge of the map is. You don't know where you are.
\n\nAnd so, you need to collapse down to something functional and then sort of build out from there. And that's, you know, that's the best way that I know to do it. And when you approach it like that, I mean, it really can be a very simple mechanical kind of a thing.
\n\nEDDY: I like that.
\n\nWILL: I was actually listening to a podcast. It’s the Andrew Huberman Podcast. He was talking about, like, literally, like, a process of learning, right? If I could paraphrase, like, a podcast that I only finished half of, the learning technique, the science that he was sort of describing was saying...he’s like, the key to learning is not so much learning; it's preventing the natural process of forgetting. Your brain is ---
\n\nDAVE: Neural pruning.
\n\nWILL: Well, your brain's taking in information all the time, right? You're constantly bombarded, flooded with data, and most of it gets thrown out because it's not useful. Your brain is actually really efficient at flushing that cache out. And so, what you want to do is try as hard as you can to establish it, and you build those hooks, tie it in with other things that you already know.
\n\nLike, I've gotten really good at picking up languages because I've picked up a lot of languages. And it's just like, you know, somebody who learns seven languages, the eighth one will be easy. Well, if you know seven programming languages, then the eighth one isn't going to be so bad. And so, we're getting new techniques. We’re sort of attaching techniques onto things that you already know how to do.
\n\nIf you wanted to write...let's say you didn't know Java, but you knew Ruby pretty well, running a web server in Java, you would have a theoretical construct, a matrix to think about things. It's like, oh, well, I know about, you know, routes in Rails. You know, does my Apache Server have routes the same way? It sure does. Or, I mean, Apache is not the right one, but anyway, I forget, Spring Boot server. And so, you can connect things. So, it's like, oh, Ruby has an array. Java's got an array. It's got a vector, right?
\n\nSo, I mean, like, okay, so we've got this and this. Do we both have a hash? Okay, we both have hashes, right? So, we have maps going back and forth each way. And then, hey, you're actually going, right? Like, the wheels are turning. Things are moving for you. And there's not that many new ideas under the sun. You know, like, once you've gotten your hands deep into something, picking up the next thing's not so bad, you know?
\n\nDAVE: You sparked a turning thing to what you just said, which is really interesting. I ran into an interesting thing where I started in Visual Basic, and then I moved into C++, and then into C, and then Assembly. I moved backwards, like, down the tech tree, down to where I was like...literally to the point where I was soldering transistors on a board, and then came back up to a high level and very high-level languages. And as I was coming...like, I got a job moving from PHP into Java, and I'd done C++ and da da da da. And I was just like, just tell me where the braces and semicolons go. All languages are the same.
\n\nAnd I was talking with a grizzled, old hacker, and he said, “Go learn Lisp.” And I'm like, okay, whatever. And I really struggled with it, and I couldn't figure out why. And, honestly, I bounced. I went and looked at Scheme, and I went, okay, yeah, this is like really, really tight versions of, you know, semicolons and whatnot, but okay, fine.
\n\nIt wasn't until I tried to learn Elixir, which is Ruby on the Erlang BEAM, right? On the Erlang virtual machine, and I struggled and struggled and struggled. And this language just kicked my butt, like, nothing would work. And, finally, somebody sat down and said, “You're thinking bols,” B-O-L-S, block-oriented, lexically scoped languages. C++, Java, Python, Perl, PHP, all of these are block-oriented lexically scoped languages, and Lisp isn't, Closure, Scheme aren't. I mean, those are all Lisps. Erlang and Elixir aren't, Smalltalk as well. They live in completely different paradigms, and block-oriented lexically scoped does not translate.
\n\nSo, when people say, “What language should I learn?” I'll tell 'em, “You know, go learn...” You know, actually, JavaScript is the perfect example of this because JavaScript is not a block-oriented lexically scoped languages. It looks like people look at it, and they think, oh, this is Java, or this is, you know, C++. It’s not. It’s not even an object-oriented language. It's a prototype-based language, and it will behave like an OO language for, like, 98%. And then, you get this weird bug. Where the heck is this coming from? Well, it's because there's not actually any inheritance in this language. You're just layering a prototype. And there's a key point where the language goes into [inaudible 10:51].
\n\nSo, knowing...I 100% agree that seven languages makes the 8th language easy, but you have to be careful when you step into that 8th language to go, is this going to be easy because I know 95% of it, or is this going to be easy because there are some huge differences in [inaudible 11:10]? And follow them very, very carefully. With Smalltalk, it's like, send a message to an object. You don't, you know, don't try to...it's rigidly OO. And if you try to write imperatively like you can in C, it will kick your butt. And it's fantastic [crosstalk 11:23]
\n\nEDDY: I will [inaudible 11:23], Dave, because you mentioned something that I think is actually kind of interesting. You said that there was a hindrance because you already had prior knowledge to a language or different languages, and it was a whole different dichotomy. So, do you think that had you gone in without any prior knowledge to any language and had to learn, would it have been easier for you to pick up? Because then you weren't translating any bad habits that didn’t --
\n\nDAVE: Let me qualify the term easy because I bounced off of Lisp so hard. I would categorize my first two years of Lisp as failing completely, utterly completely, because I was trying to make the language act like Perl, Ruby, Python, Java, C++. And because I refused to see the languages behaving differently than...I mean, I’d come from Assembly language. Everything was ones and zeros. So, obviously, I know how it's going to act at the high level, right? I didn't. I had no concept of this. And it's because I refused...and this will be a thing that we'll probably touch on a lot, but the map is not the terrain.
\n\nSometimes, there's a difference between the map and the terrain. And you can watch people get locked up when the map and the terrain don't match, and they will hammer that terrain until it matches the fricking map. Or they will just circle that part of the map and say, “Here be dragons; don't go there.” And, no, just update the map. That's all you need to do.
\n\nAnd so, random 10-second one-sentence thing. The best parenting advice I ever heard was, take the time to get to know your kid because your kid is a different person than you are. And the idea of treating a child...like, I grew up in a generation where children were meant to be seen and not heard. Children were meant to be input only. You're not a transmit. We don't want to hear anything out of you. Taking the time to actually interact with another human being validates them and turns them into a very different person than...right?
\n\nI realize that's a really weird analogy, but it's the same architectural pattern. Listening to something that you think you can just transmit nonstop, to learning that you can listen to that is a huge power-up. Sometimes, pay attention to the terrain rather than the map. Did that make sense? Did any of that make sense?
\n\nEDDY: [laughs] I like the analogy where you said all your kids are different, right? And you can't treat them the same. And then, you can probably force them to act a way, but then it's not going to be as fluid. It's not as natural because that's not the way the kid is designed.
\n\nWILL: Well, let me ask you this, though, because I think you'll probably agree with me, but we'll see. I still think you would pick it up faster, even, like, having some sort of, like, you know, a little bit of blocks, right? Like, mental blocks around stuff.
\n\nDAVE: Yes. Oh, 100%.
\n\nWILL: I still think you got there faster than if you started from zero.
\n\nDAVE: Yes. Oh, yeah, yeah, because once I figured out that I was bouncing off this language, once I realized, oh, it's the map, and the terrain don't match, I was able to go, oh, and then, all of a sudden, that 95% match was able to apply again. And, yeah, and then other things, like, one of the best things I heard in the twenty-teens was, if you want to be really good at Ruby, go learn Lisp because it will make you a better Ruby programmer. And I've meditated on that a lot, right? It's like, why would you learn this archaic language that nobody uses? Because it'll make you a better programmer.
\n\nBecause there are things that you will learn that we don't ever use over here, unless you've come from Lisp, if that makes any sense at all. It's kind of like taking a data structures class, you know, or an algorithms class. The first time you learn about Big O Notation, and, all of a sudden, you realize why that database query is taking so long. You don't cover databases in the Big O Notation class, right? You usually are covering algorithms and processing time. And then, all of a sudden, everything around you, like, people lining up at the DMV, you realize this is a Big O Notation problem. And being able to apply the structures to it, yeah, hugely, hugely beneficial.
\n\nEDDY: Dave, actually, the reason to my previous question was because I wanted to lead to eventually that final hypothesis, where it's like, yeah, even though a language that you are avid in is completely different on the way it behaves than a new language, you have still trained your brain, you know, to be proactive and resourceful and think like a programmer, to think like a computer, right? And that sort of thing is kind of hard to learn if it's your first time, right?
\n\nWILL: I have a only mildly unfair amount of skepticism around programmers that really only know one language well, you know? Like, if you're like, “I'm a Java guy.” I'm like, “Well, do you know, like, Ruby or Python?” “Nah, nah.” “Do you know JavaScript?” “Nah.” “Lisp?” “Nah. Nah, I just do Java or Kotlin, you know, both of them.” And I’m just like, you know, you're not necessarily dumb, but, you know, it's like you open up a toolbox, and it's just hammers, you know what I mean?
\n\nDAVE: Yeah. There's two types of seniors that I've seen to do that. First of all, a junior who only knows one language, I'm kind of okay with that, right?
\n\nWILL: Yeah, it’s fine.
\n\nDAVE: And if you've spent five years without learning another language, that's when I'm going to tap you on the shoulder and say, “You need to go learn another language. You need to get out. You're starting to rut in, right?
\n\nBut I've seen a programmer with 30 years under his belt who was just C, not even C++, just C. And he was really, really, really good at programming firmware. Like, this man knew his hardware inside and out. So, he was basically using this language to do his career. His career was not programming, if that makes sense.
\n\nThis guy, man, he knew graphics cards, and he knew things about like, “Oh, yeah, the 3D chip is probably going to be in a bad mood when the bit blit comes in off the 2D pipe.” And you're like, “How do you know? Like, they don't have moods.” And he’s like, “If I tell you it's a mood, it's easier than spending a week with you explaining the histories to states on da da da da.” You’re like, “How do you know this?” “Just keep doing the same thing for 30 years.”
\n\nBut, for him, it was a career, and it was a tool. And if you are a programmer, first and foremost, especially if you're in the tech economy where you're changing jobs every two years, you better be fluent in seven languages because that is your career.
\n\nEDDY: So, Dave, let me ask you this then. If someone is saying, “Hey, I'm a senior developer,” what is a fair rule of thumb for that person as far as how much diverse they are in other languages and how fluent they are? Like, what would you think is a proper and fair expectation for someone who considers a senior?
\n\nDAVE: I am going to give you an answer that's going to sound like a mystic senior kind of answer, which is no.
\n\nWILL: [laughs]
\n\nDAVE: When I interview somebody for a programming job, I don't want to know how many languages. It's good to know. If you tell me you know 17 languages, or you know seven languages and you know 3 of them really, really well, that gives me a one-sentence idea of the shape of your mind and your career. If you've gone 15 years and you've only learned one language, that tells me something about who you are.
\n\nWhen I interview a senior developer, I don't care. I expect you to be fluent in some languages, but I don't need you to be fluent in Ruby. I don't even necessarily need...and if you're a junior, I don't even need you to be fluent as...I'm saying this badly. If you come work for me, I need to know if you can think; that's what I'm trying to say. I want to know if you can think. I cannot teach you to think.
\n\nBut if you've been doing this job for 15 years and you've only learned one language and you don't have a really good reason for only learning one language, you've just told me how you think, which is kind of crusty and, you know, resistant to learning. And for my personality and the way I like to work, that's going to be a problem. For other people, that might be great, I don't know. So, I use language fluency and capacity and facility with language as a proxy for your ability to think and learn over time.
\n\nWILL: You know, I don't think I've ever asked or particularly cared about someone's language background. I think it's never really come up for me, past, like, you know what I mean, like, if I have a specific job, I need to know that you could do, you know, that specific job with some facility. But, I mean, generally speaking, I'll talk. I'll ask about projects you've done and things you've done. And, honestly, if you have a sort of a diversity of like, oh, I worked on this for a while, and then they need some help over here, so I did that, and then, they need some over here, so I did that, and I just picked up this thing, then it's almost a natural kind of thing.
\n\nAnd so, if you have kind of, like, a diversity of like, oh, I've worked in a couple of different jobs, a couple of different projects, a couple of different teams, you know, then you'll just get it. I mean, it'll just...you would have to be working pretty hard not to do it. Like, the only way I think you could really reasonably work on a good diversity of projects and not pick up just various languages would be if you were working maybe a long term, like, a long-term employee of a company that was fairly rigid in terms of, like, how they do things, you know.
\n\nLike, I could see somebody being good, who's doing good work and taking on diversity of work and is, like, thinking, well, you know, but they just happen to be in this environment. Although I will not lie to you, like, it would factor into my evaluation in that I would need to make a judgment call as to whether this person could, you know, spread their wings and fly outside of this, you know, particular corporate ecosystem.
\n\nDAVE: Yeah. And if somebody's had...if they've been in five different places over the last eight years and we ask them, you know, “So, tell me about this...” and you very quickly you start to...they all like, “Well, at this place, the team worked on this, and at this place...” and you start realizing it sounds like you were in the backseat there, and okay, so you're a backseat person who waits for things to happen around you.
\n\nAnd then, you get other people that are just like, “Oh, I did here. Man, we did this, and we went over here, and we did this.” And even if they didn't sound like they were in the front seat, you can tell that they're leaning forward. They're like, I want to know what's coming down the pipe next, and I want to engage. That's a pretty interesting...we've been talking about learning, but we've now kind of diverted into, like, how do you measure somebody's personality? But you get a feel for this. And, honestly, I think your willingness to learn...I'm worried that this is going to –-
\n\nWILL: [laughs]
\n\nDAVE: Please, please don't let this turn into a political thing. I'm going to say this.
\n\nWILL: Uh-oh.
\n\nDAVE: I used to operate off of the old-school definitions of conservatives and liberals. Old school conservative is somebody who does not like progress because there are good things in the existing system. And they understand that if you change something, we might lose some of the good things.
\n\nOld-school liberals are people who say there are flaws in the existing system, and if we don't change something, we'll never get to the even better things. So, that's the old school of this, whether you're averse to loss or whether you're averse to failure to grow, and they're both really valid, and they do well in this.
\n\nAnd I think a lot of learning falls into that, right? The jump in, get thrown into the lake, you know, light a fire under your butt. That's a very kind of, I mean, lowercase l. These are not political terms. These are attitudinal terms, right? Lowercase l. Progressive-minded people are going to want to just jump in and flail and get to it.
\n\nBut if you're programming pacemakers, we want somebody that's a little bit conservative-minded. If you're doing SecOps or, you know, other security stuff or stuff where failure can be catastrophic...I don't know if I've told this story here. I've told this story on Ruby Rogues a bunch of times. I once got a bug report that started with the sentence, “Fortunately, no one was killed, but... And that will stop the conversation in a room, right?
\n\nWe had things that could shake big, heavy things. Toyota was using it to shake cars to try and rattle the welds to see where the resonances were to find out if the car was going to rattle apart on the road. And we had a bug, and we punched one of the thrusters maximum, from zero to maximum instantly. And we launched a Camry across their fab. And everyone wore their brown pants that day. Yeah, so when you send the frame of a car, it’s scary.
\n\nEDDY: I will say that you got my attention immediately when you started your sentence [laughs] [inaudible 24:04].
\n\nDAVE: Yeah, yeah, fortunately, no one was killed.
\n\nEDDY: [laughs]
\n\nDAVE: But, yeah, yeah, that's...right? So, if you're programming a pacemaker, that's an issue. My neighbor just bought a Tesla, and I am boggled by the fact that the cars that don't have the auto drive still have all of the servos and linkages and stuff like this, to, you know...And oh, it’s so that you can purchase this upgrade, you know, right from the dash of your car. And I'm like, yeah, but they put 20,000 worth of servos in the motors that if there was an SE Model that never was going to have auto drive, they could have saved half the price on manufacturing the vehicle. Why would you do that? And he said something that scared me. He says, “I'm not actually certain there's a linkage mechanically from the steering wheel to the steering column,” And I’m like --
\n\nWILL: There isn’t.
\n\nDAVE: What happens if the computer crashes on the road? Like, safety engineering is like, if you brick this car at 70 miles an hour, you have to be able to get stopped without dying. And I'm sure the smarter people than me have an answer for this that there's probably some way that the car will keep you from, you know, dying in a fireball, but you have to think of that. Pacemakers have the same problem.
\n\nWILL: Listen, I don't want to take the podcast for a turn, but all I will say is Tesla has a different risk management envelope than the large automakers. And if you want to see the level of operational risk that they're comfortable with, you could type in “Autopilot fails” in YouTube.
\n\nDAVE: [chuckles]
\n\nWILL: And you're going to see some things that Toyota would not ship, and that is a decision that they make for themselves and also me, who is driving next to them with my children.
\n\nDAVE: Yeah. And there's some issues with that, yeah. It's like when the Ford Pinto...just Google, “Ford Pinto class action lawsuit,” or whatever it was, $4 part. They had a memo. Somebody said, “We can save 10 million by not upgrading this part with a recall. We'll just pay out the class action suits because if they get rear-ended, they will burst into flames, and people will burn to death. But we'll just pay. We'll just settle them.” They figured it would be cheaper. And that's a poor...I would have rather had a conservative or a pessimist, there we go, optimist pessimist that's probably a better word than liberal conservative.
\n\nSo, we get somebody who is risk-loss averse because there's times when you want that, right? Marty Seligman's book, “Authentic Happiness,” he talks about there's times when you want a pessimist because a pilot who is an optimist will try to take off when the wings might be still icy. A pessimist will stop. Your plane is going to be late. Everyone's going to be...it's going to cost all kinds of extra operational costs, but they won't crash and burn and kill everyone aboard. And that's kind of a feature that we actually kind of want. So, sometimes you want a pessimist in those places. If you're programming pacemakers, you want somebody who's like, okay, number one, we have to not kill you, and then anything we do has to build on that. We can't violate that constraint.
\n\nEDDY: Gotcha. And that's how we learn, right, Dave [laughs]?
\n\nDAVE: Well, okay, so, how does this apply to learning? The optimist learns by getting thrown in the lake, and, you know, as long as they're not tied up in a sack, then they're going to learn to swim. Music. Pick up a guitar and just start banging on it. Find the music that's within you. That's a fantastic, optimistic way to do it.
\n\nI was, as a kid, trained by a conservative/pessimist who basically said, “That's not the way Bach wrote it, and you must [vocalization]. You must do it exactly.” And they sucked all the joy out of music. But anybody who's going to go to Carnegie Hall needs that teacher because somebody who learns optimistically they might be the most soulful blues player in the world, but they're never going to have the articulation and the perfectionism necessary for a specific type of performance recital.
\n\nSo, how do you want to learn? Some people want that way to learn. Some people want to be taught, you know, sit down, do this, do this, do this, lead me by the nose, and don't do this. Don't do that. If you deviate from perfection, right? You want both, right? In the end, the way you learn to play music is to have 30,000 hours of just banging on the instrument, and you –-
\n\nEDDY: Well, Dave, you kind of hit on music, and I think that's kind of interesting because I wanted to add to that and say, I'm the kind of person that learns but based on just grabbing a guitar, right? Strum a couple of things until something sounds all right, and I'm like, oh, that sounds pretty good. Let me see if I can replicate that, right? And I'll try it again, and I'll try to add to that. And I'm like, cool, I think this is awesome. I think this sounds great. You know, I have no basis on it, on why it sounds great. It just sounds good, right? But it's fun. It's fun to learn that way because you get to experiment, right? Get your hands dirty.
\n\nI've also played with musicians where they learn by learning the craft, like, the roots, like, the internals of like, oh, I've got to know what notes are. I got to know how composition works because I have to dissect it before I even begin to touch it. And I'm like, God, that's so boring. Like, why are you doing all this research? Just play. That's, like, the fun. The harmony of it is just the experiment, not the research and development, right?
\n\nWILL: That was the problem. That was the problem with me and Ruby, right? I struggled with Ruby for a couple of years because I had a mental block around not the functional parts of it, right? Because I came from ML, like, you know what I mean? This was no big deal. I could do functional programming, which is fine.
\n\nThe problem was the loosey-goosey, funky syntax and all the magic pixie dust sprinkled throughout it because I came from C, you know what I mean? Where like, if you wanted to know how that sausage got made, it would tell you in excruciating detail every single thing. And ML, ML had a nasty type system, but your types were right, or you weren't doing nothing. You know, there was no ambiguity.
\n\nThere was no like, ah, you know, it just kind of works. It's like, if it looks like a duck, quack, quack, baby, you know, like, uh-uh, none of that, none of that. Like, is it a duck? What kind of duck? What is the species? What is the gender? What's its age? These were all...and so, I struggled with that. Like, I needed to know how things were going.
\n\nDAVE: I struggled coming into Ruby and Java from C++ because destructors fire the instant the object goes out of scope. Like, the way the compiler does it when that object is going to be...when we're done with it, the compiler executes the finalized code. And so, I had written a class called, you know, clogger that would say, “I've entered this scope, and I'm going to do this thing.” And its destructor would log the exit message.
\n\nAnd I ported that to Ruby, and it didn't work. I had things that were exiting, and then nothing. And then, my program exited, and I got 15 out of my 20, and then 5 of them just never happened. And it's because finalize happens on garbage collection, not when the object exits scope. And, like, yeah, that sucked.
\n\nWILL: Yeah, but your [inaudible 31:44] can happen anytime, you know what I mean? Like, your access after free, that can happen anytime, today, tomorrow, in a week, a year, like, oops, you're [inaudible 31:58]
\n\nDAVE: Yeah. So, in C++, the destructor is something that the system does for you at a specific point in time that you can then leverage for your operational details. In Java and garbage-collected languages, the destructor happens for the resource. It's going to free that thing up so that somebody else can use it, or it's going to, you know, if you've got a handle that you have to dispose of correctly, it's for that resource. It's not for you. It's for you in that we don't let your hard drive fill up or that we don't let you run out of memory. But it's not for you. It's not synchronous, where in C++, it was very deterministic, yeah.
\n\nWILL: Yeah, destructors, C++. Lots of fancy lies up there with your destructors.
\n\nEDDY: I want to add to something just because I want to take advantage that we have Mike on this call; by the way, Mike joined us.
\n\nDAVE: Yeah, Mike just joined the call. Welcome.
\n\nEDDY: I kind of want to dive in a little bit. I want to circle back a little bit to music because Mike is a musician, right Mike? Like, you compose music, right?
\n\nMIKE: Sure.
\n\nEDDY: So, if someone were to ask you, “Hey, Mike, you're a musician. We need someone to write music for us. Here's an instrument that you have no knowledge or context about how to write.” How do you learn? Knowing that you do understand how composition works, right? Just not the instrument. Like, what is your take?
\n\nMIKE: Well, as talking before about how you've been with musicians who want to understand structure and that [inaudible 33:26]. I think it goes the other way. You give a kid...you have a toolbox, you know, they get the hammer, and they'll hammer everything. They'll just be joyful hammering on everything. And there's nothing wrong with that, right? I mean, there's a lot you can do with a hammer. It's a useful tool.
\n\nBut after a while, sometimes, you want something that is more nuanced, more specific, a special-purpose tool. Maybe you need a chisel, for example. It's hard to do with a hammer what you can do with a chisel. In fact, you need a hammer to use a chisel. You kind of need them both. It's a collaborative sort of thing.
\n\nWILL: Hammer's all the way down.
\n\nMIKE: Having more tools in your toolbox is really useful. And I think the people who pursue music longer when they discover the broader toolbox, I’m thinking about Dave saying, oh, yeah, it's just a hammer. That's not a box sounds like. And he plays guitar, like, hey, I can do this differently. But, man, having a bigger toolbox, whether that's being able to do more improvisation or being able to think, well, maybe a, you know, five, seven chords, is going to resolve really well down to my root, and that sounds really nice, you know, is really useful to know because it allows you to kind of visualize the structure, have some bigger, more...I say bigger, more specialized tools so you know what you might use in that spot.
\n\nI would say that if I had to do something for a new instrument, and I've thought about this before, you know, what would I do with some random instrument? I would have to go and study what the range of that music is, or the instrument, right? What's possible. Because you probably still have a sense of what's...you certainly know what's possible with harmony, right? With how pitches are going to sound together. But you might not know what's possible to do with that instrument.
\n\nSo, you're going to have to study and from a very technical perspective, you know, all the dull parts [laughs]. What is the range of this instrument? But you still have the joy of the music creating because you're like, well, I know how it sounds, that, I get, and I can put these two together. And you actually can, I think, get some pleasure out of discovering what this new tool can do.
\n\nHey, I just gave you a new, I think, plumb bob. If anybody's ever used a plumb bob...I think it's my favorite name [laughs] of a useful tool. But, you know, you have this very specific tool that maybe most people haven't even heard of. And what does it do? What could I use this for? And you start envisioning, well, what could I do with this? And so, just the way of thinking about it changes. It's not that you're not still enjoying that process of creation, whether that be music or whatever it is, but you're thinking about it from a different part, you know, from a different area, coming at it from a different direction and, you know, working on the other side.
\n\nWILL: So, I mean, like, I like the music analogy in terms of learning because it's a little bit decoupled from the day-to-day nuts and bolts of what we do. And so, if I was going to sit down and I was going to teach somebody an instrument, because, first, I've got kids, and I also am a musician, and I would love it if they were musicians, too. And I'm not going to, like, you know what I mean? Because they’re my kids, right? My oldest is just barely getting old enough, so whether it's a possibility for him.
\n\nSo, what would I do? Number one, I would find something that he had some interest in, like a musical instrument that he gravitated to on some level, whether it's the flute, or the saxophone, or the drums, or the guitar, or the bass, whatever. Find something that he likes the sound of, like, he's drawn to on some way. Two, I would get one for him, right? I mean, which, you know, okay, it sounds obvious, but it can't be overstated, some platform with which he could practice on. Three, I would find them some instruction, some in-person instruction.
\n\nI know, Eddy, you mentioned, like, you know, playing guitar and learning guitar and stuff like that. And, man, I’ll tell you, like, the biggest piece of advice that I give to beginning musicians, that is almost universally ignored in this day and age, it's like, it takes some lessons, man. It takes some lessons. You'll get so much better, so much faster.
\n\nAnd then, the last one is I would put him in an ensemble, right? An ensemble so that they can play music in a group to get the fun, the joy of, like –-
\n\nDAVE: Together, to jam.
\n\nWILL: Hanging out and not just playing music yourself, playing music within the context of other people to get that joy. It's much like, hmm, I'm not going to make that dirty joke, but [chuckles] think about stuff that’s fun you can do by yourself and how much funner it could be --
\n\nDAVE: With people, yes.
\n\nWILL: And so, like, how do you analogize that to, you know, learning engineering, software development, stuff like that, you know? You could get all those things in together, and any sort of formalized method of training, be it a bootcamp or a bachelor's degree or, you know what I mean, anything, is going to incorporate all of that in, right? But it's a lot harder to do by yourself.
\n\nEDDY: I'm actually kind of curious; if someone were to ask you like, they give you the directions, says, “Hey, I know you know how to play guitar, but I need you to learn to play bass.” And the response is, “I can make my guitar sound like a bass. I don't need to learn bass [laughs].”
\n\nWILL: You can't, and that's only spoken. Only somebody who doesn't know what they're talking about would say that.
\n\nEDDY: [laughs]
\n\nDAVE: There's more [inaudible 39:18] to that, right? There’s --
\n\nEDDY: So, it’s like, we need to build this feature, and someone says, “Oh yeah, I'll do this in Ruby,” and you're like, “No, no, no, no, but Ruby isn't the equipped language to do this, what we need to do.” And he's like, “Oh, but I can make it do that. Like, I can make it bend the way it's not meant or designed to,” right?
\n\nDAVE: There's a beautiful distinction between Turing completeness and the idea of a Turing tar-pit. A Turing tar-pit is where everything is possible, but everything is a pain, right? You can play bass on a guitar. The White Stripes, the big song, Seven Nation Army, everyone thinks it's on a...no, he's playing on the guitar, on the low E string with an octave drop pedal, right? Okay, yeah, you can do it.
\n\nThere's two sides to this; one is, music comes from the musician, not from the instrument. So, if you take somebody who's an excellent bassist and you hand them a three-string guitar, they're going to be okay. It's not going to sound like a bass guitar. And if you tell them, “Sit in on this ensemble as the bassist,” and you hand them, you know, a soprano ukulele, it's not going to work.
\n\nSo, there's the idea of, like, I can make anything fit here because that's who I am. And then, there's the converse idea, which is, can you make anything fit into this round hole? Not necessarily. Sometimes, you’re going to have to find the right thing. Mike was talking about the tools. And something I wrote on a blog years and years ago is always use the right tool for the job. I was standing there, hammering screws into a board with a wrench, and my dad came over and smacked me and said, “Use the right tool for the job. Use a hammer to pound screws into a board.” And it's like, wait, it's still the wrong tool, right? It's the right tool.
\n\nWe keep talking about music, and I love that because the conservatory nerds are going to say, you know, it's like, there's only 12 notes and, you know, on a heptatonic scale, there's only 7. And you have to be perfectly inbound this. And then, you could talk to the jazz musicians, and they will tell you there are no wrong notes. You're just not confident enough. And I'm like, wait, but surely not everybody can think that way.
\n\nAnd then, you go back, and you listen to country music, and you realize the twang of, you know, [vocalization], that [vocalization], that they're literally bending the string into a half sharp minor note, or a half flat, whatever it is. But they're literally bending the string to a note way halfway between. It is not on any out of key, out of tune, out of everything. And it's on purpose, and it sounds perfect because it belongs there. It's this ugly, sour note. And you need it to make the rest of the consonant notes sound great.
\n\nWILL: Sure. Sure. I mean, like, non-western music uses a lot of microtones that are not...they're not even in the 12-note scale, you know, and, like, they're not accidental, and they don't sound bad either. I mean, it's just a different way of thinking about music. But I do want to pull it back to engineering. And what I would say is I talked about this sort of like, you know, this baseline, get an instrument. Get a teacher. Get an ensemble. And then, make sure you're making it fun. Make sure it's structured. Like, all that stuff that's great. And, like I said, like, anybody who's given any thought to teaching how to do a thing is going to have all of those aspects.
\n\nYou're going to have a theory. You're going to have personal projects, and then you're going to have group projects, you know, have the whole thing. However, once you get thrown out into the industry, you get nothing. It's just like, “Hey, man, like, it'd be cool if this...hey, our Go servers crashed, and the guy quit, so you know Go now.” “I don't know, Go.” “Like, yeah, you do. Get to work,” you know? And that's the gig.
\n\nOr, you know, even worse than that, you're scraping together hours in your free time where it's just like, yeah, man, I don't know if, like, I don't know if, what is it, .NET? I don't know if .NET programming is for me. Maybe I'd like to learn Ruby. And now you're sort of trying to claw together nights and weekends and stuff like that. And I think that is a substantial driver of burnout and sort of like, I don't know, it uses engineers up. And so, how do you engineer that stuff for yourself when there's nobody who's going to do it for you? But it doesn't become less, you know, less relevant to maintaining a career.
\n\nDAVE: Yeah. There's a thing that...we keep bouncing off these contrasts between overprescription and under-leading insufficiently. Like, sometimes you pick up the guitar, and you're like...or you stand on the panel, and you don't know what to do. You can't jam in a group if you don't know the key that we're going to play in, right?
\n\nAnd I wanted to circle back to this a little bit. One of the things that was super powerful to me early on my career was the discovery of a concept of mentoring, where a mentor is somebody who knows many, many, many, many, many things. They’ve forgotten seven ways to solve any problem that you're going to deal with, but they won't overprescribe. They will show you one way to do it, or they'll say...ah, my guitar teacher, I could not get this chord change, and he said, “Maybe try switching to this finger.” And all of a sudden, I could go from this chord to that chord, and I would just pivot. And it was easy and ergonomic.
\n\nAnd finding a mentor can help you really accelerate both because the mentor can say, “I'm not going to tell you the 73 ways you can do this and force you to learn all 73 of them before I let you do any of them. I'm just going to give you one to try, and I'm going to debug...oh, you're struggling here because of this. And there's this problem that you don't know that, you know, do this and, all of a sudden, your program just works.” And the first few times, you don't know why, right? Because your mentor knows [inaudible 45:25]
\n\nWILL: I wish we had time to get into the continuing education aspect of this thing. Because I think this is where, like, in my opinion, this is one of the great sins of the industry, in that, like, technology is moving so fast, all the time, so fast all the time. I do feel like it's slowing down a little bit, which is nice for me. But --
\n\nDAVE: Is it slowing down, or has the frenzied, fresh, cutting-edge moved away from where you're focusing? I'm running into that. There's as many forest fires to fight every single day. I just don't see them. And I walked into, like, the AI stuff, and I got to run so hard just to stay at the back of the pack.
\n\nWILL: I'm not sure. I'm not sure. I'm not sure. I don't know. You know, I just don't know enough about AI to really know, like, what all is going on. Although, I mean, I will say that, like, it doesn't seem like, I don't know, who knows? That's a different, separate tangent. But --
\n\nDAVE: Yeah, the idea is the sigmoid pattern, right? Things that are on fire tend to taper off over time. Yeah, yeah.
\n\nWILL: Well, exactly. So, the question, I don't know, I mean, the one thing that I wish we could have gotten into a little bit deeper is continuing education for engineers and how to keep things going, you know, because, like, it isn't...the problem with, you know, engineering education isn't so much that we don't know how to do it, you know, when we can be bothered to.
\n\nThe issue we run into is, can we be bothered, you know, can we be troubled to keep these things going? And I think it's shockingly wasteful. We burn a lot of engineers, they're perfectly good engineers, just because we can't bother to be training them on the new stuff. And, I mean, if you compare that to other industries, other professions, other career development stuff, nobody does it like this. It's really crazy the way things are going. But it's still incumbent on us as practitioners, as craftsmen to keep that stuff going. And if your boss won't do it, if it isn't part of the industry, then you just have to work it out yourself.
\n\nDAVE: Yeah, your knowledge portfolio [inaudible 47:45] career, and if your boss isn't investing in it, you're dying. You need to invest in it.
\n\nWILL: Yeah. Yeah, precisely. I mean, you know, I mean, they'd be happy to get rid of all of us and replace us with new grads for half the money.
\n\nDAVE: Yeah, until they find out that what they needed for that server fire last week was an engineer who has forgotten 19 different ways to solve that problem. All right. It's great to have a team full of people that can solve any problem first principles, but it's kind of a pain when your entire team has to solve everything from first principles.
\n\nEDDY: I think basically just coming back and having a [inaudible 48:25] is basically is there's different ways to learn, and it just depends on the personality of the individual. And it's funny how we keep coming back to music, unironically, from other sessions. Like, there's a parallel between music and programming. It's great.
\n\nDAVE: Music, linguistics, and programming has one of the most creepily off-the-charts, oddly specific overlaps. Get a musician, a linguist [inaudible 48:58], a programmer, just every time. Yep.
\n\nWILL: Interesting.
\n\nEDDY: Yeah, it's awesome. I'd like to see that study. It'd be great.
\n\nWILL: All right, well.
\n\nDAVE: It was just anecdotal, so... But so, now we've got our next...this is turning into the podcast where we tell people, let's do a part two of this, and then we never do the part two of this. Someday, we'll get around to part two, so...we hope.
\n\nWILL: Well, thanks, y'all.
\n\nDAVE: I think this has been a really good chat. Yeah, thanks for coming. Thanks for listening if you're at home. And if you're not at home, go home, and then, thanks for listening at home.
","summary":"","date_published":"2024-10-16T12:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/b2e907cd-f139-4806-8ee7-faa54afd8464.mp3","mime_type":"audio/mpeg","size_in_bytes":30344817,"duration_in_seconds":2984}]},{"id":"cd1eedb7-1603-4d3b-a135-acb2f0d9f974","title":"Episode 56: Team Sizes","url":"https://acima-development.fireside.fm/56","content_text":"In this episode of the Acima Development Podcast, the panel, led by Mike, explores the concept of team sizes and how scaling impacts management and functionality. Using an analogy from the film Honey, I Shrunk the Kids, Mike highlights how physics, like management strategies, change with scale. The group discusses how larger teams can't be managed in the same way as smaller teams and why losing a team member in a small team is more critical than in a large one. The discussion then shifts to defining the role and purpose of a team within an organization, and how the size of the team depends on its function, specialization, and the applications they support.\n\nAs the conversation evolves, the participants debate the ideal team size, suggesting that teams larger than 10 people become difficult to manage effectively. Justin and Matt argue that team dynamics, including the experience levels of team members and the distribution of leadership responsibilities, play a crucial role in determining the optimal team size. They emphasize the importance of having a blend of senior and junior members for long-term sustainability and organizational growth. The idea of \"seed corn\" is introduced, highlighting the importance of nurturing junior members to eventually fill senior roles.\n\nThe panel also touches on the downsides of excessively moving team members around, which can harm team cohesion, yet acknowledges the benefits of cross-training and preventing silos from forming. Will and Dave provide examples of how large teams can succeed with strong leadership and effective management, but caution that poor management can lead to inefficiency. The episode concludes with a discussion on how cross-team communication is one of the biggest challenges in scaling and maintaining effectiveness, with the panel agreeing that the sweet spot for team size lies between 6 to 10 members.\n\nTranscript:\n\n MIKE: Hello, and welcome to another episode of the Acima Development Podcast. We have a great panel here today, a large group. We've got Matt, Eddy, Will, Ramses, Justin, Dave, and Kyle all here with us. We're going to talk about team sizes. There’s kind of a carryover from a couple of weeks ago. We talked about other items of scale. But we're going to talk about team sizes. \n\nI'm going to start by talking about the movie, “Honey, I Shrunk the Kids.” People of a certain generation watched that movie [laughs], and it's not the only one like it. You know, there's a history of movies where people shrink. There's Marvel movies, you know, people go really small and really big. And, in those movies, generally, all the laws of physics are basically exactly the same as they are when you're larger and people are smaller, and that's it [laughs]. Everything works exactly the same. \n\nOne thing that kind of blew my mind when I ran into it is not even remotely true. And you can see it by looking at ants. Like, in that movie, the ants are big, and everything's fine. All the physics work totally normal. If you look at an actual ant, when they get hit by water, it is fundamentally different than what we experience water as, as humans. Because even just at that difference of scale, water is like glue. If you look at an ant when it gets in water, it is like, you know, it touches that drop of water, that ant is stuck, and it is a huge effort to get extricated, you know, it's like running into a giant pile of tar. Because you go down in scale, it fundamentally changes the nature of physics. \n\nYou know, you can see an ant. It's very visible that, even at that scale, our physics are different. Water does not behave in the same way at all as it behaves for something larger scale. It's just different. And, you know, and you look at a microscope. It gets even crazier. I mean, you can see in a microscope with a Brownian motion, where you get small enough, and you see things just kind of randomly moving around because of quantum-type effects. And you have molecules bouncing around; stuff is just going to generally float in a way that we just don't experience at our scale. \n\nAnd it breaks our intuition because our intuition is built on the scale that we normally work with. But even something you can see, and you can look at an ant, it's different. The physics are totally different for something as simple as water, you know, droplets of water, when you go down to that size. I say this is relevant because there's a lot of things like that, where scale changes things.\n\nWe're going to talk about team size today. And I'd argue pretty strongly that you can't just take a team of two people and manage it the same way when you've got 100 people [laughter], and maybe you can try. I hear laughter [chuckles]. It's different when you scale up in size. I had this conversation recently, thinking about different company sizes. If you've got an engineering team of 1000, the way that you can run that is totally different than even at 100, you know, you go a factor of 10, and that's very different. Then you take 100 versus 10 it's totally different. If you've got 10 people in your department and you lose somebody, that is a critical loss [laughs]. \n\nIf you've got a team of 1000, well, you're probably losing somebody every week, and that's probably fine because you've got your systems built up to handle that. Now, on individual teams, we have a variety of team sizes, you know, beyond just department sizes, and those scales matter. This [inaudible 03:47] in a lot of ways. So, I've been talking for a bit talking about how scale matters to kind of launch the conversation. Based on that, I'm going to ask the pointed question that prompts the debate. I mean, how big should a team size be, knowing that different scales matter? \n\nWILL: I would first ask the question of like...And I don't think this is a singular answer, but what is the role of a team in your organization? Why a team? Like, what's the role that the team is organized around doing stuff? It's a functional group, right? Sometimes people have sort of like, okay, this is a functional group, like, this is my DevOps team, and it serves this function. Sometimes it's sort of like a...I call it an administrative unit, where it's like we have interfaces with the bureaucracy, either through product, you know, leadership, or just sort of administrative management stuff. Sometimes they're areas of specialization within the codebase. They could all be different things. So, how big it is is maybe directly dependent on that. \n\nSo, let's say you have...DevOps, I think, is a good example. So, if you have a small DevOps team, maybe you only have two, you know, DevOps engineers. Then the right size is two, you know? If you have maybe six DevOps engineers, where, like, does two teams of three really make sense? Maybe it doesn't. And so, then you'd have a team of six, which could be a little heavy for a software development team, right? A team of six engineers is starting to get kind of big. And so, the size of it is definitely going to be informed by the functions of the team. \n\nMATT: Yeah, I think there's some questions that you have to ask yourself. How big is the application they're going to be supporting? Are they supporting multiple applications or services? Can those things be broken into domains? Do we have teams that support specific domains, or do they just umbrella and support everything? I think if you can answer some of those questions, it makes it a lot easier to determine what that team size should look like.\n\nJUSTIN: I would suggest that there's a maximum team size that exists that you don't want to go larger than X, no matter what application you're supporting. Because it suddenly becomes a case of people don't know what other people are working on. It becomes hard to coordinate. There's not interconnectedness. All the manager is doing is managing people and losing technical insights. So, yeah, I think there may be an upper limit there that you can't cross. \n\nMATT: Totally agree. Another thing that you need to think about is, are we talking team size from an HR management perspective so for, like, an engineering manager, or are we talking about teams from a team lead perspective? Because you may have 10 engineers that are technically part of the same team but broken into, say, sub-teams because we have a lead to support those engineers, right? So, they can work on different things, have a different person leading projects instead of the manager trying to lead all of them at the same time on multiple projects.\n\nWILL: Justin, I saw your face, Justin. You're like, no, no, no. No, that's two different teams. You just got two different teams in the same bucket, you know what I mean? It's like a duplex. We don't live together. We just live in the same building, you know [laughter]. \n\nMATT: So, semantics are important.\n\nWILL: But I am really interested in sort of what Justin brought up, which is like, okay, you're right; there's a ceiling for team size. Is it determined by a bunch of really specific things, right? You can't say, like, “No more than 10,” although that's a pretty good limit, you know [laughter]?\n\nJUSTIN: I agree. \n\nWILL: But how do I know, like, okay, like, you got to split it up; you got to split the team up; this is not working anymore? And then, like, more of, like, things that you'll see happening rather than, you know, a number. \n\nMATT: Yeah, what if...let's say six people is this example team size. What if all six of those people are all subject matter experts and senior-level people versus a team of six people that has one subject matter expert and senior-level person and five entry-level or junior-level engineers? I think then that changes things. That dynamic is different. \n\nWILL: Well, you may actually just want to spread them around [laughs]. \n\nJUSTIN: Yeah, exactly. That's not using your resources correctly. \n\nMATT: Well, it may be the case that those are the only resources we have. So, do you keep them together, or do you split it into two teams of three and have a junior engineer as your lead for one of those teams? I mean, those are the kind of questions we need to think about. \n\nJUSTIN: I think maybe a better way to look at this is like, what ingredients do you need in a team? You need probably at least one senior person or a tech lead. What else do you need? \n\nEDDY: You need a junior on your team [laughter]. \n\nWILL: Maybe. Maybe.\n\nMIKE: Yes, you do. I made this argument emphatically sometime in the last week or two. If you don't have a junior developer, what I said is that you're eating your seed corn. Because if you don't have somebody growing in experience to become the next subject matter expert, then your senior engineers, when they move on, leave a hole that you are not going to be able to fill. I think you absolutely need, if not a junior, you know, somebody who is learning the ropes and growing into that position. \n\nDAVE: It's almost like a long-term, short-term sustainability, right? Because I mean, you can have a small, tightly focused tiger team that goes in, takes care of the business, and gets out, but that's not a long-term sustainable...right? That's like a task function. And you don't need a junior for that. That's fine. You can have an operating theater full of brain surgeons, but if you want long-term sustainability, you need to view...\n\nI think we talked about this a long time ago, Mike, that when you give a programmer a problem, we don't take problem in and solution out. You actually take a problem and a programmer in, and what you get out is a solution and a smarter programmer. And if you start viewing it that way, as, you know, you are part of the output of this unit, you do, you need new people to step up because someday you're going to be gone, and that team will be gone if you weren't eating your seed corn, yeah.\n\nMATT: Teach a man to fish, give a man a fish, right?\n\nDAVE: Yeah, light a man on fire, you keep him warm for the rest of his life, yeah [laughter]. \n\nWILL: You know, I don't know; I mean, on one hand, I get what you're saying. But, I mean, one of my persistently more controversial software management beliefs is that we should be moving people around a lot more. So, this sort of like, you know what I mean, this thing you said where it's like, it's bad to have task-oriented teams. Like, I love task-oriented teams. I love getting together a team to do the thing, and then they go away. Dude, I like it because by enforcing that sort of procedural process discipline, you don't let people put together the little fiefdoms, and you don't let people evade accountability for corners that they may have cut, you know what I mean?\n\nLike, you make sure that people are cross-trained around stuff, and you can have little domain expertise areas of stuff that's going on there. But I find that one of the real sort of long-term rots that gets into a software engineering organization is people get into their little...they carve out a comfortable little niche, and then they just sort of sit there. And they don't necessarily, I don't know, I hate to use the word rot, but there's definitely a lower level of operational intensity once you really have your little flow within the organization. \n\nMIKE: They talk a lot about silos. They talk a lot about silos, right? And you know what a silo is for? Sometimes people think, who are unfamiliar with farming, that a silo is for storing grain, and that's not true. A silo is for storing wet grain so that it will rot. The purpose of it is to ferment it because that's a different way of preserving it. \n\nDAVE: Oh wow.\n\nMIKE: So, you take, like, green corn, and you throw the whole thing in, or you maybe throw your corn in there. But yeah, silo is different from a grain elevator. A grain elevator to keep dry. A silo is for keeping wet so that it will ferment so you can feed that fermented food to the animals. \n\nDAVE: I didn’t know that.\n\nMIKE: And [laughs] it's a great image because once you build a silo, it's going to ferment [chuckles]. And we talk about silos a lot. I don't know that we always think about the implications of that, that when you silo something off, that's going to start to go rotten by design.\n\n[laughter] \n\nDAVE: Can I offer a counterargument to both of those ideas, though? I agree with both of what you said, 100%, but it's not something to be taken completely without a qualification. There's a...oh, I'm blanking on the author. There's a book called “The One Thing You Need to Know.” And it's a book on basically what makes people happy at work. And, basically, they interviewed a bunch of people and say, “How happy are you at work and how are...?” And then, they started looking for clusters of things that were true, you know, random things that happened to be true about these people. \n\nAnd the number one non-trackable business, there's no KPR spreadsheet for this, the happiest people all had a best friend at work, which I thought was really, really interesting. And I'm a naturally gregarious, very loud person. And when I read that, I'm like, I need to double down and start making actual friends at work, and I did that. When I was at CoverMyMeds, I did this. And they had a transition. They got acquired, and they brought in some senior management whose job was just to fluff the grain and just screw everybody up just to prove that we'd been acquired.\n\nAnd we had a manager who the very first thing he wanted to do was separate everyone, so he just took all the teams and just sliced them up. So, you were on teams with complete strangers. And I think he had the idea of cross-pollinating, right? But if you take, and I'm going to mix my metaphors badly, if you take your sourdough starter and you spread it so thin that you kill the culture, it's not sourdough anymore. You haven't spread the culture or homogenized it. You've just wrecked it and ruined it. \n\nAnd it broke me because I went to the next team we were on. I started forming friendships. We got really, really close. And they did it again. And the third time through, I'm like, I think you guys are actively trying to demoralize us. Because they were cutting us off, like, every three months. There was no chance to form any kind of a personal relationship with people. So, I suggest that as a counterpoint. I 100% agree that the professional objectives, absolutely, they should be changed, or you get bored.\n\nMIKE: So, I talked about the silos because that's what silos do, but I actually was going to push back some as well. Have any of you read “Team Topologies?” I'm seeing a couple of nods here. It's a book worth reading. One of the things it says is that teams become more effective over time because it takes a while to learn to work with each other. \n\nSo, there's two kind of competing principles here. One of them is that if you’re isolated from everybody else, you tend to become very insular, and stale, stagnant, right? The other is that teams that have worked together know how each other work, and they're just going to work better. In general, a long-running team is a more effective team. And so, an effective approach needs to somehow combine those. \n\nThe idea of sub-teams got brought up. I don't know that sub-teams...they may just be separate teams. But one thing that can happen is, on a team, you can have rotating assignments, such that you still have a...you have a persistent team that takes on different kinds of work, and you may have different groupings within that team also. But you still have strong cohesion because you have your group of six, or whatever it is. You know each other, [inaudible 16:49] each other really well.\n\nYou may be grouped together on different projects, and you may be bringing in projects that are very different than the ones you did. Having a team work on different projects can help break the silos without necessarily disrupting the team for no reason. And I think that disrupting a team just to reorganize is a really bad idea. \n\nWILL: You know what? Any virtue taken in excess is vice, right? You can screw it up in both directions, right? But, like, persistently, what I would say, like, the cancer eating away at software organizations, there's two things, cross-collaboration among engineering teams and organizations is just a bag of hurt. It's sucked everywhere, and some people suck more; some people suck less. But it is the number one bogeyman of everybody, everywhere, all the time, forever. Like, I've never seen an exception to this, and second only to crappy managers.\n\nAnd those are two things that must be hunted down and eliminated constantly and mercilessly. And it's just sort of like, if you're not stirring the pot, those two things are going to creep in. It's a constant bailing out of water to keep those two things from sinking you. It's inevitable, you know; you have to have an answer to it.\n\nAnd I think moving people around, you know what I mean, like, I agree, you can do it too much. But moving people around has a lot of really strong positive effects in letting your organization thrive, you know what I mean? It's like, oh man, this manager is always getting it done. But like, oh man, everybody hates working with this guy. Like, oh man, this junior engineer is really good. We don't have a senior seat for him, but like, man, he's really ready to go, ready to move up. \n\nOr, like, oh man, this senior engineer has kind of lost the plot. And they're smart, but they're just not working well with people. Like, all of these things are stories that I'm sure a name popped up into each and every one of you guys’ heads as I was saying each and every one of these things. And if you're stirring the pot, if you're rotating through, if you're giving people opportunities to do good or to do bad, then that kind of stuff is going to surface itself, and you could do something about it. \n\nMIKE: Do you know all of these people, that is --\n\nWILL: Every last one of them. Every last one of them.\n\nMIKE: My question is, do you personally know these people within the broader organization today? And if so, that means that you're not talking about moving somebody somewhere where they don't know anybody. You're talking about a subunit of the company that's cohesive enough that you actually know all these people. \n\nWILL: It would be stupid to just drop somebody, just airdrop somebody in by a parachute in some situation where they could do no...you know what I mean? I mean, I'm not dumb. I understand that you can't just be like, “Hey, you're doing Haskell today.” Like, yeah, yeah [laughter], you're DevOps this quarter. Get to work.” You know [chuckles], that's not how it works.\n\nDAVE: I've seen it work, and I've also seen it fail spectacularly, where we had a system recently where we swapped an engineer out to help another team. And that other team's process was very, very different, and it was very rigid. And they were under the gun. They could not stop and say, “We need you to do this, do this. Everything you're doing, we need you to do it sideways because we will do layer cake instead of,” whatever, that kind of thing. At the same time --\n\nWILL: Oh, you have a bad manager. What a wonderful thing to know about.\n\nDAVE: Right? And I understood, like, why. Like, all the intentions were good, right? It's like we had a problem. We need to throw more bodies at it, right? Conversely, when I was at CMM, and they were still a unicorn, we came up with a thing that...I called it hostage exchange program, where we would go to your team and say, “Give us a developer. We'll give you one. You give us one.” \n\nAnd so, we would swap with another team, like, all the way across the building, completely different project, different vertical of the company, different profit centers. And we would swap out one person for two weeks. And very importantly, it was seed corn. It was, we're here to cross-pollinate you, to make friends, and show you how we work. We are not here to sweat you and try to get you to scream everything over the line. Because when you go to a new thing, you're going to be useless, right? But after the exchange, because we had one of yours, you had one of ours. \n\nAnd then when you swap back, this amazing thing happens because it's like, “Oh, man, we need to cycle the pods on the Jenkins thing. And how are we going to do that?” I don't know. That team doesn't like to talk to us. And the one guy who was in hostage exchange goes, “Oh, hang on. I'll just ask Justin,” right? And all of a sudden, there's a personal relationship formed. And that was like, if you forgot everything you learned while you were on that team and you just remembered who you met, it's a victory, hands down.\n\nWILL: Exactly. No, absolutely. \n\nEDDY: Or better yet, Dave, you can just be like, “Oh, I've done that before. Let me go [laughs] and do it.” \n\nDAVE: Yeah, yeah, hands down. Mike, we were talking about this on the team the day we had a deploy issue. And we have this really convenient, for those people listening out there, we have a really convenient way of deploying. There's a little thing that we click, and we get a notification that says, “If you want to deploy this, click here to deploy it,” and it's great. And you don't have to go into Jenkins and fiddle with the drop boxes and find your image and all that stuff. And I kind of forgot how to do it manually.\n\nAnd so, we had an incident last week where we were like, you need to roll this back. And it wasn't me, thank goodness. But I'm just kind of on the sideline eating popcorn going, you know, if that had been me, I would have been stuck because I have forgotten how to do it the hard way. And I’m like, we need to get the team together, and we need to review how to do it the hard way. So, like you said, so if something happens, you don't have to call somebody who knows how to do it. Just, like, everyone is just like, “Oh, wait a minute, I know this.” And if you've got a process to document, you're like, I know where to look for it in the wiki, and then all my notes will be there, and yeah.\n\nWILL: Absolutely. At the large retailer that I work for, you know, they have an unofficial tradition, 52 [inaudible 23:14] pickup, Q1 of every year, where they just, like, completely demolish the org chart, and it's anarchy. And I don't think they do it on any kind of, like, high-minded management, you know, theory principles. They just do it. \n\nBut one of the nice things, like, having been here for a couple of years and gone through several purges, is I've got people all over the company. Anything I need done, like, I've got a person. I’m like, oh, I'll take Dave, or I'll take Reed, or I'll take Max, or I'll take whoever. And I have somebody to ask to get a thing done, and it makes me really effective. \n\nDAVE: There are people in your organization who will try to shut that down, thinking they're doing a good thing because once a team starts...like, when IT starts getting overloaded, they start saying, “We need everyone to fill out a ticket on Jira because we can't manage our workload,” right? And if you know somebody and you pick up and you...I'm just going to call Corey. He'll take care of this for me. And, like, Corey has to say, “I need you to fill out a ticket, man.” But you don't have to kill either of those, right? You can still do the, “Hey, I need this,” and your friend in IT can go, “Oh yeah, just check the PRAM, just reboot it, do the thing, you know.” “Oh yeah, I remember that.”\n\nAnd then if it's going to be more, it's like, you know what? You're right. That's serious. Fill out a ticket, and I'll jump on it. So, you can still get the best of both worlds, but you can have people that are simple-minded of, like, just do it this way. And like you said, a virtue taken to an extreme can turn into a vice. \n\nMIKE: So, we've talked a lot about swapping people around and getting them into different experiences. And I heard a couple of numbers thrown out. Somebody said 10. Oh, you shouldn't have more than 10. Somebody said 6. There may not be a clear line there. But what is that number X? And maybe, more importantly, why is there a maximum team size? Why does it stop working? \n\nDAVE: In the pre-call, Mike, you posted a link to Dunbar's number on the wiki. Real quickly, for people listening, the size of the frontal cortex of a primate's brain determines how many meaningful relationships that primate can have at any one time in their life, and, for humans, it's about 150. I wanted to throw that one out there because I recently learned of another one called optimal tribe or optimal primal group...I don't know if it has a clear name, but the way they calculate it is fantastic. Anthropologists have determined that when you have this tribe of, like, 150 people, you're spread out over the valley, and you actually have subgroups within it.\n\nYou might be in a group of, like, 500 people, but you're spread out over about...150 of those are your relationships. But the people that you rub shoulders with every single day of your life is more like 30 to 35. And this number self-balances because among humans, somewhere between 30 and 35, the murder rate balances the birth rate. I love that number, that it's, literally, I will kill you if you add one more person to this team is how we dealt with this 10,000 years ago, and I think that's fantastic. I think it's brilliant. \n\n[laughter]\n\nJUSTIN: So, I don't want to be on David's team [laughter]. \n\nDAVE: Yeah, because we've got 34 right now.\n\nWILL: I don't think we're going to see deaths necessarily. \n\nDAVE: No, no, no, not where you can see ‘em.\n\nMIKE: [laughs]\n\nWILL: I think what you do see is you run into the bureaucracy associated with creating and processing and assigning work, you know what I mean, like, breaks down. That's what happens. You can't effectively utilize your people because you have this sort of, like, feast or famine, these wild swings and the amount of work you've got to do. Like, I'm getting ready. I'm warming up for a giant work hangover next week because we've got a big thing we're shipping out. \n\nAnd all of our leadership management capacity has been dedicated to getting this thing over the line. And it's a big fella, so I forgive them. But we're going to have a giant night hangover, where there's just nothing in the pipeline, and then they're like, “Oh, uh, do this.” So, that's where you break down, like, the ability to assign and manage and, like, hey, provide feedback. All that stuff it breaks down. You just can't [inaudible 27:44]\n\nJUSTIN: So, can you have a larger team if you have people helping lead it? And by this I mean you have project managers who are tracking the projects that are out there. You have your tech lead. You have your engineering manager. So, how does that all fit together? And then, you actually have the people doing the work of which, hopefully, your tech lead is one. And then, you got the other, you know, senior, regular, and junior engineers.\n\nWILL: I think there's a finite amount of leadership and, like, I don't know, man. I mean, sometimes that's the project managers. Sometimes that's them but not all that often.\n\nMIKE: If you have really good leadership of the kind you describe in sufficient quantity, I think you can push above maybe that 10 limit. Maybe you can get close to 15, pushing 20, but it is continuous work. And those leaders are going to be just incredibly busy. I mean, that's going to take a finely oiled machine, and it's really hard to replicate. They talk about this in “Team Topologies,” yeah, you can maybe go over 10. And you might be able to pull it off for a while, but if anything goes wrong, the whole thing falls apart. \n\nJUSTIN: Wasn't it the two-pizza rule? You can only have a team that you can use two pizzas to feed. That’s your team limit.\n\nDAVE: That's right. So, 200 people if we really sweat them and give them the [inaudible 29:11]\n\nEDDY: What if I eat a whole pizza, Justin? Like that’s -- [laughs]\n\nDAVE: Then the other nine people split the other one, yeah [laughter]. \n\nMIKE: When I was in high school, I was running cross country and growing like a weed. I could down two extra-large pizzas myself [laughs].\n\nDAVE: I grew up in Ranch Country, and there was a phrase that people would say that, “I have teenage boys. I'd rather clothe them than feed them [laughter] because it's cheaper.” So, the number with the group size, the thing that they found out of this was...because humans, we've obviously gone past the point where we can be around 35 people without committing a murder. And they see anthropologically, in the records from about 15 to 10,000 years ago, three things started happening. We started dancing. We started singing, and we started worshiping together as groups.\n\nAnd what this does is it gives you the ability to walk into a room and meet a stranger, you know, stranger danger, we're afraid. Like, you know, primates, we're just like, [vocalization], you know, do I need to worry about you? But we've got this thing that we're all looking at, and I’m like, oh, wait a minute, we're all here to worship at the same time. Or here, we're all here to sing and dance and experience this pleasant experience in a safe environment. I can call you my tribe. I can call you my friend. And from there, we then get scaled all the way up to, you know, patriotism for a country.\n\nI used to hate, hate with a passion, town hall meetings where the CEO comes down and tells you about the corporate vision. And now I realize it's absolutely essential. You can have 25 people on a team if you all are looking...like, the interpersonal team communication is going to go exponential, right? It's a triangle number like n times n plus 1 divided by 2, something like that. \n\nThe links between the number of nodes goes up exponentially, and that will fry and become exponentially difficult to manage. But for a short time, you can exceed that number if all of you are looking in the same direction, if you're trying to pursue, you know, common gods, common goals, common enemies, that sort of thing. You're like, okay, yeah, I can pick up and pull in the traces next to you without knowing your life story. \n\nWILL: You must be going to different town hall meetings than I am. \n\nMIKE: [laughs]\n\nDAVE: I am a different person in town hall meetings than I was two years ago. And I would say I'm going to different town hall meetings than I was two years ago. And, yes, I've been at Acima for more than two years. So, what I'm saying is I have changed, and the experience of the meetings is different now, yeah. \n\nWILL: I actually see most of the corporate town hall meetings that I have witnessed are actually like a case study in, like, this isn't working anymore. This is no longer anything. Because my experience with the meetings has been, typically, that we're not on the same team, like, anymore, like, the C-level executive that I'm meeting and me as like a, you know, a skilled worker, certainly, and somebody who's like, you know, I punch above my weight in terms of impact. But we can't have an honest conversation. They're not doing that with me anymore. \n\nI am a resource to be managed and not really dealt with forthrightly. It's too big. We're too far away. Our interests have also rather sharply diverged. And so, there's a lot of, like, I don't know, man. They're lying, and they know they're lying. I know they're lying. We're all sort of like going through this theatrical display, you know what I mean? \n\nDAVE: 100%. 100%.\n\nWILL: I'm just like, all right, guys. We're not that. We're not that. We're not on the same tribe anymore. Don't put my face in it, okay? Like, I could listen to the investor call if I want to know what you're doing to justify your share price. If we need to do that, that's okay. \n\nDAVE: The corollary that I take from that is that there's times when I sit in church, and I'm like, we are all here to do the same thing. And then, there's times when I remember a...my dad had nothing to do with church or religion for most of his life. And it was because he would sit, and his experience was, you'll shake my hand on Sunday and stab me in the back on Monday.\n\nAnd if you've ever had that experience of sitting in church-going, you SOBs are all miserable jerks, and not one of you believes in what we're doing, that's a horrible town hall to be in, right? It's like, oh, yeah, yeah, you're not trying to incentivize us. You're trying to sucker us into doing work now in exchange for a promise for something you're never going to deliver, right? When there's no faith in that, it's brutal, right? It's the opposite of it. \n\nWILL: Well, I mean, I don't have a problem with working for Corporate America. It's fine. I'm not some guy who's [inaudible 34:02] is communist, you know what I mean? Let's all get paid. Let's all make really cool stuff for our customers and delight them. And then, they will give, you know, us some of our money, and then I will get my piece of that. You'll get your piece of that. We're all going to be good. But that's not a forthright conversation that we're having.\n\nDAVE: No, it's not. \n\nWILL: It's like big meetings, right? Big meetings, big companies. Like, it just gets so big that you're not really...the gap's too wide. \n\nMIKE: Well, we're talking, I mean, this is germane to the conversation because we're talking about ways to maintain group cohesion. And you're saying, as you get large, you get to town hall size, it is really hard, that getting everybody on the same page and making them happy about it may just utterly fail. So, if those tactics are challenging with a large group, it says something about the team size, right? And if you look at hierarchy of organizations, there usually is a hierarchy.\n\nWILL: Sure.\n\nMIKE: And at any level of the hierarchy, you have, you know, probably that six to, you know, 12 or something people at that level so that everybody is within a similarly sized team because it's really hard. It's really, really hard when you try to scale that up. \n\nJUSTIN: So, going back to your talk, I mean, your chat about, you know, getting everybody aligned in the same direction, I can't help but think about the example of Twitter, X. And say what you will about Elon Musk. He forced his way to everybody be in the same direction, and I am very curious to know what impact that had on their team sizes. Because I'm like [laughs], did they...\n\nEDDY: Correct me if I'm wrong; it might be inflated, but I think over half of the team left when he forced his way.\n\nJUSTIN: I think so.\n\nWILL: 70%, yeah. \n\nEDDY: It was quite significant.\n\nJUSTIN: And so, do they have smaller teams, or do they have larger teams with fewer managers? I bet that's what happened. My theory is that Musk got rid of most of the middle management, and they have the engineers left who are interested in working for Musk and are probably well-compensated as well. \n\nWILL: [laughs]\n\nJUSTIN: And so, they're all aligned somehow. But, I don't know, that is going to be an interesting case study in some future, you know, business school or engineering school. \n\nWILL: I’d imagine you're right. I’d bet you any sum of money the team sizes are larger. And I think probably you got a lot of people on a visa who aren't empowered to just go anywhere. And I think they're probably making less money and working harder, and maybe just didn't have the option to hop over to Amazon, or Microsoft, or Google, or whatever. We'll see. We'll see. \n\nI think there are a lot of people who are leveraging tech winter right now. And whether that remains to be a sustainable management practice or not is going to be told, you know, when tech starts to boom again because nobody got off their phones, man.\n\nMIKE: [laughs]\n\nWILL: And then, the market for talent becomes a little more competitive. I think there's a lot of people who, you know, it's your way in this, like, rather sharp and prolonged economic downturn for our slice of the economy but long term, I don't know, man. I don't know. Is it good management? We'll see, you know. Sorry, that's a little bit of a tangent, I think. \n\nMIKE: Yeah, no, it still comes down to, you know, how do you work with the group? How do you keep the group cohesive, and the challenges with that? So, is 10 a reasonable cap? Like, if you got a team bigger than ten, you better look at cutting it? \n\nJUSTIN: I don't think I've ever been on a team that large. I think the most I've been on is...well, I guess it depends on how you define it because I've been on front-end teams where we have the product owner and then the designer. And then, I was a full-stack engineer, so I helped the frontend and the backend, and the database [laughs], but there were also people on each of those. And so, I guess we were, you know, if you include the designer and maybe a database guy, I don't know, it's like, you know, hey, we're together for a project. But I don't think it ever got up to 10 in our standups. I think the max number of people in our standup was, like, seven or eight. \n\nDAVE: I'm hesitant to say a number. I worked at Evans & Sutherland around the turn of the millennium, and I was on a team of 50, 25 software engineers, 25 hardware engineers. Basically, we'd come up with the same idea that NVIDIA had, that you could do 3D in hardware and do it very, very fast. You could do stuff in real time that couldn't be done at that point, and, it worked really, really well. \n\nThe 25 people, the status meetings got [inaudible 39:00], but those went on and on and on and on, right? It took forever to get through the status stuff. And, yeah, subdivided, and, like, I was literally...my sub-team was in the middle of a cube farm, but, like, my job was 2D-bit blit block image transfer. My job was to move rectangles from one place in memory to another. And there was somebody else whose job was to handle 3D and somebody's for curves. Literally, we had a triangle team, like, literally. But at 25 people, it functioned. \n\nBut what I will also say is I was on version 3. They had built the entire graphics card for real image 1, real image 2. I was on the Real Image 3,000 team for making version 3. And we also did largely waterfall because there was hardware coming through the pipe that had to be anticipated 18 months in advance. And the rule for waterfall is don't do it unless you've built the exact same thing twice before, which they had. And so, there were a lot of stuff that, you know, that had happened in that.\n\nWILL: Right now, like, my daily standup has 18 people in it. \n\nDAVE: How long are your stand-up meetings? \n\nWILL: 30 minutes. \n\nDAVE: 30 minutes? That's a status meeting, yeah. \n\nWILL: Eh, it's okay. Thirty minutes is fine. They're pretty efficient. They tend to go over fairly regularly, but not because of the status meeting being bad, just because we're just getting ready for a big release, so there's a lot of nuts and bolts to make sure everything goes right.\n\nAnd I would say that the team is functional. And it is really kind of one team, but there's a manager, and then there's sort of an assistant manager. And there are some, you know, pretty senior, you know, sort of shadow management. Like, we have at least three people that could and do act as managers, like de facto managers. And so, it's big, and it works. And it works as, like, a single team, but there's a lot. It isn't just a guy. There's a lot of support. \n\nMIKE: So, proof. There's an example case of all the support you can push up close to 20 and make it work.\n\nDAVE: For a while. \n\nWILL: But there's like, well, yeah, but there's also at least three people who are acting, like, two named and one unnamed people who are doing that job. And if you took any one of them out, the whole system would collapse. And so, you think like, oh, we've got 18 people on one team. But it's like, yeah, but you've got three managers, so that's, like, three six-person teams kind of in one thing. It would be hard to make that a sustainable thing other than just sort of a special case where it's like, if you have the right mix of people, you can make it go. \n\nDAVE: There's something going on right now where I live and work. And, Eddy, I think, Eddy, you're in Michael's team, right? I think I see you in the standups. Maybe not. I'm on a team of 28. Well, I'm on 4 teams that total 28 people. And shout out to Michael McMullin. I don't know what he's done behind the scenes, but our standups are three minutes long. Like, I'm not kidding. Like, we walk in -- \n\nWILL: Three minutes long?\n\nDAVE: Yeah, literally just long enough to...is everybody here? Does anybody have any blockers? And, like, we don't even do the here's what I'm working on, and here's what I need to. And part of that is because we have a channel for that. Mike, you'll be happy to hear this. I have made some impassioned pleas against using a Slack channel for standups. And there's times when that has been completely opaque to me. And when I first started, it was very transparent what everybody was working on, and it's back to that. \n\nI'm back to being able to see what everybody is doing, and because of that, I walk into the meeting prepared to leave the meeting. It's like I kind of know where everybody's at, and we walk in, and then one person will go, “Actually, I’ve got...” and they’ll raise a blocker, and then we'll talk about the blocker for five minutes. I think the longest a meeting has gone is, like, 12 minutes. \n\nI don't know if Michael has a gypsy woman prisoner in his basement, and she's just forced to hex everybody else and not him. I don't know how he's doing it, but it's amazing. It's very exciting to watch. I love it when something miraculous can happen and I'm like, how does that work? Like, I genuinely don't know. But it works --\n\nWILL: I mean, I think it’s working by, like, not doing. I haven't been to the meeting. I can't speak to it. I won't do it. But like you said, like, oh, it's a three-minute meeting. I'm like, then why have the meeting?\n\nDAVE: Well, because sometimes if there's...the reason it was three minutes was there were no blockers that day. Usually, the meeting is like 5, 10, 15, but not half an hour. Like, it’s scheduled for -- \n\nWILL: And how many people are in this meeting? How many people are on it?\n\nDAVE: 28. \n\nWILL: 28? Forget it. Like, get rid of the meeting. I’m sorry, like, you're not doing anything. And, I mean, it's great, like, I don't know, if you don't [inaudible 44:21]\n\nDAVE: Hmm, I disagree.\n\nWILL: With the daily standup, that’s valid. But why even have it? Why even have it? If you're not going to do it, then don't do it. Figure out another way, and that’s okay.\n\nDAVE: We could stop having that meeting and see what breaks, and I kind of don't want to because, like I said, it's magic right now. And I genuinely don't understand it. There's a book that I highly recommend called “Read This Before Our Next Meeting.”\n\nWILL: I have to say the only thing I’ve heard is good is, like, it’s very short. That's the only benefit that I've heard described. And I don’t know how the team runs -- \n\nDAVE: Okay. Okay. Hang on. Cool. Yeah, let me answer the question that you're really asking then, which is, what's going on? There's a book called “Read This Before Our Next Meeting,” where you basically say, “Everyone, this is the objective of the meeting. Come prepared to reach that objective,” and that's the difference. We're not wandering in going, who's doing what, and where are we? We're not looking for a status on anybody. Everybody knows everybody else's status. So, that part of the meeting doesn't need to happen. You're right, that part of the meeting doesn't happen.\n\nBut we do need to know if anybody's stuck, and we need to dogpile on something to save somebody from something. And if there's an issue, we dogpile on it, and we take care of it. And that's the point of that part of the stand up for us, yeah. So, the status part is being routed through another channel, and that's what saves us 27 minutes. Does that make sense? \n\nWILL: I like to see people, man, like, I don't know. Like, that’s just me. I like to see people, and I like to look at their faces, and I like to look 'em in the eye and hear their voices and how things are going. And I get a lot out of that. And I don't think software engineering as a discipline is served by having more people typing into screens in isolation, generally speaking.\n\nJUSTIN: So, Will, I think you bring up a good point, which is part of having a team is creating the culture that, you know, you want to engender within your company. And the act of meeting together and of interacting with each other is how you create that culture. Well, it's one of the aspects of creating that culture, right? Obviously, working with each other, time outside the meeting. But bringing it all in and kind of sharing a joke and doing, you know, interacting in some way, I think, is a great benefit to engendering a sense of teamwork, and so on. And so, that can be hard to do with a larger team. It's a lot easier to do with a smaller team; let me just put it that way. \n\nWILL: I mean, if you have 28 people in a daily standup, like, I don't know how you could do it differently than Michael McMullin's doing it just because you just can't.\n\nDAVE: You can't. It would turn into an hour-long status meeting. And to your point, though, we don't socialize. Well, we do. We all show up a couple of minutes early and then we get the water cooler stuff going on. And I don't count that as part of the official meeting, but I probably should because, yeah, there's some socialization that's essential. And it's good because it's cross-team because, like I said, there's 4 teams actually in there. And if you're going into this meeting expressly to socialize, and communicate status between people, and where are your projects, and that sort of thing, you're not going to get 28 people through in 3 minutes. Yeah, absolutely. \n\nWILL: So, it's like 4 people in sort of a meeting. It's a four-person meeting. Well, I feel like 24 of those people don't need to be there. Like, 24 of those people are not supposed to be in that meeting. \n\nDAVE: I'm hesitant to change the formula because it's working, and I don't know how [laughter]. \n\nWILL: You’re right. No, no, you're right. You’re right. Like, we agree, right? Like, don't do it, but at the same time, like, you've got four teams. You've got four managers who are supposed to be explicitly doing this job. And you have all these other people, what, holding their hand while they, you know what I mean? \n\nDAVE: Yeah. See, we just came off of that. We just came off of a representational republic, and it was satan. It was the worst. The representative served as an information killer, as a communication deaddrop. And we had the team not knowing what the rest of the company was doing or why we were working on what we were doing. And our issue is we’re going up to this person and not going out...we finally started routing around them. \n\nWILL: Oh, so you have a bad manager. What a wonderful thing to know about. \n\nDAVE: That was said, not I, yeah. So...\n\nWILL: Like, I don't even know who I'm dragging here, and I have no accountability whatsoever. But it sounds like somebody has a really important job, and they're blowing it.\n\nDAVE: I won't say how recently before this team. I won't say how recently. I’ll just say that before I commit career suicide. \n\nMIKE: Well [chuckles], you know, there's some aspects of this. We talked about some things to make a group meeting work, but still, you're talking about four teams, around seven, you know, six or seven. It just keeps on coming to that number. Yeah, you can get up to about six, and then that's it. So, you know, empirically [chuckles], this number keeps on returning [inaudible 49:18]\n\nWILL: Okay, what's the smallest number? Let's go in the other direction. Wait, actually, no, hang on. We might not have time to get into this. But I am curious, like, where does the team no longer make sense? One person, you're not really a team, right? \n\nDAVE: I mean, I have arguments with myself, but –-\n\nWILL: Two people, why are you on your own team? Three people, have we seen a team, like, an effective functional unit with three people? It really becomes like, honestly, more, like, on an org chart level, like, does it make sense to give these people a manager, right? Are there enough workers for me to rationally advocate these people that are on manager? It's almost like can I justify the accounting line item, you know, more than anything else? \n\nDAVE: I think it comes down to how much of your objective is explicit and static, where, an organization, you need a lot of that. You could have a team of two, just a partnership. And what direction do we want to go in? We don't need a lot of external, right? And now you can go after a goal, and that goal can change and adapt very, very quickly. If it's a much [inaudible 50:23] thing, then changing the goal is a lot more complicated. You've got to synchronize a lot more people. \n\nWILL: I'm kind of curious to hear from Kyle. As DevOps, you guys are not necessarily always sort of as robustly staffed as, like, software engineers. What's the smallest DevOps team you've been on, like, one or two, two or three, one, just you by yourself? I feel like you feel that more than we necessarily would. \n\nKYLE: Three was the smallest, and I thought that worked really well. Scaling up from that, there's quite a few DevOps tooling that you run into locking situations. So, I feel like you kind of start to develop sub-teams, which we kind of have as we've grown to 7, 10 people.\n\nSo, while I'm sitting here listening to you guys talk about all this, I'm just kind of thinking of team size, to me, I was thinking, well, the minimum and the maximum are kind of dependent on the pipe size, and it will depend on what pipe is coming in or what pipe’s coming out, so your work coming in, the channels that you have to get the work out. So, if you've got a build pipeline that backs up, maybe it's only six people, it makes sense. That 7th person is always just twiddling their thumbs because they're never ever actually able to deploy something, right? \n\nOr, you know, maybe the pipe that's the smallest is the management pipe. The manager over here he can't manage 10 people. He can't manage he, she, it, can't manage eight people, right? Like, so, where's the pipe the smallest is kind of what I'm thinking of, just because I think of everything as systems and, you know, flow like that. I don't know if there is a magical number kind of like we brought up, and I'm wondering if it's more of that pipe situation, because, yeah, kind of like we've said, well, does it make sense to have a team of 1?\n\nWell, if you've only got enough work for 1 person, it's a team of 1. That's your pipe. And, you know, if you don't have a manager, do you go past 3 people? Do you have, you know, the ability? Do you have the pipe to actually function as a team if you don't have somebody managing that fourth individual, or whatever you want to call it, to kind of scale that up [inaudible 52:44]? \n\nDAVE: I think also it has to do with your organizational, like, you can have a team of 2 that aren't really a team because you're all just doing the same amount of work, right? The same kind of work. This is a weird quote out of nowhere, but General Schwarzkopf from Operation Desert Storm in 1991 said in the battles in Kuwait, they very quickly learned that the Kuwaitis were not capable of, how did he put it, they were not capable of putting together an attack above the brigade level. And that's very much a team organizational statement, right? And they were able to capitalize on that in that particular venue. \n\nAnd I think about that in terms of team organization, right? Like, if you've just got 2 people, you don't have a brigade, right? And if you've got silos of 5-person teams in a 50-person team, you can't put together an attack above the brigade level, right? You're going to have that same problem. \n\nMIKE: We could probably dig into cross-team communication, which is one of the most challenging things, if not the most, that we deal with. I think that came up...it was either in the pre-call or earlier because it is a huge challenge to deal with cross-team communication. \n\nBut I think that we've covered our topic pretty thoroughly. We've talked about some of these physics of scale, right? That once you get things bigger, the rules quit working, right? It quits applying. And that there's kind of a sweet spot, you know, the Goldilocks zone of somewhere around half of 10 [chuckles] that works really well and allows teams to collaborate well together. \n\nDAVE: I like that our podcast is kind of a, well, here's the thing, and it's like, we're going talk about this, but there's all these adjacencies to it that affect and almost sometimes even govern, right? Because they become a dominant term. \n\nMIKE: Well, we have to put maybe a pin in that one and come back to it later and talk about cross-team communication because, again, that is a challenge in [chuckles] our industry, probably not just in our industry, but universally crossing those boundaries without maybe literally killing each other [laughs] and making that work. But for here, we've kind of talked about the team size. Is there any final words people want to get out there before we end this? \n\nWILL: I just want to apologize to all the managers that David threw under the bus. \n\n[laughter]\n\nDAVE: Yeah. They've got plenty of company under there. It's, yeah, it's...My mouth tastes like feet all the time, so... But --\n\nEDDY: I would just make sure that you add a comment out loud to whoever edits and says, “Please leave my apology.” [laughter]\n\nDAVE: Yes, please...so, I heard a great definition. The definition of a friend is somebody who listens to your BS, and then calls you on your BS, and then keeps listening to your BS. So, any time that you hear me dragging somebody, I swear to God, I'm not dragging them. Like, you'll know if I'm angry. And this is just me being happy, and sometimes stuff goes weird. \n\nAnd yeah, I apologize if I'm dragging somebody inappropriately. I hope I dragged them appropriately; that's a very different thing. Because I'm going to go right back to listening to their BS because there's nobody that I want to get rid of, you know, so...some people I'd like to adjust. But I'm sure they'd like to see me pipe down and adjust as well. So, it's fair. \n\nMIKE: [chuckles] Well, thank you, it's been a great discussion. \n\nDAVE: Thank you…\n\nMIKE: Until next time on the Acima Development Podcast.","content_html":"In this episode of the Acima Development Podcast, the panel, led by Mike, explores the concept of team sizes and how scaling impacts management and functionality. Using an analogy from the film Honey, I Shrunk the Kids, Mike highlights how physics, like management strategies, change with scale. The group discusses how larger teams can't be managed in the same way as smaller teams and why losing a team member in a small team is more critical than in a large one. The discussion then shifts to defining the role and purpose of a team within an organization, and how the size of the team depends on its function, specialization, and the applications they support.
\n\nAs the conversation evolves, the participants debate the ideal team size, suggesting that teams larger than 10 people become difficult to manage effectively. Justin and Matt argue that team dynamics, including the experience levels of team members and the distribution of leadership responsibilities, play a crucial role in determining the optimal team size. They emphasize the importance of having a blend of senior and junior members for long-term sustainability and organizational growth. The idea of "seed corn" is introduced, highlighting the importance of nurturing junior members to eventually fill senior roles.
\n\nThe panel also touches on the downsides of excessively moving team members around, which can harm team cohesion, yet acknowledges the benefits of cross-training and preventing silos from forming. Will and Dave provide examples of how large teams can succeed with strong leadership and effective management, but caution that poor management can lead to inefficiency. The episode concludes with a discussion on how cross-team communication is one of the biggest challenges in scaling and maintaining effectiveness, with the panel agreeing that the sweet spot for team size lies between 6 to 10 members.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. We have a great panel here today, a large group. We've got Matt, Eddy, Will, Ramses, Justin, Dave, and Kyle all here with us. We're going to talk about team sizes. There’s kind of a carryover from a couple of weeks ago. We talked about other items of scale. But we're going to talk about team sizes.
\n\nI'm going to start by talking about the movie, “Honey, I Shrunk the Kids.” People of a certain generation watched that movie [laughs], and it's not the only one like it. You know, there's a history of movies where people shrink. There's Marvel movies, you know, people go really small and really big. And, in those movies, generally, all the laws of physics are basically exactly the same as they are when you're larger and people are smaller, and that's it [laughs]. Everything works exactly the same.
\n\nOne thing that kind of blew my mind when I ran into it is not even remotely true. And you can see it by looking at ants. Like, in that movie, the ants are big, and everything's fine. All the physics work totally normal. If you look at an actual ant, when they get hit by water, it is fundamentally different than what we experience water as, as humans. Because even just at that difference of scale, water is like glue. If you look at an ant when it gets in water, it is like, you know, it touches that drop of water, that ant is stuck, and it is a huge effort to get extricated, you know, it's like running into a giant pile of tar. Because you go down in scale, it fundamentally changes the nature of physics.
\n\nYou know, you can see an ant. It's very visible that, even at that scale, our physics are different. Water does not behave in the same way at all as it behaves for something larger scale. It's just different. And, you know, and you look at a microscope. It gets even crazier. I mean, you can see in a microscope with a Brownian motion, where you get small enough, and you see things just kind of randomly moving around because of quantum-type effects. And you have molecules bouncing around; stuff is just going to generally float in a way that we just don't experience at our scale.
\n\nAnd it breaks our intuition because our intuition is built on the scale that we normally work with. But even something you can see, and you can look at an ant, it's different. The physics are totally different for something as simple as water, you know, droplets of water, when you go down to that size. I say this is relevant because there's a lot of things like that, where scale changes things.
\n\nWe're going to talk about team size today. And I'd argue pretty strongly that you can't just take a team of two people and manage it the same way when you've got 100 people [laughter], and maybe you can try. I hear laughter [chuckles]. It's different when you scale up in size. I had this conversation recently, thinking about different company sizes. If you've got an engineering team of 1000, the way that you can run that is totally different than even at 100, you know, you go a factor of 10, and that's very different. Then you take 100 versus 10 it's totally different. If you've got 10 people in your department and you lose somebody, that is a critical loss [laughs].
\n\nIf you've got a team of 1000, well, you're probably losing somebody every week, and that's probably fine because you've got your systems built up to handle that. Now, on individual teams, we have a variety of team sizes, you know, beyond just department sizes, and those scales matter. This [inaudible 03:47] in a lot of ways. So, I've been talking for a bit talking about how scale matters to kind of launch the conversation. Based on that, I'm going to ask the pointed question that prompts the debate. I mean, how big should a team size be, knowing that different scales matter?
\n\nWILL: I would first ask the question of like...And I don't think this is a singular answer, but what is the role of a team in your organization? Why a team? Like, what's the role that the team is organized around doing stuff? It's a functional group, right? Sometimes people have sort of like, okay, this is a functional group, like, this is my DevOps team, and it serves this function. Sometimes it's sort of like a...I call it an administrative unit, where it's like we have interfaces with the bureaucracy, either through product, you know, leadership, or just sort of administrative management stuff. Sometimes they're areas of specialization within the codebase. They could all be different things. So, how big it is is maybe directly dependent on that.
\n\nSo, let's say you have...DevOps, I think, is a good example. So, if you have a small DevOps team, maybe you only have two, you know, DevOps engineers. Then the right size is two, you know? If you have maybe six DevOps engineers, where, like, does two teams of three really make sense? Maybe it doesn't. And so, then you'd have a team of six, which could be a little heavy for a software development team, right? A team of six engineers is starting to get kind of big. And so, the size of it is definitely going to be informed by the functions of the team.
\n\nMATT: Yeah, I think there's some questions that you have to ask yourself. How big is the application they're going to be supporting? Are they supporting multiple applications or services? Can those things be broken into domains? Do we have teams that support specific domains, or do they just umbrella and support everything? I think if you can answer some of those questions, it makes it a lot easier to determine what that team size should look like.
\n\nJUSTIN: I would suggest that there's a maximum team size that exists that you don't want to go larger than X, no matter what application you're supporting. Because it suddenly becomes a case of people don't know what other people are working on. It becomes hard to coordinate. There's not interconnectedness. All the manager is doing is managing people and losing technical insights. So, yeah, I think there may be an upper limit there that you can't cross.
\n\nMATT: Totally agree. Another thing that you need to think about is, are we talking team size from an HR management perspective so for, like, an engineering manager, or are we talking about teams from a team lead perspective? Because you may have 10 engineers that are technically part of the same team but broken into, say, sub-teams because we have a lead to support those engineers, right? So, they can work on different things, have a different person leading projects instead of the manager trying to lead all of them at the same time on multiple projects.
\n\nWILL: Justin, I saw your face, Justin. You're like, no, no, no. No, that's two different teams. You just got two different teams in the same bucket, you know what I mean? It's like a duplex. We don't live together. We just live in the same building, you know [laughter].
\n\nMATT: So, semantics are important.
\n\nWILL: But I am really interested in sort of what Justin brought up, which is like, okay, you're right; there's a ceiling for team size. Is it determined by a bunch of really specific things, right? You can't say, like, “No more than 10,” although that's a pretty good limit, you know [laughter]?
\n\nJUSTIN: I agree.
\n\nWILL: But how do I know, like, okay, like, you got to split it up; you got to split the team up; this is not working anymore? And then, like, more of, like, things that you'll see happening rather than, you know, a number.
\n\nMATT: Yeah, what if...let's say six people is this example team size. What if all six of those people are all subject matter experts and senior-level people versus a team of six people that has one subject matter expert and senior-level person and five entry-level or junior-level engineers? I think then that changes things. That dynamic is different.
\n\nWILL: Well, you may actually just want to spread them around [laughs].
\n\nJUSTIN: Yeah, exactly. That's not using your resources correctly.
\n\nMATT: Well, it may be the case that those are the only resources we have. So, do you keep them together, or do you split it into two teams of three and have a junior engineer as your lead for one of those teams? I mean, those are the kind of questions we need to think about.
\n\nJUSTIN: I think maybe a better way to look at this is like, what ingredients do you need in a team? You need probably at least one senior person or a tech lead. What else do you need?
\n\nEDDY: You need a junior on your team [laughter].
\n\nWILL: Maybe. Maybe.
\n\nMIKE: Yes, you do. I made this argument emphatically sometime in the last week or two. If you don't have a junior developer, what I said is that you're eating your seed corn. Because if you don't have somebody growing in experience to become the next subject matter expert, then your senior engineers, when they move on, leave a hole that you are not going to be able to fill. I think you absolutely need, if not a junior, you know, somebody who is learning the ropes and growing into that position.
\n\nDAVE: It's almost like a long-term, short-term sustainability, right? Because I mean, you can have a small, tightly focused tiger team that goes in, takes care of the business, and gets out, but that's not a long-term sustainable...right? That's like a task function. And you don't need a junior for that. That's fine. You can have an operating theater full of brain surgeons, but if you want long-term sustainability, you need to view...
\n\nI think we talked about this a long time ago, Mike, that when you give a programmer a problem, we don't take problem in and solution out. You actually take a problem and a programmer in, and what you get out is a solution and a smarter programmer. And if you start viewing it that way, as, you know, you are part of the output of this unit, you do, you need new people to step up because someday you're going to be gone, and that team will be gone if you weren't eating your seed corn, yeah.
\n\nMATT: Teach a man to fish, give a man a fish, right?
\n\nDAVE: Yeah, light a man on fire, you keep him warm for the rest of his life, yeah [laughter].
\n\nWILL: You know, I don't know; I mean, on one hand, I get what you're saying. But, I mean, one of my persistently more controversial software management beliefs is that we should be moving people around a lot more. So, this sort of like, you know what I mean, this thing you said where it's like, it's bad to have task-oriented teams. Like, I love task-oriented teams. I love getting together a team to do the thing, and then they go away. Dude, I like it because by enforcing that sort of procedural process discipline, you don't let people put together the little fiefdoms, and you don't let people evade accountability for corners that they may have cut, you know what I mean?
\n\nLike, you make sure that people are cross-trained around stuff, and you can have little domain expertise areas of stuff that's going on there. But I find that one of the real sort of long-term rots that gets into a software engineering organization is people get into their little...they carve out a comfortable little niche, and then they just sort of sit there. And they don't necessarily, I don't know, I hate to use the word rot, but there's definitely a lower level of operational intensity once you really have your little flow within the organization.
\n\nMIKE: They talk a lot about silos. They talk a lot about silos, right? And you know what a silo is for? Sometimes people think, who are unfamiliar with farming, that a silo is for storing grain, and that's not true. A silo is for storing wet grain so that it will rot. The purpose of it is to ferment it because that's a different way of preserving it.
\n\nDAVE: Oh wow.
\n\nMIKE: So, you take, like, green corn, and you throw the whole thing in, or you maybe throw your corn in there. But yeah, silo is different from a grain elevator. A grain elevator to keep dry. A silo is for keeping wet so that it will ferment so you can feed that fermented food to the animals.
\n\nDAVE: I didn’t know that.
\n\nMIKE: And [laughs] it's a great image because once you build a silo, it's going to ferment [chuckles]. And we talk about silos a lot. I don't know that we always think about the implications of that, that when you silo something off, that's going to start to go rotten by design.
\n\n[laughter]
\n\nDAVE: Can I offer a counterargument to both of those ideas, though? I agree with both of what you said, 100%, but it's not something to be taken completely without a qualification. There's a...oh, I'm blanking on the author. There's a book called “The One Thing You Need to Know.” And it's a book on basically what makes people happy at work. And, basically, they interviewed a bunch of people and say, “How happy are you at work and how are...?” And then, they started looking for clusters of things that were true, you know, random things that happened to be true about these people.
\n\nAnd the number one non-trackable business, there's no KPR spreadsheet for this, the happiest people all had a best friend at work, which I thought was really, really interesting. And I'm a naturally gregarious, very loud person. And when I read that, I'm like, I need to double down and start making actual friends at work, and I did that. When I was at CoverMyMeds, I did this. And they had a transition. They got acquired, and they brought in some senior management whose job was just to fluff the grain and just screw everybody up just to prove that we'd been acquired.
\n\nAnd we had a manager who the very first thing he wanted to do was separate everyone, so he just took all the teams and just sliced them up. So, you were on teams with complete strangers. And I think he had the idea of cross-pollinating, right? But if you take, and I'm going to mix my metaphors badly, if you take your sourdough starter and you spread it so thin that you kill the culture, it's not sourdough anymore. You haven't spread the culture or homogenized it. You've just wrecked it and ruined it.
\n\nAnd it broke me because I went to the next team we were on. I started forming friendships. We got really, really close. And they did it again. And the third time through, I'm like, I think you guys are actively trying to demoralize us. Because they were cutting us off, like, every three months. There was no chance to form any kind of a personal relationship with people. So, I suggest that as a counterpoint. I 100% agree that the professional objectives, absolutely, they should be changed, or you get bored.
\n\nMIKE: So, I talked about the silos because that's what silos do, but I actually was going to push back some as well. Have any of you read “Team Topologies?” I'm seeing a couple of nods here. It's a book worth reading. One of the things it says is that teams become more effective over time because it takes a while to learn to work with each other.
\n\nSo, there's two kind of competing principles here. One of them is that if you’re isolated from everybody else, you tend to become very insular, and stale, stagnant, right? The other is that teams that have worked together know how each other work, and they're just going to work better. In general, a long-running team is a more effective team. And so, an effective approach needs to somehow combine those.
\n\nThe idea of sub-teams got brought up. I don't know that sub-teams...they may just be separate teams. But one thing that can happen is, on a team, you can have rotating assignments, such that you still have a...you have a persistent team that takes on different kinds of work, and you may have different groupings within that team also. But you still have strong cohesion because you have your group of six, or whatever it is. You know each other, [inaudible 16:49] each other really well.
\n\nYou may be grouped together on different projects, and you may be bringing in projects that are very different than the ones you did. Having a team work on different projects can help break the silos without necessarily disrupting the team for no reason. And I think that disrupting a team just to reorganize is a really bad idea.
\n\nWILL: You know what? Any virtue taken in excess is vice, right? You can screw it up in both directions, right? But, like, persistently, what I would say, like, the cancer eating away at software organizations, there's two things, cross-collaboration among engineering teams and organizations is just a bag of hurt. It's sucked everywhere, and some people suck more; some people suck less. But it is the number one bogeyman of everybody, everywhere, all the time, forever. Like, I've never seen an exception to this, and second only to crappy managers.
\n\nAnd those are two things that must be hunted down and eliminated constantly and mercilessly. And it's just sort of like, if you're not stirring the pot, those two things are going to creep in. It's a constant bailing out of water to keep those two things from sinking you. It's inevitable, you know; you have to have an answer to it.
\n\nAnd I think moving people around, you know what I mean, like, I agree, you can do it too much. But moving people around has a lot of really strong positive effects in letting your organization thrive, you know what I mean? It's like, oh man, this manager is always getting it done. But like, oh man, everybody hates working with this guy. Like, oh man, this junior engineer is really good. We don't have a senior seat for him, but like, man, he's really ready to go, ready to move up.
\n\nOr, like, oh man, this senior engineer has kind of lost the plot. And they're smart, but they're just not working well with people. Like, all of these things are stories that I'm sure a name popped up into each and every one of you guys’ heads as I was saying each and every one of these things. And if you're stirring the pot, if you're rotating through, if you're giving people opportunities to do good or to do bad, then that kind of stuff is going to surface itself, and you could do something about it.
\n\nMIKE: Do you know all of these people, that is --
\n\nWILL: Every last one of them. Every last one of them.
\n\nMIKE: My question is, do you personally know these people within the broader organization today? And if so, that means that you're not talking about moving somebody somewhere where they don't know anybody. You're talking about a subunit of the company that's cohesive enough that you actually know all these people.
\n\nWILL: It would be stupid to just drop somebody, just airdrop somebody in by a parachute in some situation where they could do no...you know what I mean? I mean, I'm not dumb. I understand that you can't just be like, “Hey, you're doing Haskell today.” Like, yeah, yeah [laughter], you're DevOps this quarter. Get to work.” You know [chuckles], that's not how it works.
\n\nDAVE: I've seen it work, and I've also seen it fail spectacularly, where we had a system recently where we swapped an engineer out to help another team. And that other team's process was very, very different, and it was very rigid. And they were under the gun. They could not stop and say, “We need you to do this, do this. Everything you're doing, we need you to do it sideways because we will do layer cake instead of,” whatever, that kind of thing. At the same time --
\n\nWILL: Oh, you have a bad manager. What a wonderful thing to know about.
\n\nDAVE: Right? And I understood, like, why. Like, all the intentions were good, right? It's like we had a problem. We need to throw more bodies at it, right? Conversely, when I was at CMM, and they were still a unicorn, we came up with a thing that...I called it hostage exchange program, where we would go to your team and say, “Give us a developer. We'll give you one. You give us one.”
\n\nAnd so, we would swap with another team, like, all the way across the building, completely different project, different vertical of the company, different profit centers. And we would swap out one person for two weeks. And very importantly, it was seed corn. It was, we're here to cross-pollinate you, to make friends, and show you how we work. We are not here to sweat you and try to get you to scream everything over the line. Because when you go to a new thing, you're going to be useless, right? But after the exchange, because we had one of yours, you had one of ours.
\n\nAnd then when you swap back, this amazing thing happens because it's like, “Oh, man, we need to cycle the pods on the Jenkins thing. And how are we going to do that?” I don't know. That team doesn't like to talk to us. And the one guy who was in hostage exchange goes, “Oh, hang on. I'll just ask Justin,” right? And all of a sudden, there's a personal relationship formed. And that was like, if you forgot everything you learned while you were on that team and you just remembered who you met, it's a victory, hands down.
\n\nWILL: Exactly. No, absolutely.
\n\nEDDY: Or better yet, Dave, you can just be like, “Oh, I've done that before. Let me go [laughs] and do it.”
\n\nDAVE: Yeah, yeah, hands down. Mike, we were talking about this on the team the day we had a deploy issue. And we have this really convenient, for those people listening out there, we have a really convenient way of deploying. There's a little thing that we click, and we get a notification that says, “If you want to deploy this, click here to deploy it,” and it's great. And you don't have to go into Jenkins and fiddle with the drop boxes and find your image and all that stuff. And I kind of forgot how to do it manually.
\n\nAnd so, we had an incident last week where we were like, you need to roll this back. And it wasn't me, thank goodness. But I'm just kind of on the sideline eating popcorn going, you know, if that had been me, I would have been stuck because I have forgotten how to do it the hard way. And I’m like, we need to get the team together, and we need to review how to do it the hard way. So, like you said, so if something happens, you don't have to call somebody who knows how to do it. Just, like, everyone is just like, “Oh, wait a minute, I know this.” And if you've got a process to document, you're like, I know where to look for it in the wiki, and then all my notes will be there, and yeah.
\n\nWILL: Absolutely. At the large retailer that I work for, you know, they have an unofficial tradition, 52 [inaudible 23:14] pickup, Q1 of every year, where they just, like, completely demolish the org chart, and it's anarchy. And I don't think they do it on any kind of, like, high-minded management, you know, theory principles. They just do it.
\n\nBut one of the nice things, like, having been here for a couple of years and gone through several purges, is I've got people all over the company. Anything I need done, like, I've got a person. I’m like, oh, I'll take Dave, or I'll take Reed, or I'll take Max, or I'll take whoever. And I have somebody to ask to get a thing done, and it makes me really effective.
\n\nDAVE: There are people in your organization who will try to shut that down, thinking they're doing a good thing because once a team starts...like, when IT starts getting overloaded, they start saying, “We need everyone to fill out a ticket on Jira because we can't manage our workload,” right? And if you know somebody and you pick up and you...I'm just going to call Corey. He'll take care of this for me. And, like, Corey has to say, “I need you to fill out a ticket, man.” But you don't have to kill either of those, right? You can still do the, “Hey, I need this,” and your friend in IT can go, “Oh yeah, just check the PRAM, just reboot it, do the thing, you know.” “Oh yeah, I remember that.”
\n\nAnd then if it's going to be more, it's like, you know what? You're right. That's serious. Fill out a ticket, and I'll jump on it. So, you can still get the best of both worlds, but you can have people that are simple-minded of, like, just do it this way. And like you said, a virtue taken to an extreme can turn into a vice.
\n\nMIKE: So, we've talked a lot about swapping people around and getting them into different experiences. And I heard a couple of numbers thrown out. Somebody said 10. Oh, you shouldn't have more than 10. Somebody said 6. There may not be a clear line there. But what is that number X? And maybe, more importantly, why is there a maximum team size? Why does it stop working?
\n\nDAVE: In the pre-call, Mike, you posted a link to Dunbar's number on the wiki. Real quickly, for people listening, the size of the frontal cortex of a primate's brain determines how many meaningful relationships that primate can have at any one time in their life, and, for humans, it's about 150. I wanted to throw that one out there because I recently learned of another one called optimal tribe or optimal primal group...I don't know if it has a clear name, but the way they calculate it is fantastic. Anthropologists have determined that when you have this tribe of, like, 150 people, you're spread out over the valley, and you actually have subgroups within it.
\n\nYou might be in a group of, like, 500 people, but you're spread out over about...150 of those are your relationships. But the people that you rub shoulders with every single day of your life is more like 30 to 35. And this number self-balances because among humans, somewhere between 30 and 35, the murder rate balances the birth rate. I love that number, that it's, literally, I will kill you if you add one more person to this team is how we dealt with this 10,000 years ago, and I think that's fantastic. I think it's brilliant.
\n\n[laughter]
\n\nJUSTIN: So, I don't want to be on David's team [laughter].
\n\nDAVE: Yeah, because we've got 34 right now.
\n\nWILL: I don't think we're going to see deaths necessarily.
\n\nDAVE: No, no, no, not where you can see ‘em.
\n\nMIKE: [laughs]
\n\nWILL: I think what you do see is you run into the bureaucracy associated with creating and processing and assigning work, you know what I mean, like, breaks down. That's what happens. You can't effectively utilize your people because you have this sort of, like, feast or famine, these wild swings and the amount of work you've got to do. Like, I'm getting ready. I'm warming up for a giant work hangover next week because we've got a big thing we're shipping out.
\n\nAnd all of our leadership management capacity has been dedicated to getting this thing over the line. And it's a big fella, so I forgive them. But we're going to have a giant night hangover, where there's just nothing in the pipeline, and then they're like, “Oh, uh, do this.” So, that's where you break down, like, the ability to assign and manage and, like, hey, provide feedback. All that stuff it breaks down. You just can't [inaudible 27:44]
\n\nJUSTIN: So, can you have a larger team if you have people helping lead it? And by this I mean you have project managers who are tracking the projects that are out there. You have your tech lead. You have your engineering manager. So, how does that all fit together? And then, you actually have the people doing the work of which, hopefully, your tech lead is one. And then, you got the other, you know, senior, regular, and junior engineers.
\n\nWILL: I think there's a finite amount of leadership and, like, I don't know, man. I mean, sometimes that's the project managers. Sometimes that's them but not all that often.
\n\nMIKE: If you have really good leadership of the kind you describe in sufficient quantity, I think you can push above maybe that 10 limit. Maybe you can get close to 15, pushing 20, but it is continuous work. And those leaders are going to be just incredibly busy. I mean, that's going to take a finely oiled machine, and it's really hard to replicate. They talk about this in “Team Topologies,” yeah, you can maybe go over 10. And you might be able to pull it off for a while, but if anything goes wrong, the whole thing falls apart.
\n\nJUSTIN: Wasn't it the two-pizza rule? You can only have a team that you can use two pizzas to feed. That’s your team limit.
\n\nDAVE: That's right. So, 200 people if we really sweat them and give them the [inaudible 29:11]
\n\nEDDY: What if I eat a whole pizza, Justin? Like that’s -- [laughs]
\n\nDAVE: Then the other nine people split the other one, yeah [laughter].
\n\nMIKE: When I was in high school, I was running cross country and growing like a weed. I could down two extra-large pizzas myself [laughs].
\n\nDAVE: I grew up in Ranch Country, and there was a phrase that people would say that, “I have teenage boys. I'd rather clothe them than feed them [laughter] because it's cheaper.” So, the number with the group size, the thing that they found out of this was...because humans, we've obviously gone past the point where we can be around 35 people without committing a murder. And they see anthropologically, in the records from about 15 to 10,000 years ago, three things started happening. We started dancing. We started singing, and we started worshiping together as groups.
\n\nAnd what this does is it gives you the ability to walk into a room and meet a stranger, you know, stranger danger, we're afraid. Like, you know, primates, we're just like, [vocalization], you know, do I need to worry about you? But we've got this thing that we're all looking at, and I’m like, oh, wait a minute, we're all here to worship at the same time. Or here, we're all here to sing and dance and experience this pleasant experience in a safe environment. I can call you my tribe. I can call you my friend. And from there, we then get scaled all the way up to, you know, patriotism for a country.
\n\nI used to hate, hate with a passion, town hall meetings where the CEO comes down and tells you about the corporate vision. And now I realize it's absolutely essential. You can have 25 people on a team if you all are looking...like, the interpersonal team communication is going to go exponential, right? It's a triangle number like n times n plus 1 divided by 2, something like that.
\n\nThe links between the number of nodes goes up exponentially, and that will fry and become exponentially difficult to manage. But for a short time, you can exceed that number if all of you are looking in the same direction, if you're trying to pursue, you know, common gods, common goals, common enemies, that sort of thing. You're like, okay, yeah, I can pick up and pull in the traces next to you without knowing your life story.
\n\nWILL: You must be going to different town hall meetings than I am.
\n\nMIKE: [laughs]
\n\nDAVE: I am a different person in town hall meetings than I was two years ago. And I would say I'm going to different town hall meetings than I was two years ago. And, yes, I've been at Acima for more than two years. So, what I'm saying is I have changed, and the experience of the meetings is different now, yeah.
\n\nWILL: I actually see most of the corporate town hall meetings that I have witnessed are actually like a case study in, like, this isn't working anymore. This is no longer anything. Because my experience with the meetings has been, typically, that we're not on the same team, like, anymore, like, the C-level executive that I'm meeting and me as like a, you know, a skilled worker, certainly, and somebody who's like, you know, I punch above my weight in terms of impact. But we can't have an honest conversation. They're not doing that with me anymore.
\n\nI am a resource to be managed and not really dealt with forthrightly. It's too big. We're too far away. Our interests have also rather sharply diverged. And so, there's a lot of, like, I don't know, man. They're lying, and they know they're lying. I know they're lying. We're all sort of like going through this theatrical display, you know what I mean?
\n\nDAVE: 100%. 100%.
\n\nWILL: I'm just like, all right, guys. We're not that. We're not that. We're not on the same tribe anymore. Don't put my face in it, okay? Like, I could listen to the investor call if I want to know what you're doing to justify your share price. If we need to do that, that's okay.
\n\nDAVE: The corollary that I take from that is that there's times when I sit in church, and I'm like, we are all here to do the same thing. And then, there's times when I remember a...my dad had nothing to do with church or religion for most of his life. And it was because he would sit, and his experience was, you'll shake my hand on Sunday and stab me in the back on Monday.
\n\nAnd if you've ever had that experience of sitting in church-going, you SOBs are all miserable jerks, and not one of you believes in what we're doing, that's a horrible town hall to be in, right? It's like, oh, yeah, yeah, you're not trying to incentivize us. You're trying to sucker us into doing work now in exchange for a promise for something you're never going to deliver, right? When there's no faith in that, it's brutal, right? It's the opposite of it.
\n\nWILL: Well, I mean, I don't have a problem with working for Corporate America. It's fine. I'm not some guy who's [inaudible 34:02] is communist, you know what I mean? Let's all get paid. Let's all make really cool stuff for our customers and delight them. And then, they will give, you know, us some of our money, and then I will get my piece of that. You'll get your piece of that. We're all going to be good. But that's not a forthright conversation that we're having.
\n\nDAVE: No, it's not.
\n\nWILL: It's like big meetings, right? Big meetings, big companies. Like, it just gets so big that you're not really...the gap's too wide.
\n\nMIKE: Well, we're talking, I mean, this is germane to the conversation because we're talking about ways to maintain group cohesion. And you're saying, as you get large, you get to town hall size, it is really hard, that getting everybody on the same page and making them happy about it may just utterly fail. So, if those tactics are challenging with a large group, it says something about the team size, right? And if you look at hierarchy of organizations, there usually is a hierarchy.
\n\nWILL: Sure.
\n\nMIKE: And at any level of the hierarchy, you have, you know, probably that six to, you know, 12 or something people at that level so that everybody is within a similarly sized team because it's really hard. It's really, really hard when you try to scale that up.
\n\nJUSTIN: So, going back to your talk, I mean, your chat about, you know, getting everybody aligned in the same direction, I can't help but think about the example of Twitter, X. And say what you will about Elon Musk. He forced his way to everybody be in the same direction, and I am very curious to know what impact that had on their team sizes. Because I'm like [laughs], did they...
\n\nEDDY: Correct me if I'm wrong; it might be inflated, but I think over half of the team left when he forced his way.
\n\nJUSTIN: I think so.
\n\nWILL: 70%, yeah.
\n\nEDDY: It was quite significant.
\n\nJUSTIN: And so, do they have smaller teams, or do they have larger teams with fewer managers? I bet that's what happened. My theory is that Musk got rid of most of the middle management, and they have the engineers left who are interested in working for Musk and are probably well-compensated as well.
\n\nWILL: [laughs]
\n\nJUSTIN: And so, they're all aligned somehow. But, I don't know, that is going to be an interesting case study in some future, you know, business school or engineering school.
\n\nWILL: I’d imagine you're right. I’d bet you any sum of money the team sizes are larger. And I think probably you got a lot of people on a visa who aren't empowered to just go anywhere. And I think they're probably making less money and working harder, and maybe just didn't have the option to hop over to Amazon, or Microsoft, or Google, or whatever. We'll see. We'll see.
\n\nI think there are a lot of people who are leveraging tech winter right now. And whether that remains to be a sustainable management practice or not is going to be told, you know, when tech starts to boom again because nobody got off their phones, man.
\n\nMIKE: [laughs]
\n\nWILL: And then, the market for talent becomes a little more competitive. I think there's a lot of people who, you know, it's your way in this, like, rather sharp and prolonged economic downturn for our slice of the economy but long term, I don't know, man. I don't know. Is it good management? We'll see, you know. Sorry, that's a little bit of a tangent, I think.
\n\nMIKE: Yeah, no, it still comes down to, you know, how do you work with the group? How do you keep the group cohesive, and the challenges with that? So, is 10 a reasonable cap? Like, if you got a team bigger than ten, you better look at cutting it?
\n\nJUSTIN: I don't think I've ever been on a team that large. I think the most I've been on is...well, I guess it depends on how you define it because I've been on front-end teams where we have the product owner and then the designer. And then, I was a full-stack engineer, so I helped the frontend and the backend, and the database [laughs], but there were also people on each of those. And so, I guess we were, you know, if you include the designer and maybe a database guy, I don't know, it's like, you know, hey, we're together for a project. But I don't think it ever got up to 10 in our standups. I think the max number of people in our standup was, like, seven or eight.
\n\nDAVE: I'm hesitant to say a number. I worked at Evans & Sutherland around the turn of the millennium, and I was on a team of 50, 25 software engineers, 25 hardware engineers. Basically, we'd come up with the same idea that NVIDIA had, that you could do 3D in hardware and do it very, very fast. You could do stuff in real time that couldn't be done at that point, and, it worked really, really well.
\n\nThe 25 people, the status meetings got [inaudible 39:00], but those went on and on and on and on, right? It took forever to get through the status stuff. And, yeah, subdivided, and, like, I was literally...my sub-team was in the middle of a cube farm, but, like, my job was 2D-bit blit block image transfer. My job was to move rectangles from one place in memory to another. And there was somebody else whose job was to handle 3D and somebody's for curves. Literally, we had a triangle team, like, literally. But at 25 people, it functioned.
\n\nBut what I will also say is I was on version 3. They had built the entire graphics card for real image 1, real image 2. I was on the Real Image 3,000 team for making version 3. And we also did largely waterfall because there was hardware coming through the pipe that had to be anticipated 18 months in advance. And the rule for waterfall is don't do it unless you've built the exact same thing twice before, which they had. And so, there were a lot of stuff that, you know, that had happened in that.
\n\nWILL: Right now, like, my daily standup has 18 people in it.
\n\nDAVE: How long are your stand-up meetings?
\n\nWILL: 30 minutes.
\n\nDAVE: 30 minutes? That's a status meeting, yeah.
\n\nWILL: Eh, it's okay. Thirty minutes is fine. They're pretty efficient. They tend to go over fairly regularly, but not because of the status meeting being bad, just because we're just getting ready for a big release, so there's a lot of nuts and bolts to make sure everything goes right.
\n\nAnd I would say that the team is functional. And it is really kind of one team, but there's a manager, and then there's sort of an assistant manager. And there are some, you know, pretty senior, you know, sort of shadow management. Like, we have at least three people that could and do act as managers, like de facto managers. And so, it's big, and it works. And it works as, like, a single team, but there's a lot. It isn't just a guy. There's a lot of support.
\n\nMIKE: So, proof. There's an example case of all the support you can push up close to 20 and make it work.
\n\nDAVE: For a while.
\n\nWILL: But there's like, well, yeah, but there's also at least three people who are acting, like, two named and one unnamed people who are doing that job. And if you took any one of them out, the whole system would collapse. And so, you think like, oh, we've got 18 people on one team. But it's like, yeah, but you've got three managers, so that's, like, three six-person teams kind of in one thing. It would be hard to make that a sustainable thing other than just sort of a special case where it's like, if you have the right mix of people, you can make it go.
\n\nDAVE: There's something going on right now where I live and work. And, Eddy, I think, Eddy, you're in Michael's team, right? I think I see you in the standups. Maybe not. I'm on a team of 28. Well, I'm on 4 teams that total 28 people. And shout out to Michael McMullin. I don't know what he's done behind the scenes, but our standups are three minutes long. Like, I'm not kidding. Like, we walk in --
\n\nWILL: Three minutes long?
\n\nDAVE: Yeah, literally just long enough to...is everybody here? Does anybody have any blockers? And, like, we don't even do the here's what I'm working on, and here's what I need to. And part of that is because we have a channel for that. Mike, you'll be happy to hear this. I have made some impassioned pleas against using a Slack channel for standups. And there's times when that has been completely opaque to me. And when I first started, it was very transparent what everybody was working on, and it's back to that.
\n\nI'm back to being able to see what everybody is doing, and because of that, I walk into the meeting prepared to leave the meeting. It's like I kind of know where everybody's at, and we walk in, and then one person will go, “Actually, I’ve got...” and they’ll raise a blocker, and then we'll talk about the blocker for five minutes. I think the longest a meeting has gone is, like, 12 minutes.
\n\nI don't know if Michael has a gypsy woman prisoner in his basement, and she's just forced to hex everybody else and not him. I don't know how he's doing it, but it's amazing. It's very exciting to watch. I love it when something miraculous can happen and I'm like, how does that work? Like, I genuinely don't know. But it works --
\n\nWILL: I mean, I think it’s working by, like, not doing. I haven't been to the meeting. I can't speak to it. I won't do it. But like you said, like, oh, it's a three-minute meeting. I'm like, then why have the meeting?
\n\nDAVE: Well, because sometimes if there's...the reason it was three minutes was there were no blockers that day. Usually, the meeting is like 5, 10, 15, but not half an hour. Like, it’s scheduled for --
\n\nWILL: And how many people are in this meeting? How many people are on it?
\n\nDAVE: 28.
\n\nWILL: 28? Forget it. Like, get rid of the meeting. I’m sorry, like, you're not doing anything. And, I mean, it's great, like, I don't know, if you don't [inaudible 44:21]
\n\nDAVE: Hmm, I disagree.
\n\nWILL: With the daily standup, that’s valid. But why even have it? Why even have it? If you're not going to do it, then don't do it. Figure out another way, and that’s okay.
\n\nDAVE: We could stop having that meeting and see what breaks, and I kind of don't want to because, like I said, it's magic right now. And I genuinely don't understand it. There's a book that I highly recommend called “Read This Before Our Next Meeting.”
\n\nWILL: I have to say the only thing I’ve heard is good is, like, it’s very short. That's the only benefit that I've heard described. And I don’t know how the team runs --
\n\nDAVE: Okay. Okay. Hang on. Cool. Yeah, let me answer the question that you're really asking then, which is, what's going on? There's a book called “Read This Before Our Next Meeting,” where you basically say, “Everyone, this is the objective of the meeting. Come prepared to reach that objective,” and that's the difference. We're not wandering in going, who's doing what, and where are we? We're not looking for a status on anybody. Everybody knows everybody else's status. So, that part of the meeting doesn't need to happen. You're right, that part of the meeting doesn't happen.
\n\nBut we do need to know if anybody's stuck, and we need to dogpile on something to save somebody from something. And if there's an issue, we dogpile on it, and we take care of it. And that's the point of that part of the stand up for us, yeah. So, the status part is being routed through another channel, and that's what saves us 27 minutes. Does that make sense?
\n\nWILL: I like to see people, man, like, I don't know. Like, that’s just me. I like to see people, and I like to look at their faces, and I like to look 'em in the eye and hear their voices and how things are going. And I get a lot out of that. And I don't think software engineering as a discipline is served by having more people typing into screens in isolation, generally speaking.
\n\nJUSTIN: So, Will, I think you bring up a good point, which is part of having a team is creating the culture that, you know, you want to engender within your company. And the act of meeting together and of interacting with each other is how you create that culture. Well, it's one of the aspects of creating that culture, right? Obviously, working with each other, time outside the meeting. But bringing it all in and kind of sharing a joke and doing, you know, interacting in some way, I think, is a great benefit to engendering a sense of teamwork, and so on. And so, that can be hard to do with a larger team. It's a lot easier to do with a smaller team; let me just put it that way.
\n\nWILL: I mean, if you have 28 people in a daily standup, like, I don't know how you could do it differently than Michael McMullin's doing it just because you just can't.
\n\nDAVE: You can't. It would turn into an hour-long status meeting. And to your point, though, we don't socialize. Well, we do. We all show up a couple of minutes early and then we get the water cooler stuff going on. And I don't count that as part of the official meeting, but I probably should because, yeah, there's some socialization that's essential. And it's good because it's cross-team because, like I said, there's 4 teams actually in there. And if you're going into this meeting expressly to socialize, and communicate status between people, and where are your projects, and that sort of thing, you're not going to get 28 people through in 3 minutes. Yeah, absolutely.
\n\nWILL: So, it's like 4 people in sort of a meeting. It's a four-person meeting. Well, I feel like 24 of those people don't need to be there. Like, 24 of those people are not supposed to be in that meeting.
\n\nDAVE: I'm hesitant to change the formula because it's working, and I don't know how [laughter].
\n\nWILL: You’re right. No, no, you're right. You’re right. Like, we agree, right? Like, don't do it, but at the same time, like, you've got four teams. You've got four managers who are supposed to be explicitly doing this job. And you have all these other people, what, holding their hand while they, you know what I mean?
\n\nDAVE: Yeah. See, we just came off of that. We just came off of a representational republic, and it was satan. It was the worst. The representative served as an information killer, as a communication deaddrop. And we had the team not knowing what the rest of the company was doing or why we were working on what we were doing. And our issue is we’re going up to this person and not going out...we finally started routing around them.
\n\nWILL: Oh, so you have a bad manager. What a wonderful thing to know about.
\n\nDAVE: That was said, not I, yeah. So...
\n\nWILL: Like, I don't even know who I'm dragging here, and I have no accountability whatsoever. But it sounds like somebody has a really important job, and they're blowing it.
\n\nDAVE: I won't say how recently before this team. I won't say how recently. I’ll just say that before I commit career suicide.
\n\nMIKE: Well [chuckles], you know, there's some aspects of this. We talked about some things to make a group meeting work, but still, you're talking about four teams, around seven, you know, six or seven. It just keeps on coming to that number. Yeah, you can get up to about six, and then that's it. So, you know, empirically [chuckles], this number keeps on returning [inaudible 49:18]
\n\nWILL: Okay, what's the smallest number? Let's go in the other direction. Wait, actually, no, hang on. We might not have time to get into this. But I am curious, like, where does the team no longer make sense? One person, you're not really a team, right?
\n\nDAVE: I mean, I have arguments with myself, but –-
\n\nWILL: Two people, why are you on your own team? Three people, have we seen a team, like, an effective functional unit with three people? It really becomes like, honestly, more, like, on an org chart level, like, does it make sense to give these people a manager, right? Are there enough workers for me to rationally advocate these people that are on manager? It's almost like can I justify the accounting line item, you know, more than anything else?
\n\nDAVE: I think it comes down to how much of your objective is explicit and static, where, an organization, you need a lot of that. You could have a team of two, just a partnership. And what direction do we want to go in? We don't need a lot of external, right? And now you can go after a goal, and that goal can change and adapt very, very quickly. If it's a much [inaudible 50:23] thing, then changing the goal is a lot more complicated. You've got to synchronize a lot more people.
\n\nWILL: I'm kind of curious to hear from Kyle. As DevOps, you guys are not necessarily always sort of as robustly staffed as, like, software engineers. What's the smallest DevOps team you've been on, like, one or two, two or three, one, just you by yourself? I feel like you feel that more than we necessarily would.
\n\nKYLE: Three was the smallest, and I thought that worked really well. Scaling up from that, there's quite a few DevOps tooling that you run into locking situations. So, I feel like you kind of start to develop sub-teams, which we kind of have as we've grown to 7, 10 people.
\n\nSo, while I'm sitting here listening to you guys talk about all this, I'm just kind of thinking of team size, to me, I was thinking, well, the minimum and the maximum are kind of dependent on the pipe size, and it will depend on what pipe is coming in or what pipe’s coming out, so your work coming in, the channels that you have to get the work out. So, if you've got a build pipeline that backs up, maybe it's only six people, it makes sense. That 7th person is always just twiddling their thumbs because they're never ever actually able to deploy something, right?
\n\nOr, you know, maybe the pipe that's the smallest is the management pipe. The manager over here he can't manage 10 people. He can't manage he, she, it, can't manage eight people, right? Like, so, where's the pipe the smallest is kind of what I'm thinking of, just because I think of everything as systems and, you know, flow like that. I don't know if there is a magical number kind of like we brought up, and I'm wondering if it's more of that pipe situation, because, yeah, kind of like we've said, well, does it make sense to have a team of 1?
\n\nWell, if you've only got enough work for 1 person, it's a team of 1. That's your pipe. And, you know, if you don't have a manager, do you go past 3 people? Do you have, you know, the ability? Do you have the pipe to actually function as a team if you don't have somebody managing that fourth individual, or whatever you want to call it, to kind of scale that up [inaudible 52:44]?
\n\nDAVE: I think also it has to do with your organizational, like, you can have a team of 2 that aren't really a team because you're all just doing the same amount of work, right? The same kind of work. This is a weird quote out of nowhere, but General Schwarzkopf from Operation Desert Storm in 1991 said in the battles in Kuwait, they very quickly learned that the Kuwaitis were not capable of, how did he put it, they were not capable of putting together an attack above the brigade level. And that's very much a team organizational statement, right? And they were able to capitalize on that in that particular venue.
\n\nAnd I think about that in terms of team organization, right? Like, if you've just got 2 people, you don't have a brigade, right? And if you've got silos of 5-person teams in a 50-person team, you can't put together an attack above the brigade level, right? You're going to have that same problem.
\n\nMIKE: We could probably dig into cross-team communication, which is one of the most challenging things, if not the most, that we deal with. I think that came up...it was either in the pre-call or earlier because it is a huge challenge to deal with cross-team communication.
\n\nBut I think that we've covered our topic pretty thoroughly. We've talked about some of these physics of scale, right? That once you get things bigger, the rules quit working, right? It quits applying. And that there's kind of a sweet spot, you know, the Goldilocks zone of somewhere around half of 10 [chuckles] that works really well and allows teams to collaborate well together.
\n\nDAVE: I like that our podcast is kind of a, well, here's the thing, and it's like, we're going talk about this, but there's all these adjacencies to it that affect and almost sometimes even govern, right? Because they become a dominant term.
\n\nMIKE: Well, we have to put maybe a pin in that one and come back to it later and talk about cross-team communication because, again, that is a challenge in [chuckles] our industry, probably not just in our industry, but universally crossing those boundaries without maybe literally killing each other [laughs] and making that work. But for here, we've kind of talked about the team size. Is there any final words people want to get out there before we end this?
\n\nWILL: I just want to apologize to all the managers that David threw under the bus.
\n\n[laughter]
\n\nDAVE: Yeah. They've got plenty of company under there. It's, yeah, it's...My mouth tastes like feet all the time, so... But --
\n\nEDDY: I would just make sure that you add a comment out loud to whoever edits and says, “Please leave my apology.” [laughter]
\n\nDAVE: Yes, please...so, I heard a great definition. The definition of a friend is somebody who listens to your BS, and then calls you on your BS, and then keeps listening to your BS. So, any time that you hear me dragging somebody, I swear to God, I'm not dragging them. Like, you'll know if I'm angry. And this is just me being happy, and sometimes stuff goes weird.
\n\nAnd yeah, I apologize if I'm dragging somebody inappropriately. I hope I dragged them appropriately; that's a very different thing. Because I'm going to go right back to listening to their BS because there's nobody that I want to get rid of, you know, so...some people I'd like to adjust. But I'm sure they'd like to see me pipe down and adjust as well. So, it's fair.
\n\nMIKE: [chuckles] Well, thank you, it's been a great discussion.
\n\nDAVE: Thank you…
\n\nMIKE: Until next time on the Acima Development Podcast.
","summary":"","date_published":"2024-10-02T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/cd1eedb7-1603-4d3b-a135-acb2f0d9f974.mp3","mime_type":"audio/mpeg","size_in_bytes":34547599,"duration_in_seconds":3379}]},{"id":"675c8758-3a76-4bb7-b6bc-e89c4c315415","title":"Episode 55: How to Estimate Badly","url":"https://acima-development.fireside.fm/55","content_text":"In this episode of the Acima Developer Podcast, host Dave Brady and the panel, including Mike Challis, Kyle Archer, Eddy Lopez, and Will Archer, delve into a satirical discussion on how to ensure time estimates for software projects go wrong. They explore various humorous yet insightful approaches, such as using aggressive negotiation with engineers, ignoring edge cases, and focusing on points as extrinsic values rather than consistency. The conversation is full of playful examples, with stories from past experiences, all illustrating how poor communication, over-optimistic estimates, and leadership pressure can derail projects.\n\nThe team highlights how over-reliance on tools like Pivotal Tracker or Jira without considering the actual complexity of tasks can lead to skewed results. They also mock the practice of placing value on productivity metrics, like story points, while ignoring the consistency and accuracy of those numbers. Throughout the discussion, the panel pokes fun at the missteps that can occur when management overrides technical teams' decisions, fails to understand project requirements, or implements unrealistic planning methods, using examples from both personal and industry-wide experiences.\n\nTowards the end, the group turns their satire to broader topics like testing practices, infrastructure management, and project launches. They humorously suggest that skipping QA, bolting on security post-launch, and involving high-level executives in day-to-day decisions can lead to even more dysfunction. Ultimately, the conversation serves as a playful critique of common issues in project management and development, with a clear undertone of how these behaviors should be avoided for the sake of successful project outcomes.\n\nTranscript:\n\nDAVE: Hello and welcome to the Acima Developer Podcast. I'm Dave Brady, and I'm hosting today. We've got a good panel today. We've got Mike Challis, Kyle Archer. We've got Eddy Lopez and Will Unverified. I don't think that's your...\n\nWILL: It's Will Archer. \n\nDAVE: It's Archer. Archer? Yeah. Welcome, Will. So, last week, we talked about some structure, and we thought we would carry over, and I think we're going to table that for a week. Today we came up with, actually, it was Will. You came up with a really interesting question phrased in kind of a devil's advocacy. Do you want to phrase that up for us and tee us up?\n\nWILL: Well, so, if I wanted the worst possible time estimate for my project, how could I do it? How could I really screw up my time estimates? \n\nDAVE: I like it. I may or may not have some stories related to this. I'm seeing knowing smiles around the board. Okay, so I'll give two stories really, really quick. And the second one is actually the counter to the first one. \n\nNegotiate aggressively with your subject matter experts in a threatening manner. Specifically, negotiate story points down because you don't want to spend extra time dealing with the problems that your people are thinking of that might be coming down the pipe. And a great way to do it and sound like you're not doing it is to begin every sentence with, \"Why don't you just...?\" \n\nAnd so, you can take something really super-duper complicated...I mean, throwing the ring into Mount Doom that's a one-point story. How long does it take you to drop a piece of jewelry into lava [laughter]? It's super easy, right? Super-duper easy. Why don't you just do that? It's fine. And yeah, it's that kind of thing, right? Where the actual thing, you know, getting to the site to deliver it, you know, OSHA injuries where he gets his finger bitten off, right? That whole thing. \n\nWILL: Take the Eagles, guys! It's [crosstalk 02:00] a one-hour flight. Take the Eagles, duh. \n\nDAVE: Yes.\n\nEDDY: I was going to say, don't you like the idea of having an extra cushion to your points?\n\nDAVE: [inaudible 02:08]\n\nEDDY: Yeah, because if you over-deliver and you get it done, like, two or three weeks ahead of time, the only thing that you get is just applause, right? Like, you got it done earlier. \n\nDAVE: Well, so, I think this is kind of the other way around, right, where it's like dropping this in. We're going to budget two hours for this, which is plenty of time to drop a piece of jewelry into lava. And the project, as we know, is going to end up taking three months from, you know, hindsight. And that's the kind of stuff where...like, engineers often get paid to think about edge cases, and weird things, and, you know, what about this thing, and da da da da da. \n\nAnd very, very smart people who are low in trait openness...openness is one of the big five psychological traits for gauging a personality. People who are low on this are very certain they're the J type on the Myers Briggs. They're judgy, not perceptive. What's in their head, they will press that down on the world around them.\n\nAnd this leader that I worked with would negotiate aggressively, and because he was the CTO, every discussion was an uphill push, so, okay. And we used Pivotal Tracker, and Pivotal didn't care. Tracker doesn't care what you think your velocity is. It will tell you what your velocity is. And because the stories were getting smaller and smaller numbers on them, all of Lord of the Rings became a one-point story, which means it took us three months to deliver one point of value.\n\nMIKE: Wow.\n\nDAVE: And he did not like that. We literally watched Tracker go sub-integer. We had a velocity of 0.2 at one point. And that did not make the CTO happy either because he wanted the points to be big, which might be another evil thing is, like, place extrinsic value on points.\n\nThe counter to it is the second story, which I'll just tell in just one quick sentence. I had a manager who looked at me, and he said, \"I don't care what your velocity is. I don't care what the number is. If it's consistent, I can bank on it.\" If the team velocity is 180, that's great. If it's accurate, I'm going to ship on time, and I'm happy. If the team velocity is 1.8, that's fine. Points don't matter, remember? And if I can bank on you shipping on this day, and I can queue up the next thing, I'm happy.\" So, if you want to mess up your schedule, focus on the points themselves as extrinsic things, and ignore consistency in your estimates. \n\nEDDY: So, Dave, for the people that may not be aware, what's Tracker? Can you give an overview?\n\nDAVE: Pivotal is a company that makes software, and Tracker is their time-tracking thing. It's Jira, or VersionOne, or Rally. These are all competitors. Jira is the really big gorilla kind of taking over the scene. Basically, you do this, deliver it, and then it goes into the backlog, and you put points on it. And then, Tracker gives you your to-do list against a calendar. It's like, no, no, this is your...I've been measuring your velocity. This is how many stories you have. This is when you're going to be done. And after you've been using it for about three or four months, it starts getting spookily accurate. And if you don't like what it says, you can change the numbers to be wrong. \n\nMIKE: I had a couple of stories I was thinking of as you were sharing them [chuckles], but I'm going to go a different way. I mean, we were talking in the pre-call about the first line in Anna Karenina, which is all happy families resemble one another. Every unhappy family is unhappy in its own way. Like, there's many ways to ruin your estimate [laughs]. \n\nAnd I saw two kind of opposing examples. In one, product came to our team, and they had a big, international expansion project, and they had been burned by some optimistic estimates in the past. I said, \"Okay, what's the worst case that can happen?\" And so, the team talked about all of the worst cases and all of the unknowns we had [chuckles] and everything that could go wrong. \n\nAnd we got an estimate that it was going to be this huge project that was going to take, I don't know, like, eight months or something. And then, the estimate was so big that management decided to...they said, \"Oh, that's just...that's crazy.\" And they quit trusting our software. And this is, like, new management at the time. And said, \"We're just going to outsource this.\" And when they looked at what was going to be involved in outsourcing and how expensive it was, we said, \"Well, no, we can actually do it a lot faster than that.\" Ended up actually getting the project done in 2 or 3 months, way below what the previous estimates were. \n\nBut, you know [chuckles], there was, like, a year that that project didn't get worked on because nobody wanted to invest that huge amount. And engineers actually didn't even know that that was going on. We just did what we were asked to do. It was the worst case, so we gave it to you. And, of course, the worst case is not the average case. It's going to be some of the cases. So, you want to probably aim high, but that one failed.\n\nAnd then, on the flip side, we did some annual planning and didn't have a whole lot of information. So, we planned out a lot of stuff quickly [chuckles], and then somebody went through it and said, \"No, I don't think it actually will take that long.\" And they just chopped the number of our estimates in half [laughs] without any input whatsoever. And not surprisingly, a project that had that happened to has gone about double budget because when that project finally finished, it was about double budget because the earlier estimates were actually pretty good because we compared it with previous work and matched. It can go either way. If you don't trust the past experience, a similar future experience, then you're probably going to have some bad, bad, bad numbers. \n\nDAVE: There's another symptom in what you said that I think is really interesting, which was management sent people off to go make a decision. They didn't have a discussion. They said, \"Go away, discuss and decide, and then give us the decision.\" And then, out of context with no dependencies, or corollaries, or caveats, they're just like, \"Here's the number.\" And because they have completely different assumptions, they made a completely different decision than they might have had they been in the room saying, \"Well, what about this? Well, what if we cut this feature, or what if we brought in contractors, or what if...\" you know, what if. There's no what if. It's just, this is how it will be, and it's unqualified. This is how it will always be in every universe. \n\nMIKE: So, first key to give a really bad estimate is give numbers with no context whatsoever [laughs]?\n\nDAVE: Mm-hmm. Mm-hmm.\n\nEDDY: Well, I do want to say, just because the idea sounds easy doesn't mean the implementation will be. \n\nMIKE: Well, that's an interesting one as well. Have you all ever been in a situation where product did the estimate and then told you what the estimate was? \n\nWILL: I tell you, man, like, I think a really good idea to get these estimates really messed up...so, what you got to do, right? Engineering is so expensive, right? It's really expensive. And so, really, you got to have a business case for it. You got to have a business case for it, and this case is dependent on impact and timelines, how much money. \n\nAnd so, really what you got to do is you got to go to the very highest level, like, the business folks with the spreadsheets. And you got to present your case for your engineering idea, your engineering idea to them, right? And you really got to get them, like, you have to get them aligned with sort of an outcome before you even talk to engineering because, like, you know what I mean, it's such a...you got to justify this line item expense, right?\n\nSo, you really got to go from the business case, top, top, top-level approval of budgets, and then you go down to engineering. Because, as we know, if something went wrong, it's always easier to piss off the C-level executive because they're really, I mean, they're disciplined, emotionally intelligent. They know all of that stuff. And it's easier to piss off your CEO, who maybe made some promises, even to the board, to the public markets, to all that stuff, rather than line-level engineers that might know things that you don't know. Like, as high as you can go, that is just absolutely critical.\n\nDAVE: There's a phrase that weirdly has come up, like, three times in conversations for me this week. And so, this is number four, which is people are sometimes blind to the fact that if you have a problem and you start percolating it up the chain, your team lead can't help you with it. So, you go to the, you know, the department head, and they can't help you with it. So, you go to the engineering. \n\nOnce you're about three levels up, it is very, very hard for that person to solve your problem. It is much easier for them to solve you. And it's the same kind of thing, right? It's like, if I go to the CEO of Rent-A-Center and say, \"I need this,\" he's going to say, \"Stop needing that. Go away,\" right? Because that's the fastest way to solve that, especially if he's got five layers of people that he trusts, which you're going to do if you're in the C-suite. So, whether they're trustworthy or not, you've built them to trust. So, yeah. \n\nMIKE: Will touched on something, the person on the ground who's familiar with the system. A great way to have a really out-of-whack estimate is to completely ignore what they say [laughs]. It's very easy if you're in a leadership position to say, \"Well, I know what I'm talking about.\" You get inflated ego. It's a malady that has been present throughout history [laughs] that people will think, if I'm in charge, that means I know what I'm talking about. And a great way to get to get the estimate that you want to hear is to ignore what people are telling you and just don't even ask, right? Like, well, you know, this should be [chuckles], take the eagles, right? There's an easy way to get to Mordor.\n\nDAVE: The thing that I'm hearing a lot is, like, committing to the map instead of to the terrain. We see this a lot. There's a specific case that I will tell people. Sorry, I need to phrase this in the evil way, right? You should make your decisions as early as possible and stick to them because, later on, you're going to get more information, and that's just going to annoy you. So, make your decisions at the point of minimum information. Never, ever, ever defer a decision, even if making it now would be hard. That's a good one.\n\nWILL: Ooh, I got one, just to pile on. Hard launch everything. It's so cool. You have this grand unveiling, right? I mean, it's like you're showing somebody a finished product. They can get excited rather than a bunch of Tiki-tac incremental stuff you can't hardly do a press release on it. Hard launch, always hard, hard, hard launch, big unveiling. Think Apple, you know what I mean? Like, just the biggest possible spectacle. That's the way to do it. \n\nMIKE: Nailed it. Nailed it. And let me take that a step further. You know you're going to have that big launch. You better plan everything you're going to launch on day one. Make sure you have all of your plans up front.\n\nDAVE: Waterfall. Yep. \n\nMIKE: Plan that --\n\nDAVE: Don't start designing anything until you have planned everything. \n\nMIKE: Everything. Yeah. Absolutely. And follow that plan to the T. Bonus points if you can get out ahead, you know, that means that you're really good at planning. So, if you've got, like, a two-year plan, make sure to do all that planning upfront. \n\nWILL: And the people who did the plan should really be in charge of the estimates, too. And when you give those estimates, right? So, you lay out, this is the product; this is the timeline; this is our hard launch. Get all that stuff done. And when you present it, you should present it with a timeline, right? And this is really important, right? It's like the intuitive mind, right? When you present the thing, you want people's gut instinctual reaction, preferably in a public meeting with everybody there. \n\nSo, you just want to get people right around the table. And you want to be, like, you just want to shoot from the hip, boom. First thought, best thought. You want that creativity. And you want people...like, the accountability is critical, right? So, you got to make sure that you say like, \"I think this is two months. What do you think?\" so that people feel empowered to speak up in front of their peers and say, \"I'm going to disappoint you and your boss. I'm not going to be pressured. I'm going to give you the real estimate because this is an art, not a science.\" You got to let people just go with their feelings. Let it flow. \n\nMIKE: The more public, the better, right? \n\nWILL: Absolutely. Absolutely. It's their time to shine, right? So, the bigger the hats you can get in the room, you know, get a CTO in there. Get some VPs in there, really, like, you know, elevate your team so that they can show what they're capable of because everybody wants to move up. And you don't get to see these guys all the time, right? So, they can really get a feeling for your ability to say, \"Yes [laughs].\" \n\nDAVE: 100%. I had a scrum master that I worked for 15 years ago who loved that step 11 is the commitment. The team must commit. And we had all these blank checks. We had tickets that had been pointed that literally were, \"Click to add description.\" Stop me when you've heard me bang on about that one, right? And it was like, no, we've got this many points in the sprint. Does the team commit to this? And I said, \"No. The team commits to work as hard as we can and give it our best level effort, but this is the plan, and it's not going to go that way.\"\n\nAnd I got a lot of pushback. So, make sure you push back on the people like that. Call them disloyal. Make sure that they do not feel psychologically safe pushing back on that [laughter], and whatever you do, never, ever, ever consider the possibility that you have not refined tickets well enough to commit to making it work.\n\nEDDY: I do want to say that some of the things that I've noticed in my two years or so is that it's really easy to overestimate how fast a project is going to get completed based on the number of cooks you have cooking, right? Because you could add more talent, but you spend more time bringing that talent up to speed than it would take to have people who already know the context to just do it themselves. So, in a sense, sometimes it slows down the process by adding more people who don't have the context to do it. So, from experience, anyways, it's like, help is great, but you got to be smart about it. \n\nMIKE: Well, no, throw more people at it. It'll always speed it up, right? Like, a good example is pregnancy.\n\nDAVE: Brook's law.\n\nMIKE: Nine women, you can have a baby in one month.\n\nDAVE: One month. There was...I worked at...\n\nEDDY: I think someone told me, as a response, sorry, Dave. But I think someone told me --\n\nDAVE: It's okay.\n\nEDDY: They're like, \"Oh yeah, you can't have nine women cook one baby quicker.\" And I'm like, okay, yeah, but the retort was, \"Yeah, but what if you impregnate all nine women? Suddenly, now you have [laughs]\" –-\n\nDAVE: Parallel development, yeah [laughter]. I worked at Acclaim Entertainment, which was not my proudest moment. They're not a great company. But we were working on a video game, and they always get into crunch time as the Christmas season approaches because you got to get your games manufactured to be on the stores before Black Friday and that sort of thing.\n\nAnd they had brought in a whole bunch of contractors from our London studio, flew them over to Salt Lake, and literally just throwing bodies at the problem. And this was when I read Brooks. And so, I wrote, \"How long does it take to make a baby if you assign nine women to the problem?\" And I came back the next day, and somebody had written, \"Two weeks, because we're going to hire nine more contractors.\"\n\n[laughter]\n\nWILL: I'll tell you what's another real needle mover in terms of team efficiency is, when the deadline starts to slip, the more people you can get on a project asking for status reports, and timelines, and when that's supposed to be [laughter], it motivates. It allows team members to have that sort of clarity of purpose because they know how important it is. Otherwise, I mean, developers, I got to be honest with you; sometimes, when we're behind on a project, we can kind of drift. We start taking long lunches. We go for walks around the office, playing a lot of ping pong. \n\nWithout that focus, you could kind of...honestly, sometimes we just forget that we're behind on these commitments. And sort of if you can have somebody every hour, every 30 minutes or so really getting the status reports, it's such a weight off everybody's mind. I forgot. I was like, \"What? Oh my God. Stand-up was two hours ago.\" I already forgot that this project is way behind, like; oh, thank goodness. I could have wasted the entire day not updating you on where the thing was just because, like, oopsie [chuckles], what was I doing?\n\nKYLE: I think having as many of those status updates as meetings that really speeds things up, too. So, make sure that all of those are meetings and scheduled throughout the day. \n\nMIKE: And you want everybody to be aware of it. So, make sure to bring the whole staff in, right? \n\nKYLE: Yeah. The entire staff.\n\nEDDY: I was going to say, make sure everyone who's able to attend to attend; that way, it's more efficient. \n\nWILL: The really critical people, the people you've got to have even more so than product managers who...I know they're coordinating the tickets, but I'd say the people you really, really need to get in those meetings, as many meetings as possible, is the senior technical leaders like your senior engineers, your team leads, the people who are the people who really know the critical bottleneck issues that need to get plugged to enable maybe the junior level team to do work. It's like, you got to know what's really, really going on, and you got to have technical expertise to get those real serious moment-by-moment updates.\n\nDAVE: Yes, if you're going to clean the supply closet in a hospital, make certain that every surgeon in the building is required to be in that meeting, every single one of them. \n\nWILL: Are we going too dark? I feel like we might be going too dark [laughs].\n\nDAVE: I'm here for it, but yeah.\n\n[laughter]\n\nEDDY: I do want to also just say, someone who didn't pick up on it, just for our listener out there, all that was satire, by the way [laughs].\n\nDAVE: Oh yeah, this is a sarcastic episode. \n\nEDDY: [laughs] Please don't take this to heart.\n\nDAVE: Are you being sarcastic? No [laughs]! Yeah [laughs], good times. I think we touched on this a little bit, but make sure your businesspeople are making technical decisions. Make sure your technical people are making business decisions. This is important. If you're at the keyboard typing away, writing some software and that last function just won't work because of this problematic workaround to it, just cut the feature. It's too hard to do; just change the feature to the way you want. If it doesn't comply with some stupid law, whatever, that's somebody else's problem. Businesspeople, at the same time, don't tell people how much stuff is worth. Insist on that you know the price. And we had talked about that. Make sure you're telling people what their estimates are, so...\n\nWILL: I will say, I think, it's really important to make sure you go up the entire chain to product if you want to do something like what color should this button be, or the copy should it be, like, select, or okay, or see all. I'm going to need to check in with marketing, sales. I can't make that decision on my own. I'm just an engineer. I got to have sign-off from VP of marketing on what the okay button text should be. What is the design thing? Should it be white or off-white? I don't know. These are critical questions. Completely above my pay grade. I can't use common sense. I'm an engineer. I'm half autistic, you know what I mean [laughs]? \n\nDAVE: I have worked at a shop where the art team would hand us comps, and they had to be pixel-perfect, or they would just stop the whole team. It's like, \"No, no, you rounded this button with a three-point fillet, and I specifically specified a 3.5.\" Yeah, I can slice pixels. I don't like it, but I can do it because I had to do it. \n\nMIKE: Well, if you really want to make sure your project gets done on time, you don't want to ever have your developers idle. So, make sure you get them started working on the project immediately while you're gathering the requirements.\n\nDAVE: Maximize utilization. Absolutely. \n\nMIKE: Absolutely. \n\nDAVE: Absolutely. \n\nMIKE: It might take you several months to get the requirements for the project. So, you need to make sure that they're really busy working so that when you get those requirements, they already have most of the work done. \n\nEDDY: You know you're being efficient when you're reverting a bunch of the work you're doing because you're releasing a lot of code. \n\nDAVE: I may have put that on a pull request this week. I love it when I can add features by deleting code, yep.\n\nKYLE: [laughs]\n\nDAVE: I think it was yours, Eddy. I think it was your PR that I did that on, so...yep.\n\nWILL: I'm not going to lie. I actually...\n\nDAVE: It wasn't your code that we were reverting. For anybody listening, it was some legacy code that was no longer relevant, so...\n\nWILL: Anyway, I don't know, like, unironically, not devil's advocating, I like just sort of getting to work, you know what I mean? \n\nDAVE: It's very satisfying. \n\nWILL: I like the aspect of, like, well, just agile sprinty. I mean, unironically, I'm not being the devil's advocate. Let's just throw something up and let people look at it, not release it. But it's like, \"Here. Do you like this?\" \n\nSo much ambiguity can be resolved by giving somebody something that they can touch and feel and put their hands on. I'm no longer being ironic. I like giving people prototypes, and they can click the buttons and be like, \"Oh yeah, it clarifies so much.\" I don't know; I've found there's, generally speaking, a difficulty among people who haven't sort of managed a lot of software projects to think about things in a fully fleshed-out way in the abstract. If I showed you a form, and a button, and a widget, and a web page, even if it's connected to nothing, I can get much better feedback, much faster, you know what I mean? I like that.\n\nEDDY: I would argue that's part of your UX design person. It doesn't really fall on the developer. \n\nWILL: You go to war with the designers you have, man. They're art school kids. Like, that's not their gig. It's okay. They're going to make it look good. That's their job. Like, I don't know, if I can make it easier, if I can work harder technically to get a better product, then I'm going to do that, and I'm not going to complain too much about it. Like, that's my job. \n\nMIKE: And, unironically [chuckles], right? I agree with you. I was thinking of an example of, you know, go spend three months working on backend without requirements, without providing a single prototype. And yes, I've seen that kind of thing happen [chuckles] in the past. And it goes about as well as you'd imagine. The [chuckles] services you're building don't match what's actually required because you need to do...to your point, Will, again, unironically, that quick feedback is so critical that if you can't loop on it, it's terrible, which is a good reason to build out one small domain out of your project first so that you can have something that actually works. \n\nWILL: Yeah, yeah, that is an important caveat. I would say that this is kind of frontend only. You can't show your VP of sales a slick API. I don't know who the VP of sales is, but I have a pretty clear idea of, like, that is some slick JSON, you know what I mean? [inaudible 28:00]\n\nMIKE: [laughs]\n\nWILL: But you can show people interfaces. And if you show people a frontend, you know, the backend exists to serve the frontend. Like, the backend is your problem. Get the dorks on it. Anyway.\n\nDAVE: There's a web mockup tool that was designed...it's called Balsamiq. And I don't know if it's still like this. I haven't touched it in years. But when it first came out, it looked like napkin sketches. Like, on your computer screen, it would draw somebody with a ballpoint pen on a napkin, and they did it very deliberately. \n\nAnd I have had this happen to me where you mockup a quick prototype, business looks at it, and they go, \"That's great. Ship it.\" You're like, \"No, this is literally a prototype. There's nothing wired behind this. This is 4% of the system.\" And they're like, \"That looks like 90%. Ship it. You've got a week,\" and you're like, \"No.\" \n\nAnd so, Balsamiq literally shipped sketch stuff to stop that, to let the businesspeople understand that this is nowhere near complete. And it's related to what you were just saying, Will. I think knowing your trade-offs is super important. There's a time when you want to spike, and there's a time when you want to just knuckle down and trudge. And we've got good estimates, and we think we're right, and there's a lot of work to do. Let's sled along on this, or let's...versus jumping in ahead and working on the wrong things, but, spikes, sure. And they do happen frontend, backend. \n\nI have literally spiked a mockup of an entire website, full-stack, database to frontend with just Rails, generate, generate, generate, generate, in a car on the way to an investor meeting, because my boss had said, \"No, we're not switching to Rails. We're not switching to Rails\". And, in the car, he's like, \"How long would it take?\" And I'm like, \"Probably mock it up in the car.\" And he's like, \"No, you can't.\" I'm like, \"Bet.\" And I did. And so, we switched to Rails. \n\nBut that spike there was nothing shippable in that spike. I built it to throw away. It served its purpose, which was to say, \"This is possible. This legacy codebase that we spent five years building, here's the prototype. And based on the prototype and our existing codebase, I'm thinking 18 months.\" So, I was able to give him a realistic estimate off of it. So, knowing where your trade-offs are, I think, and --\n\nEDDY: If that doesn't tell you how powerful Rails is for a start-up company [laughs], I don't know what does [laughs]. \n\nDAVE: To be fair, this was Rails 3.0 when you could still write a blog in 15 minutes on it without having to know Stimulus and a front-end packer, and a pixel shipper, and the, you know, the asset poop line, and all that messy stuff, so...\n\nMIKE: So, if I'm going to go...I'm going back into the snark. \n\nDAVE: Yes. \n\nMIKE: Advanced warning [chuckles]. One great way to make sure that a project gets done on time is to bring in as many teams as possible. But make sure they work independently and never coordinate with each other because you wouldn't want them to have any inefficiencies of communication. Also, let them design the interfaces independently, and then we can just fix that communication layer at the end because that's not the important part. The important part is that we all make sure that they're all working, and they're all heads down. We can handle any and many communication issues later. Make sure the APIs are in line. That's not a big problem, right? \n\nDAVE: Yes.\n\nEDDY: Well, if you want a way to speed up your service, just don't write tests. \n\nDAVE: Oh yeah. \n\nEDDY: Just ship your code. \n\nDAVE: Fair point. Yeah. And there's a generic form of that, which is never check your work, right? Never cross-check. In fact, we should put that as part of the waterfall. Make sure coding is 100% done before you start debugging. That's literally part of the original SDLC when they were saying, \"Stop doing this.\" \n\nEDDY: Yeah, also, let your developers be the sole QA. That's good, too. \n\nDAVE: Make sure your creators are editing at the same time that they're trying to create.\n\nEDDY: 100%. \n\nWILL: I mean, software QA exists. The entire career exists because I cannot be trusted. \n\nMIKE: [laughs]\n\nWILL: That's it. That's it. There's nothing a QA can do that I can't and don't. You cannot trust me. I cannot be relied upon. Like, I can't do it. You can't, like, jump. Oh, wait, wait. Hang on. No, no, hang on. I said that wrong. \n\nDAVE: You got it backwards, yeah. How dare you be candid?\n\nWILL: Bro, why do you even have a QA? Devs know how it works. Like, they understand it better than anybody. QA is just a waste of time. Like, you have an extra person? They don't even know how to code, bro. Like, What? Why even? It's a nonsensical position to have. Like, the devs could do it. They did it. Just shut your work, guys, duh. \n\nDAVE: If they can't code, we could have them doing tech estimates for us, though. There's that option, so...\n\nMIKE: [laughs]\n\nEDDY: And you can have your product guys go ahead and help you commit a bunch of stuff. When you're short-staffed, you know, just rely on other departments.\n\nDAVE: Yep. We talked a little bit earlier about Fred Brooks, about how many women and da da da da. Fred Brooks wrote a book called \"The Mythical Man-Month\" that's all about this. And Brooks' actual law that he quotes is, \"Adding people to a late project makes it later.\" \n\nEDDY: It's true.\n\nDAVE: That's where it comes from, yeah. \n\nWILL: And I'd say another note on QA. I'd say the best people to do the QA are the high-level executives when you're doing your demo, your final presentation, preferably even after it's already been out to production and you got your VP out there. \n\nDAVE: [laughs]\n\nWILL: They're pretty loose people. Like, they're not detail-oriented. They don't have real visions. And even if they did, they found something; it's not like you're going to look like an idiot when your VP of product is checking stuff in prod, and your links are broken. And, honestly, those guys, they don't even notice half the time. They're just like [inaudible 34:30], whatever. They're just so chill. They don't even care. \n\nMIKE: They don't have any relationships outside of your business either, right? And they're too busy working with people in the company. They don't have the CEO of your partner's company on their speed dial because, yeah, they don't have time for that. There's no way anybody would ever, you know, important business partner would ever reach out to them at 3:00 in the morning wondering why the service is down. That's just not their job. \n\nEDDY: You know, one way to really ramp up the way wave to meet the deadline is to just ship it, even if it's broken. You met the deadline. Just merge --\n\nDAVE: Yeah. We can ship DLC later. \n\nKYLE: I've got a controversial one, I think. \n\nDAVE: Oh, please. \n\nKYLE: DevOps is a culture, not a team. I've seen where, you know, that's on the developer. They can do their own DevOps and manage their own infrastructure. And --\n\nDAVE: It's called DevOps for a reason, Kyle. We're the devs. We do the ops. \n\nKYLE: Yeah. So, we don't need a specialized team for any of that. \n\nDAVE: Yeah. And all you need to know as DevOps is just chmod A plus X minus R. Just go nuts, just 777 for the entire hard drive. Yeah, it's fine. \n\nWILL: It's called CI/CD, bruh, continuous deployment. I'm just going to throw that thing up. New endpoint? I don't know. There's probably no scaling requirements. The server was fine before. I'll just throw this new API up there. Let's roll, YOLO. \n\nDAVE: Ooh, related to this, Mike's going to wince a little bit, but don't do any tech debt. If your CI machine catches on fire, get some marshmallows. That's the best thing you can do for it, yeah. So... [laughs]. \n\nEDDY: Well, you don't have tech debt if you just delete [laughter] [inaudible 36:16] you've broken. \n\nDAVE: Mike is covering his mouth. There may have been an incident at work this week, so... \n\nEDDY: You can't have [inaudible 36:36] that's broken, Dave. You just delete the code. \n\nDAVE: That's right. \n\nEDDY: Just delete it. It's not broken no more. \n\nDAVE: Yep. Actually, touching on what Kyle said about DevOps, if you really want to mess everybody up, divide your company horizontally. Make sure that the database team are in their own spot, servicing all the database clients, because then you've got all your experts in one place. And anybody that needs anything from the database team now has to go up through their boss and their boss, and then come down through the data management people, and they've got objectives that they need done. Same thing with your sysadmin, same things with your DevOps, same things, you know, if you've got anybody that's writing backend and frontend, get them on separate teams. Whatever you do, do not under any circumstances have a full cross-functional product team. \n\nKYLE: I think another good one is launch your service or whatever deliverable you have before you consider security. \n\nDAVE: Yeah. Yeah. Yeah, you can just bolt that on later, come on. There's no security. That mockup that I showed you that, you said, \"Ship it,\" and gave me a week; we can just do security later. It's fine. 100%.\n\nEDDY: Mockups don't have permissions. Dave, are you crazy? You don't need to scope permissions to your users. Just whatever --\n\nDAVE: If you can see the mockup, you can access the thing, yeah. \n\nMIKE: You'll never have a user who will try changing the URL to see, you know, another user's data. Our users are never clever like that. \n\nDAVE: Ooh, slightly related to that, I'm not sure how to phrase this, but as you're developing, if you trip over something, don't flag that. Just step over it every single time. Definitely don't put rules in your engine. Don't write an RSpec thing to check to make sure that there's no implicit scopes or default scopes on your Rails models. And you want default scopes everywhere. You want to tenant your customers at the default scope. That's really, really important --\n\nEDDY: Make sure you unscope, Dave. Like, that's –-\n\nDAVE: And then, what you'll also do is you'll have your scope that says, \"Valid,\" which is going to select for things that have not been deleted so that then when you say \"Unscoped,\" we throw away the deleted at so that you can pull all the records, and we also throw away the tenanting. And now you're looking at every single customer in the system. I had that happen at a company where showing somebody else somebody else's data involved federal oversight. Like, you messed up. There was a department that you had to report to and say, \"We did that.\"\n\nEDDY: I was going to say, Dave, that's kind of oddly specific [laughs]. \n\nDAVE: And if you press me further, I will deny it, yep.\n\nEDDY: [laughs] [inaudible 39:13]\n\nDAVE: I've never worked with an entire company full of idiots. I self-select out of that environment. I've seen all of these design...most of us have, right? All these design hell problems, and they usually come about based on really good partial information. \n\nEDDY: I was going to say, something that can really speed up is just always, always, always going against your framework's convention. Like, it works 100% of the time. \n\nMIKE: Well, I can one-up you there. You want to get out quickly. You don't have to deal with the constraints of a framework. So, make sure you implement from scratch because, that way, you can...\n\nDAVE: Roll your own.\n\nMIKE: Yeah, roll your own. That way, you won't have to memorize the conventions. You won't have to deal with, like, libraries that will fight back against you when you're trying to do direct database manipulation. Just build everything yourself. It's a much faster way to work. \n\nDAVE: This week, I am maintaining some code that has some custom snippets of SQL wrapped up in a custom DSL that are wrapped up in the source code. And it's just a joy to work with. It's absolutely fun. I have not ripped out any of my fingernails. I have not shaved my head defensively to save tufts of hair from being ripped out. It's, yeah, it's just been a dream, absolutely a dream. So...\n\nEDDY: You know, another thing that's helped me, Dave, and I want to say, like, [inaudible 40:41] loading has been wonders. Like, you want me to ship something? Yeah, copy and paste someone else's work, you know, that's done before. It doesn't matter if it's being used in that context or not. Just [inaudible 40:53] is always --\n\nDAVE: Yes, going back to the good intentions, end up in hellish places; drying things up to the point that they become chaffy is fantastic. You should compress everything and especially, you know, that SQL DSL that I'm working on, get into RSpec, and there's an include, not, like, include shared context. It's an include module, and the module was in the support directory. And I opened that up. And when you include the module, it creates a shared context and includes it. And the shared context creates lets. I have told that nightmare story here at work multiple times, thinking certainly that I would never see it. We saw it this week, so it's pleasant. It's kind of fun. \n\nEDDY: Mine is a controversial one.\n\nDAVE: I will say that I am sincerely saying that I'm enjoying working on this because I feel a little bit vindicated when I work on it. Also, in defense, because I did actually say something about a real company that is doing real work, and I don't want to get yelled at for this, I do want to point out that the developer who did it that way did it in 2015 when it was a best practice. I've written a lot of code that had shared context and riffling the deck to shuffle all the pieces so that they, like, laminates on an overhead projector with multiple layers to make them line up and that kind of thing. \n\nIt's very satisfying to dry that up in your text editor because you've got it all in your head, and you're like, oh, yes, why should I duplicate this? Let's put this over here. It's not until you come back later that you realize that you have just burned off every entry point for intuition and for someone else to be able to follow your path.\n\nMIKE: I was thinking about a real-world story as well about avoiding the framework. I'm going to go back a lot farther, I think, like, 2003 [laughs]-ish. \n\nDAVE: Ooh, okay. So, probably not Rails. It might have been Rails, but probably not Rails. \n\nMIKE: Not Rails. I don't think Rails was out there. Anyway, this was actually some sort of Visual Basic. I don't remember the exact flavor of it. And there was no database library used whatsoever. It was all just raw rights to the database. And it only takes one unsanitized database input. It only takes one to lose a million dollars [laughs] of your customer's money. \n\nEDDY: Yeah. Just don’t --\n\nDAVE: What's the .NET... .NET has a SQL thing, like linker, SkLink. There's a name for it. But yeah...that would've been coming into existence about two years after 2003. So, yeah, if you're going to write SQL, it's going to be in the code. It's going to have to be in the code. \n\nMIKE: This is back...I remember Hibernate was just getting started in the Java world and, like, wow, this is great. You can use some library and convention to write your SQL rather than hand-coding it all [laughs], but not so in the application that we took over [laughs]. \n\nDAVE: Oh, never switch. There's some people on this call that are going to feel seen and attacked at the same time, but this is actually not. But if you're going to add a new technology, add it. Don't change the existing stuff. You want people to have to maintain both. It's even better if they don't know which one they're working on until it's too late. That's a good one. \n\nMIKE: As many text stacks as possible?\n\nDAVE: Mm-hmm. Mm-hmm.\n\nEDDY: Ship --\n\nDAVE: For real, I used to walk into stand-ups...if I wanted to terrify everyone, I would give my stand-up report as, \"So I did a quick spike, and I rewrote this in Rust.\" And, if you can sell that with a straight face, you can get, like, the blood to drain out of other people's...they're like, \"You're doing what?\" \n\nMIKE: [laughs]\n\nEDDY: Also, make sure you support multiple versions. I think that's --\n\nDAVE: Oh.\n\nMIKE: Simultaneous.\n\nDAVE: Arbitrarily, arbitrarily. Don't just do it for the interface stability reasons. Do it arbitrarily. \n\nMIKE: Well, if you don't have three versions of bootstrapping in your codebase, you're not a real project. \n\nDAVE: What are you doing right? Yeah, and Angular 1 to Angular 2, they redesigned everything. So, you're going to need both, or you're going to be missing stuff out. \n\nEDDY: It's a good thing that you can't support multiple versions of Ruby, though, like, satire aside, right? Like, you can only have one true Ruby version for the project. You can't support multiple. Is that correct? I see you smirk, Dave. Like, I wonder [chuckles], is that possible? \n\nDAVE: It's absolutely possible. Like, Ruby 1.0 shipped with a library, dRuby? Distributed Ruby. And it made remote procedure calls very, very easy. You could write your program in two places. And if they knew how to find each other, you could call the function here, and execute it over here, and send it back, and nobody uses it. It was an interesting experiment, and nobody uses it. But 100%. \n\nAnd, honestly, we do this here, where we've got service-oriented architecture. So, this team is on one version of Ruby, and this team is struggling because they've got this really important science library or finance library that isn't up on the latest. So, they have to stay back on an old version. Yeah, you do see that. So, what you have to do is you have to get out of the processor. You can't share memory with each other. I'm not going to say that super confidently. Somebody will say, \"Here's a proof of concept.\" \n\nMIKE: [inaudible 46:34]\n\nDAVE: But, to my knowledge, if you're going to have multiple versions, they're going to have to drop to a protocol and communicate with each other like separate programs.\n\nEDDY: Not ideal. \n\nMIKE: We've come up with a lot of great ideas. I think that we could come up with an estimate that's pretty much whatever we want. \n\nDAVE: We might be able to bring down the whole system. \n\n[laughter]\n\nEDDY: I was going to say something controversial, but some people may or may not agree, really just depends on your perspective. But I was going to say, as a satire, make sure you always do integration tests, and use factories to make sure you're testing the real data so that it gets committed to your database, but --\n\nDAVE: And committed without any trade-offs. \n\nEDDY: But I feel like some people do agree with that, and that's an interesting [laughs] topic. \n\nDAVE: As long as you're ignoring your trade-offs so that you've got your test where you need to go really, really fast, as long as they're writing to disk and doing everything slow, and exercising the full-stack, and the stuff where you just need to test an accessor method that doesn't even talk to anything else that should be talking to the database, too, then, yeah, you'll be fine. You'll be fine. \n\nMIKE: Well, you need to make sure that everything works, right? So, make sure -- \n\nEDDY: Make sure you test Ruby and Rails, too, like --\n\nMIKE: Well, yeah, you can't trust the framework, and you definitely can't trust your third parties, so make sure that you make live API calls to their sandbox in your integration, you know, in your CI environment. \n\nDAVE: Oh, yeah. If you come up with a workaround to a problem, solve it as far up the tech stack as possible. Like, I worked with an engineer who would recompile Ruby to add features to it, and we set him straight pretty quickly because [laughter] we're like, \"We're not shipping your copy of Ruby to all of our servers. It's not happening. Stop asking.\" To be fair, he was a genius. He could shatter a human mind at 50 paces just by thinking about it, and he was very, very, very clever, and sometimes he was too clever for all of our good, so... \n\nKYLE: I'd say –-\n\nDAVE: I had a funny idea for how to end this podcast, which is to say, \"Okay, now we estimated this much time,\" and then cut off right in the middle of the sentence, just no outro.\n\n[chuckles]\n\nEDDY: Kyle, you were going to say something? \n\nDAVE: Sorry, yeah.\n\nKYLE: I was just going to say, and don't worry about the performance of your code. We can always throw more hardware at it. \n\nDAVE: Right [laughs].\n\nEDDY: It's your computer that's slow, dude, [inaudible 49:11] [laughs]. \n\nKYLE: And we can ship that into the cloud if we need to. \n\nDAVE: Yes.\n\nEDDY: Develop to the cloud; it has unlimited resources. \n\nDAVE: And I will see you in raise. You should care about maximizing performance at the start. \n\nMIKE: Yes [laughs].\n\nDAVE: You want to make the code as hard to read and as difficult to maintain as early as possible. And unrolling anything that's readable into something that's just hyper-efficient, go for it. That way, you're guaranteed to optimize things that aren't important. So, we will still need to scale up into the cloud to get around all the bottlenecks that we didn't even look at. \n\nMIKE: And make sure that you do lots of planning around that optimization during the beginning of your waterfall process. \n\nDAVE: Yes.\n\nMIKE: Because that's what's going to matter the most is that optimization. \n\nEDDY: I was going to say one thing, too. I was going to say, don't add comments and be super brilliant to what you're doing, so it's complicated for everyone else. \n\nDAVE: Yes. \n\nEDDY: So that you --\n\nDAVE: Never ever pave a path through the code. You need to vanish into the jungle and be lost without a trace. Anybody who needs to follow you needs to solve it from first principles. That's important. It builds character. \n\nEDDY: 100%. Like --\n\nDAVE: And you need to prove your worth. \n\nMIKE: So, if you don't have tricky code to read, well, then you're probably doing it wrong, right? I mean, how smart are you if everybody can read what you're writing? \n\nDAVE: Yeah. We can go into a whole tangent about, like, your ego is more important than right and wrong, and that should be protected at any cost. \n\nKYLE: I think one thing that goes really good on readability is the largest PRs as possible. \n\nMIKE: Oh yeah. \n\nDAVE: Definitely. \n\nMIKE: You wouldn't want to waste time with QA having to review a bunch of small PRs. So, make sure you release the whole feature in one, that way, they can just test it once –- \n\nKYLE: Save testing time.\n\nEDDY: And test in production. That's the best way --\n\nKYLE: Oh, that's the best one. Yeah, we can go to production first. \n\nDAVE: Yes --\n\nEDDY: Who better to tell you that your feature sucks than actual users, you know what I mean? \n\nDAVE: I have a suggestion for a good final one, which is, if you're listening to this podcast and you think we're making fun of you, ignore it. It's fine. Don't take any lessons away from this. Remember to just stick by your guns, no matter what. Nobody has done any of these things in real. We're not talking about you; it's fine. Yeah, definitely don't take a hint from this to maybe try to improve steadily and stably. If you are going to react, make sure you overreact. I think that's the important takeaway here. \n\nMIKE: We'll take the same advice because, of course, we've never run into any of these things ourselves. \n\nDAVE: Mm-mm. Mm-mm. That's fantastic. Are we at a good stopping point, gentlemen? \n\nEDDY: I think so. \n\nDAVE: This has been a lot of fun. Thank you, guys, for coming out: Mike, Kyle, Eddy. Will had to drop off for a family issue. But so glad you guys came out. This was a lot of fun. And thank you all for listening and watching The Acima Developer Podcast. We'll see you again in a couple of weeks. ","content_html":"In this episode of the Acima Developer Podcast, host Dave Brady and the panel, including Mike Challis, Kyle Archer, Eddy Lopez, and Will Archer, delve into a satirical discussion on how to ensure time estimates for software projects go wrong. They explore various humorous yet insightful approaches, such as using aggressive negotiation with engineers, ignoring edge cases, and focusing on points as extrinsic values rather than consistency. The conversation is full of playful examples, with stories from past experiences, all illustrating how poor communication, over-optimistic estimates, and leadership pressure can derail projects.
\n\nThe team highlights how over-reliance on tools like Pivotal Tracker or Jira without considering the actual complexity of tasks can lead to skewed results. They also mock the practice of placing value on productivity metrics, like story points, while ignoring the consistency and accuracy of those numbers. Throughout the discussion, the panel pokes fun at the missteps that can occur when management overrides technical teams' decisions, fails to understand project requirements, or implements unrealistic planning methods, using examples from both personal and industry-wide experiences.
\n\nTowards the end, the group turns their satire to broader topics like testing practices, infrastructure management, and project launches. They humorously suggest that skipping QA, bolting on security post-launch, and involving high-level executives in day-to-day decisions can lead to even more dysfunction. Ultimately, the conversation serves as a playful critique of common issues in project management and development, with a clear undertone of how these behaviors should be avoided for the sake of successful project outcomes.
\n\nTranscript:
\n\nDAVE: Hello and welcome to the Acima Developer Podcast. I'm Dave Brady, and I'm hosting today. We've got a good panel today. We've got Mike Challis, Kyle Archer. We've got Eddy Lopez and Will Unverified. I don't think that's your...
\n\nWILL: It's Will Archer.
\n\nDAVE: It's Archer. Archer? Yeah. Welcome, Will. So, last week, we talked about some structure, and we thought we would carry over, and I think we're going to table that for a week. Today we came up with, actually, it was Will. You came up with a really interesting question phrased in kind of a devil's advocacy. Do you want to phrase that up for us and tee us up?
\n\nWILL: Well, so, if I wanted the worst possible time estimate for my project, how could I do it? How could I really screw up my time estimates?
\n\nDAVE: I like it. I may or may not have some stories related to this. I'm seeing knowing smiles around the board. Okay, so I'll give two stories really, really quick. And the second one is actually the counter to the first one.
\n\nNegotiate aggressively with your subject matter experts in a threatening manner. Specifically, negotiate story points down because you don't want to spend extra time dealing with the problems that your people are thinking of that might be coming down the pipe. And a great way to do it and sound like you're not doing it is to begin every sentence with, "Why don't you just...?"
\n\nAnd so, you can take something really super-duper complicated...I mean, throwing the ring into Mount Doom that's a one-point story. How long does it take you to drop a piece of jewelry into lava [laughter]? It's super easy, right? Super-duper easy. Why don't you just do that? It's fine. And yeah, it's that kind of thing, right? Where the actual thing, you know, getting to the site to deliver it, you know, OSHA injuries where he gets his finger bitten off, right? That whole thing.
\n\nWILL: Take the Eagles, guys! It's [crosstalk 02:00] a one-hour flight. Take the Eagles, duh.
\n\nDAVE: Yes.
\n\nEDDY: I was going to say, don't you like the idea of having an extra cushion to your points?
\n\nDAVE: [inaudible 02:08]
\n\nEDDY: Yeah, because if you over-deliver and you get it done, like, two or three weeks ahead of time, the only thing that you get is just applause, right? Like, you got it done earlier.
\n\nDAVE: Well, so, I think this is kind of the other way around, right, where it's like dropping this in. We're going to budget two hours for this, which is plenty of time to drop a piece of jewelry into lava. And the project, as we know, is going to end up taking three months from, you know, hindsight. And that's the kind of stuff where...like, engineers often get paid to think about edge cases, and weird things, and, you know, what about this thing, and da da da da da.
\n\nAnd very, very smart people who are low in trait openness...openness is one of the big five psychological traits for gauging a personality. People who are low on this are very certain they're the J type on the Myers Briggs. They're judgy, not perceptive. What's in their head, they will press that down on the world around them.
\n\nAnd this leader that I worked with would negotiate aggressively, and because he was the CTO, every discussion was an uphill push, so, okay. And we used Pivotal Tracker, and Pivotal didn't care. Tracker doesn't care what you think your velocity is. It will tell you what your velocity is. And because the stories were getting smaller and smaller numbers on them, all of Lord of the Rings became a one-point story, which means it took us three months to deliver one point of value.
\n\nMIKE: Wow.
\n\nDAVE: And he did not like that. We literally watched Tracker go sub-integer. We had a velocity of 0.2 at one point. And that did not make the CTO happy either because he wanted the points to be big, which might be another evil thing is, like, place extrinsic value on points.
\n\nThe counter to it is the second story, which I'll just tell in just one quick sentence. I had a manager who looked at me, and he said, "I don't care what your velocity is. I don't care what the number is. If it's consistent, I can bank on it." If the team velocity is 180, that's great. If it's accurate, I'm going to ship on time, and I'm happy. If the team velocity is 1.8, that's fine. Points don't matter, remember? And if I can bank on you shipping on this day, and I can queue up the next thing, I'm happy." So, if you want to mess up your schedule, focus on the points themselves as extrinsic things, and ignore consistency in your estimates.
\n\nEDDY: So, Dave, for the people that may not be aware, what's Tracker? Can you give an overview?
\n\nDAVE: Pivotal is a company that makes software, and Tracker is their time-tracking thing. It's Jira, or VersionOne, or Rally. These are all competitors. Jira is the really big gorilla kind of taking over the scene. Basically, you do this, deliver it, and then it goes into the backlog, and you put points on it. And then, Tracker gives you your to-do list against a calendar. It's like, no, no, this is your...I've been measuring your velocity. This is how many stories you have. This is when you're going to be done. And after you've been using it for about three or four months, it starts getting spookily accurate. And if you don't like what it says, you can change the numbers to be wrong.
\n\nMIKE: I had a couple of stories I was thinking of as you were sharing them [chuckles], but I'm going to go a different way. I mean, we were talking in the pre-call about the first line in Anna Karenina, which is all happy families resemble one another. Every unhappy family is unhappy in its own way. Like, there's many ways to ruin your estimate [laughs].
\n\nAnd I saw two kind of opposing examples. In one, product came to our team, and they had a big, international expansion project, and they had been burned by some optimistic estimates in the past. I said, "Okay, what's the worst case that can happen?" And so, the team talked about all of the worst cases and all of the unknowns we had [chuckles] and everything that could go wrong.
\n\nAnd we got an estimate that it was going to be this huge project that was going to take, I don't know, like, eight months or something. And then, the estimate was so big that management decided to...they said, "Oh, that's just...that's crazy." And they quit trusting our software. And this is, like, new management at the time. And said, "We're just going to outsource this." And when they looked at what was going to be involved in outsourcing and how expensive it was, we said, "Well, no, we can actually do it a lot faster than that." Ended up actually getting the project done in 2 or 3 months, way below what the previous estimates were.
\n\nBut, you know [chuckles], there was, like, a year that that project didn't get worked on because nobody wanted to invest that huge amount. And engineers actually didn't even know that that was going on. We just did what we were asked to do. It was the worst case, so we gave it to you. And, of course, the worst case is not the average case. It's going to be some of the cases. So, you want to probably aim high, but that one failed.
\n\nAnd then, on the flip side, we did some annual planning and didn't have a whole lot of information. So, we planned out a lot of stuff quickly [chuckles], and then somebody went through it and said, "No, I don't think it actually will take that long." And they just chopped the number of our estimates in half [laughs] without any input whatsoever. And not surprisingly, a project that had that happened to has gone about double budget because when that project finally finished, it was about double budget because the earlier estimates were actually pretty good because we compared it with previous work and matched. It can go either way. If you don't trust the past experience, a similar future experience, then you're probably going to have some bad, bad, bad numbers.
\n\nDAVE: There's another symptom in what you said that I think is really interesting, which was management sent people off to go make a decision. They didn't have a discussion. They said, "Go away, discuss and decide, and then give us the decision." And then, out of context with no dependencies, or corollaries, or caveats, they're just like, "Here's the number." And because they have completely different assumptions, they made a completely different decision than they might have had they been in the room saying, "Well, what about this? Well, what if we cut this feature, or what if we brought in contractors, or what if..." you know, what if. There's no what if. It's just, this is how it will be, and it's unqualified. This is how it will always be in every universe.
\n\nMIKE: So, first key to give a really bad estimate is give numbers with no context whatsoever [laughs]?
\n\nDAVE: Mm-hmm. Mm-hmm.
\n\nEDDY: Well, I do want to say, just because the idea sounds easy doesn't mean the implementation will be.
\n\nMIKE: Well, that's an interesting one as well. Have you all ever been in a situation where product did the estimate and then told you what the estimate was?
\n\nWILL: I tell you, man, like, I think a really good idea to get these estimates really messed up...so, what you got to do, right? Engineering is so expensive, right? It's really expensive. And so, really, you got to have a business case for it. You got to have a business case for it, and this case is dependent on impact and timelines, how much money.
\n\nAnd so, really what you got to do is you got to go to the very highest level, like, the business folks with the spreadsheets. And you got to present your case for your engineering idea, your engineering idea to them, right? And you really got to get them, like, you have to get them aligned with sort of an outcome before you even talk to engineering because, like, you know what I mean, it's such a...you got to justify this line item expense, right?
\n\nSo, you really got to go from the business case, top, top, top-level approval of budgets, and then you go down to engineering. Because, as we know, if something went wrong, it's always easier to piss off the C-level executive because they're really, I mean, they're disciplined, emotionally intelligent. They know all of that stuff. And it's easier to piss off your CEO, who maybe made some promises, even to the board, to the public markets, to all that stuff, rather than line-level engineers that might know things that you don't know. Like, as high as you can go, that is just absolutely critical.
\n\nDAVE: There's a phrase that weirdly has come up, like, three times in conversations for me this week. And so, this is number four, which is people are sometimes blind to the fact that if you have a problem and you start percolating it up the chain, your team lead can't help you with it. So, you go to the, you know, the department head, and they can't help you with it. So, you go to the engineering.
\n\nOnce you're about three levels up, it is very, very hard for that person to solve your problem. It is much easier for them to solve you. And it's the same kind of thing, right? It's like, if I go to the CEO of Rent-A-Center and say, "I need this," he's going to say, "Stop needing that. Go away," right? Because that's the fastest way to solve that, especially if he's got five layers of people that he trusts, which you're going to do if you're in the C-suite. So, whether they're trustworthy or not, you've built them to trust. So, yeah.
\n\nMIKE: Will touched on something, the person on the ground who's familiar with the system. A great way to have a really out-of-whack estimate is to completely ignore what they say [laughs]. It's very easy if you're in a leadership position to say, "Well, I know what I'm talking about." You get inflated ego. It's a malady that has been present throughout history [laughs] that people will think, if I'm in charge, that means I know what I'm talking about. And a great way to get to get the estimate that you want to hear is to ignore what people are telling you and just don't even ask, right? Like, well, you know, this should be [chuckles], take the eagles, right? There's an easy way to get to Mordor.
\n\nDAVE: The thing that I'm hearing a lot is, like, committing to the map instead of to the terrain. We see this a lot. There's a specific case that I will tell people. Sorry, I need to phrase this in the evil way, right? You should make your decisions as early as possible and stick to them because, later on, you're going to get more information, and that's just going to annoy you. So, make your decisions at the point of minimum information. Never, ever, ever defer a decision, even if making it now would be hard. That's a good one.
\n\nWILL: Ooh, I got one, just to pile on. Hard launch everything. It's so cool. You have this grand unveiling, right? I mean, it's like you're showing somebody a finished product. They can get excited rather than a bunch of Tiki-tac incremental stuff you can't hardly do a press release on it. Hard launch, always hard, hard, hard launch, big unveiling. Think Apple, you know what I mean? Like, just the biggest possible spectacle. That's the way to do it.
\n\nMIKE: Nailed it. Nailed it. And let me take that a step further. You know you're going to have that big launch. You better plan everything you're going to launch on day one. Make sure you have all of your plans up front.
\n\nDAVE: Waterfall. Yep.
\n\nMIKE: Plan that --
\n\nDAVE: Don't start designing anything until you have planned everything.
\n\nMIKE: Everything. Yeah. Absolutely. And follow that plan to the T. Bonus points if you can get out ahead, you know, that means that you're really good at planning. So, if you've got, like, a two-year plan, make sure to do all that planning upfront.
\n\nWILL: And the people who did the plan should really be in charge of the estimates, too. And when you give those estimates, right? So, you lay out, this is the product; this is the timeline; this is our hard launch. Get all that stuff done. And when you present it, you should present it with a timeline, right? And this is really important, right? It's like the intuitive mind, right? When you present the thing, you want people's gut instinctual reaction, preferably in a public meeting with everybody there.
\n\nSo, you just want to get people right around the table. And you want to be, like, you just want to shoot from the hip, boom. First thought, best thought. You want that creativity. And you want people...like, the accountability is critical, right? So, you got to make sure that you say like, "I think this is two months. What do you think?" so that people feel empowered to speak up in front of their peers and say, "I'm going to disappoint you and your boss. I'm not going to be pressured. I'm going to give you the real estimate because this is an art, not a science." You got to let people just go with their feelings. Let it flow.
\n\nMIKE: The more public, the better, right?
\n\nWILL: Absolutely. Absolutely. It's their time to shine, right? So, the bigger the hats you can get in the room, you know, get a CTO in there. Get some VPs in there, really, like, you know, elevate your team so that they can show what they're capable of because everybody wants to move up. And you don't get to see these guys all the time, right? So, they can really get a feeling for your ability to say, "Yes [laughs]."
\n\nDAVE: 100%. I had a scrum master that I worked for 15 years ago who loved that step 11 is the commitment. The team must commit. And we had all these blank checks. We had tickets that had been pointed that literally were, "Click to add description." Stop me when you've heard me bang on about that one, right? And it was like, no, we've got this many points in the sprint. Does the team commit to this? And I said, "No. The team commits to work as hard as we can and give it our best level effort, but this is the plan, and it's not going to go that way."
\n\nAnd I got a lot of pushback. So, make sure you push back on the people like that. Call them disloyal. Make sure that they do not feel psychologically safe pushing back on that [laughter], and whatever you do, never, ever, ever consider the possibility that you have not refined tickets well enough to commit to making it work.
\n\nEDDY: I do want to say that some of the things that I've noticed in my two years or so is that it's really easy to overestimate how fast a project is going to get completed based on the number of cooks you have cooking, right? Because you could add more talent, but you spend more time bringing that talent up to speed than it would take to have people who already know the context to just do it themselves. So, in a sense, sometimes it slows down the process by adding more people who don't have the context to do it. So, from experience, anyways, it's like, help is great, but you got to be smart about it.
\n\nMIKE: Well, no, throw more people at it. It'll always speed it up, right? Like, a good example is pregnancy.
\n\nDAVE: Brook's law.
\n\nMIKE: Nine women, you can have a baby in one month.
\n\nDAVE: One month. There was...I worked at...
\n\nEDDY: I think someone told me, as a response, sorry, Dave. But I think someone told me --
\n\nDAVE: It's okay.
\n\nEDDY: They're like, "Oh yeah, you can't have nine women cook one baby quicker." And I'm like, okay, yeah, but the retort was, "Yeah, but what if you impregnate all nine women? Suddenly, now you have [laughs]" –-
\n\nDAVE: Parallel development, yeah [laughter]. I worked at Acclaim Entertainment, which was not my proudest moment. They're not a great company. But we were working on a video game, and they always get into crunch time as the Christmas season approaches because you got to get your games manufactured to be on the stores before Black Friday and that sort of thing.
\n\nAnd they had brought in a whole bunch of contractors from our London studio, flew them over to Salt Lake, and literally just throwing bodies at the problem. And this was when I read Brooks. And so, I wrote, "How long does it take to make a baby if you assign nine women to the problem?" And I came back the next day, and somebody had written, "Two weeks, because we're going to hire nine more contractors."
\n\n[laughter]
\n\nWILL: I'll tell you what's another real needle mover in terms of team efficiency is, when the deadline starts to slip, the more people you can get on a project asking for status reports, and timelines, and when that's supposed to be [laughter], it motivates. It allows team members to have that sort of clarity of purpose because they know how important it is. Otherwise, I mean, developers, I got to be honest with you; sometimes, when we're behind on a project, we can kind of drift. We start taking long lunches. We go for walks around the office, playing a lot of ping pong.
\n\nWithout that focus, you could kind of...honestly, sometimes we just forget that we're behind on these commitments. And sort of if you can have somebody every hour, every 30 minutes or so really getting the status reports, it's such a weight off everybody's mind. I forgot. I was like, "What? Oh my God. Stand-up was two hours ago." I already forgot that this project is way behind, like; oh, thank goodness. I could have wasted the entire day not updating you on where the thing was just because, like, oopsie [chuckles], what was I doing?
\n\nKYLE: I think having as many of those status updates as meetings that really speeds things up, too. So, make sure that all of those are meetings and scheduled throughout the day.
\n\nMIKE: And you want everybody to be aware of it. So, make sure to bring the whole staff in, right?
\n\nKYLE: Yeah. The entire staff.
\n\nEDDY: I was going to say, make sure everyone who's able to attend to attend; that way, it's more efficient.
\n\nWILL: The really critical people, the people you've got to have even more so than product managers who...I know they're coordinating the tickets, but I'd say the people you really, really need to get in those meetings, as many meetings as possible, is the senior technical leaders like your senior engineers, your team leads, the people who are the people who really know the critical bottleneck issues that need to get plugged to enable maybe the junior level team to do work. It's like, you got to know what's really, really going on, and you got to have technical expertise to get those real serious moment-by-moment updates.
\n\nDAVE: Yes, if you're going to clean the supply closet in a hospital, make certain that every surgeon in the building is required to be in that meeting, every single one of them.
\n\nWILL: Are we going too dark? I feel like we might be going too dark [laughs].
\n\nDAVE: I'm here for it, but yeah.
\n\n[laughter]
\n\nEDDY: I do want to also just say, someone who didn't pick up on it, just for our listener out there, all that was satire, by the way [laughs].
\n\nDAVE: Oh yeah, this is a sarcastic episode.
\n\nEDDY: [laughs] Please don't take this to heart.
\n\nDAVE: Are you being sarcastic? No [laughs]! Yeah [laughs], good times. I think we touched on this a little bit, but make sure your businesspeople are making technical decisions. Make sure your technical people are making business decisions. This is important. If you're at the keyboard typing away, writing some software and that last function just won't work because of this problematic workaround to it, just cut the feature. It's too hard to do; just change the feature to the way you want. If it doesn't comply with some stupid law, whatever, that's somebody else's problem. Businesspeople, at the same time, don't tell people how much stuff is worth. Insist on that you know the price. And we had talked about that. Make sure you're telling people what their estimates are, so...
\n\nWILL: I will say, I think, it's really important to make sure you go up the entire chain to product if you want to do something like what color should this button be, or the copy should it be, like, select, or okay, or see all. I'm going to need to check in with marketing, sales. I can't make that decision on my own. I'm just an engineer. I got to have sign-off from VP of marketing on what the okay button text should be. What is the design thing? Should it be white or off-white? I don't know. These are critical questions. Completely above my pay grade. I can't use common sense. I'm an engineer. I'm half autistic, you know what I mean [laughs]?
\n\nDAVE: I have worked at a shop where the art team would hand us comps, and they had to be pixel-perfect, or they would just stop the whole team. It's like, "No, no, you rounded this button with a three-point fillet, and I specifically specified a 3.5." Yeah, I can slice pixels. I don't like it, but I can do it because I had to do it.
\n\nMIKE: Well, if you really want to make sure your project gets done on time, you don't want to ever have your developers idle. So, make sure you get them started working on the project immediately while you're gathering the requirements.
\n\nDAVE: Maximize utilization. Absolutely.
\n\nMIKE: Absolutely.
\n\nDAVE: Absolutely.
\n\nMIKE: It might take you several months to get the requirements for the project. So, you need to make sure that they're really busy working so that when you get those requirements, they already have most of the work done.
\n\nEDDY: You know you're being efficient when you're reverting a bunch of the work you're doing because you're releasing a lot of code.
\n\nDAVE: I may have put that on a pull request this week. I love it when I can add features by deleting code, yep.
\n\nKYLE: [laughs]
\n\nDAVE: I think it was yours, Eddy. I think it was your PR that I did that on, so...yep.
\n\nWILL: I'm not going to lie. I actually...
\n\nDAVE: It wasn't your code that we were reverting. For anybody listening, it was some legacy code that was no longer relevant, so...
\n\nWILL: Anyway, I don't know, like, unironically, not devil's advocating, I like just sort of getting to work, you know what I mean?
\n\nDAVE: It's very satisfying.
\n\nWILL: I like the aspect of, like, well, just agile sprinty. I mean, unironically, I'm not being the devil's advocate. Let's just throw something up and let people look at it, not release it. But it's like, "Here. Do you like this?"
\n\nSo much ambiguity can be resolved by giving somebody something that they can touch and feel and put their hands on. I'm no longer being ironic. I like giving people prototypes, and they can click the buttons and be like, "Oh yeah, it clarifies so much." I don't know; I've found there's, generally speaking, a difficulty among people who haven't sort of managed a lot of software projects to think about things in a fully fleshed-out way in the abstract. If I showed you a form, and a button, and a widget, and a web page, even if it's connected to nothing, I can get much better feedback, much faster, you know what I mean? I like that.
\n\nEDDY: I would argue that's part of your UX design person. It doesn't really fall on the developer.
\n\nWILL: You go to war with the designers you have, man. They're art school kids. Like, that's not their gig. It's okay. They're going to make it look good. That's their job. Like, I don't know, if I can make it easier, if I can work harder technically to get a better product, then I'm going to do that, and I'm not going to complain too much about it. Like, that's my job.
\n\nMIKE: And, unironically [chuckles], right? I agree with you. I was thinking of an example of, you know, go spend three months working on backend without requirements, without providing a single prototype. And yes, I've seen that kind of thing happen [chuckles] in the past. And it goes about as well as you'd imagine. The [chuckles] services you're building don't match what's actually required because you need to do...to your point, Will, again, unironically, that quick feedback is so critical that if you can't loop on it, it's terrible, which is a good reason to build out one small domain out of your project first so that you can have something that actually works.
\n\nWILL: Yeah, yeah, that is an important caveat. I would say that this is kind of frontend only. You can't show your VP of sales a slick API. I don't know who the VP of sales is, but I have a pretty clear idea of, like, that is some slick JSON, you know what I mean? [inaudible 28:00]
\n\nMIKE: [laughs]
\n\nWILL: But you can show people interfaces. And if you show people a frontend, you know, the backend exists to serve the frontend. Like, the backend is your problem. Get the dorks on it. Anyway.
\n\nDAVE: There's a web mockup tool that was designed...it's called Balsamiq. And I don't know if it's still like this. I haven't touched it in years. But when it first came out, it looked like napkin sketches. Like, on your computer screen, it would draw somebody with a ballpoint pen on a napkin, and they did it very deliberately.
\n\nAnd I have had this happen to me where you mockup a quick prototype, business looks at it, and they go, "That's great. Ship it." You're like, "No, this is literally a prototype. There's nothing wired behind this. This is 4% of the system." And they're like, "That looks like 90%. Ship it. You've got a week," and you're like, "No."
\n\nAnd so, Balsamiq literally shipped sketch stuff to stop that, to let the businesspeople understand that this is nowhere near complete. And it's related to what you were just saying, Will. I think knowing your trade-offs is super important. There's a time when you want to spike, and there's a time when you want to just knuckle down and trudge. And we've got good estimates, and we think we're right, and there's a lot of work to do. Let's sled along on this, or let's...versus jumping in ahead and working on the wrong things, but, spikes, sure. And they do happen frontend, backend.
\n\nI have literally spiked a mockup of an entire website, full-stack, database to frontend with just Rails, generate, generate, generate, generate, in a car on the way to an investor meeting, because my boss had said, "No, we're not switching to Rails. We're not switching to Rails". And, in the car, he's like, "How long would it take?" And I'm like, "Probably mock it up in the car." And he's like, "No, you can't." I'm like, "Bet." And I did. And so, we switched to Rails.
\n\nBut that spike there was nothing shippable in that spike. I built it to throw away. It served its purpose, which was to say, "This is possible. This legacy codebase that we spent five years building, here's the prototype. And based on the prototype and our existing codebase, I'm thinking 18 months." So, I was able to give him a realistic estimate off of it. So, knowing where your trade-offs are, I think, and --
\n\nEDDY: If that doesn't tell you how powerful Rails is for a start-up company [laughs], I don't know what does [laughs].
\n\nDAVE: To be fair, this was Rails 3.0 when you could still write a blog in 15 minutes on it without having to know Stimulus and a front-end packer, and a pixel shipper, and the, you know, the asset poop line, and all that messy stuff, so...
\n\nMIKE: So, if I'm going to go...I'm going back into the snark.
\n\nDAVE: Yes.
\n\nMIKE: Advanced warning [chuckles]. One great way to make sure that a project gets done on time is to bring in as many teams as possible. But make sure they work independently and never coordinate with each other because you wouldn't want them to have any inefficiencies of communication. Also, let them design the interfaces independently, and then we can just fix that communication layer at the end because that's not the important part. The important part is that we all make sure that they're all working, and they're all heads down. We can handle any and many communication issues later. Make sure the APIs are in line. That's not a big problem, right?
\n\nDAVE: Yes.
\n\nEDDY: Well, if you want a way to speed up your service, just don't write tests.
\n\nDAVE: Oh yeah.
\n\nEDDY: Just ship your code.
\n\nDAVE: Fair point. Yeah. And there's a generic form of that, which is never check your work, right? Never cross-check. In fact, we should put that as part of the waterfall. Make sure coding is 100% done before you start debugging. That's literally part of the original SDLC when they were saying, "Stop doing this."
\n\nEDDY: Yeah, also, let your developers be the sole QA. That's good, too.
\n\nDAVE: Make sure your creators are editing at the same time that they're trying to create.
\n\nEDDY: 100%.
\n\nWILL: I mean, software QA exists. The entire career exists because I cannot be trusted.
\n\nMIKE: [laughs]
\n\nWILL: That's it. That's it. There's nothing a QA can do that I can't and don't. You cannot trust me. I cannot be relied upon. Like, I can't do it. You can't, like, jump. Oh, wait, wait. Hang on. No, no, hang on. I said that wrong.
\n\nDAVE: You got it backwards, yeah. How dare you be candid?
\n\nWILL: Bro, why do you even have a QA? Devs know how it works. Like, they understand it better than anybody. QA is just a waste of time. Like, you have an extra person? They don't even know how to code, bro. Like, What? Why even? It's a nonsensical position to have. Like, the devs could do it. They did it. Just shut your work, guys, duh.
\n\nDAVE: If they can't code, we could have them doing tech estimates for us, though. There's that option, so...
\n\nMIKE: [laughs]
\n\nEDDY: And you can have your product guys go ahead and help you commit a bunch of stuff. When you're short-staffed, you know, just rely on other departments.
\n\nDAVE: Yep. We talked a little bit earlier about Fred Brooks, about how many women and da da da da. Fred Brooks wrote a book called "The Mythical Man-Month" that's all about this. And Brooks' actual law that he quotes is, "Adding people to a late project makes it later."
\n\nEDDY: It's true.
\n\nDAVE: That's where it comes from, yeah.
\n\nWILL: And I'd say another note on QA. I'd say the best people to do the QA are the high-level executives when you're doing your demo, your final presentation, preferably even after it's already been out to production and you got your VP out there.
\n\nDAVE: [laughs]
\n\nWILL: They're pretty loose people. Like, they're not detail-oriented. They don't have real visions. And even if they did, they found something; it's not like you're going to look like an idiot when your VP of product is checking stuff in prod, and your links are broken. And, honestly, those guys, they don't even notice half the time. They're just like [inaudible 34:30], whatever. They're just so chill. They don't even care.
\n\nMIKE: They don't have any relationships outside of your business either, right? And they're too busy working with people in the company. They don't have the CEO of your partner's company on their speed dial because, yeah, they don't have time for that. There's no way anybody would ever, you know, important business partner would ever reach out to them at 3:00 in the morning wondering why the service is down. That's just not their job.
\n\nEDDY: You know, one way to really ramp up the way wave to meet the deadline is to just ship it, even if it's broken. You met the deadline. Just merge --
\n\nDAVE: Yeah. We can ship DLC later.
\n\nKYLE: I've got a controversial one, I think.
\n\nDAVE: Oh, please.
\n\nKYLE: DevOps is a culture, not a team. I've seen where, you know, that's on the developer. They can do their own DevOps and manage their own infrastructure. And --
\n\nDAVE: It's called DevOps for a reason, Kyle. We're the devs. We do the ops.
\n\nKYLE: Yeah. So, we don't need a specialized team for any of that.
\n\nDAVE: Yeah. And all you need to know as DevOps is just chmod A plus X minus R. Just go nuts, just 777 for the entire hard drive. Yeah, it's fine.
\n\nWILL: It's called CI/CD, bruh, continuous deployment. I'm just going to throw that thing up. New endpoint? I don't know. There's probably no scaling requirements. The server was fine before. I'll just throw this new API up there. Let's roll, YOLO.
\n\nDAVE: Ooh, related to this, Mike's going to wince a little bit, but don't do any tech debt. If your CI machine catches on fire, get some marshmallows. That's the best thing you can do for it, yeah. So... [laughs].
\n\nEDDY: Well, you don't have tech debt if you just delete [laughter] [inaudible 36:16] you've broken.
\n\nDAVE: Mike is covering his mouth. There may have been an incident at work this week, so...
\n\nEDDY: You can't have [inaudible 36:36] that's broken, Dave. You just delete the code.
\n\nDAVE: That's right.
\n\nEDDY: Just delete it. It's not broken no more.
\n\nDAVE: Yep. Actually, touching on what Kyle said about DevOps, if you really want to mess everybody up, divide your company horizontally. Make sure that the database team are in their own spot, servicing all the database clients, because then you've got all your experts in one place. And anybody that needs anything from the database team now has to go up through their boss and their boss, and then come down through the data management people, and they've got objectives that they need done. Same thing with your sysadmin, same things with your DevOps, same things, you know, if you've got anybody that's writing backend and frontend, get them on separate teams. Whatever you do, do not under any circumstances have a full cross-functional product team.
\n\nKYLE: I think another good one is launch your service or whatever deliverable you have before you consider security.
\n\nDAVE: Yeah. Yeah. Yeah, you can just bolt that on later, come on. There's no security. That mockup that I showed you that, you said, "Ship it," and gave me a week; we can just do security later. It's fine. 100%.
\n\nEDDY: Mockups don't have permissions. Dave, are you crazy? You don't need to scope permissions to your users. Just whatever --
\n\nDAVE: If you can see the mockup, you can access the thing, yeah.
\n\nMIKE: You'll never have a user who will try changing the URL to see, you know, another user's data. Our users are never clever like that.
\n\nDAVE: Ooh, slightly related to that, I'm not sure how to phrase this, but as you're developing, if you trip over something, don't flag that. Just step over it every single time. Definitely don't put rules in your engine. Don't write an RSpec thing to check to make sure that there's no implicit scopes or default scopes on your Rails models. And you want default scopes everywhere. You want to tenant your customers at the default scope. That's really, really important --
\n\nEDDY: Make sure you unscope, Dave. Like, that's –-
\n\nDAVE: And then, what you'll also do is you'll have your scope that says, "Valid," which is going to select for things that have not been deleted so that then when you say "Unscoped," we throw away the deleted at so that you can pull all the records, and we also throw away the tenanting. And now you're looking at every single customer in the system. I had that happen at a company where showing somebody else somebody else's data involved federal oversight. Like, you messed up. There was a department that you had to report to and say, "We did that."
\n\nEDDY: I was going to say, Dave, that's kind of oddly specific [laughs].
\n\nDAVE: And if you press me further, I will deny it, yep.
\n\nEDDY: [laughs] [inaudible 39:13]
\n\nDAVE: I've never worked with an entire company full of idiots. I self-select out of that environment. I've seen all of these design...most of us have, right? All these design hell problems, and they usually come about based on really good partial information.
\n\nEDDY: I was going to say, something that can really speed up is just always, always, always going against your framework's convention. Like, it works 100% of the time.
\n\nMIKE: Well, I can one-up you there. You want to get out quickly. You don't have to deal with the constraints of a framework. So, make sure you implement from scratch because, that way, you can...
\n\nDAVE: Roll your own.
\n\nMIKE: Yeah, roll your own. That way, you won't have to memorize the conventions. You won't have to deal with, like, libraries that will fight back against you when you're trying to do direct database manipulation. Just build everything yourself. It's a much faster way to work.
\n\nDAVE: This week, I am maintaining some code that has some custom snippets of SQL wrapped up in a custom DSL that are wrapped up in the source code. And it's just a joy to work with. It's absolutely fun. I have not ripped out any of my fingernails. I have not shaved my head defensively to save tufts of hair from being ripped out. It's, yeah, it's just been a dream, absolutely a dream. So...
\n\nEDDY: You know, another thing that's helped me, Dave, and I want to say, like, [inaudible 40:41] loading has been wonders. Like, you want me to ship something? Yeah, copy and paste someone else's work, you know, that's done before. It doesn't matter if it's being used in that context or not. Just [inaudible 40:53] is always --
\n\nDAVE: Yes, going back to the good intentions, end up in hellish places; drying things up to the point that they become chaffy is fantastic. You should compress everything and especially, you know, that SQL DSL that I'm working on, get into RSpec, and there's an include, not, like, include shared context. It's an include module, and the module was in the support directory. And I opened that up. And when you include the module, it creates a shared context and includes it. And the shared context creates lets. I have told that nightmare story here at work multiple times, thinking certainly that I would never see it. We saw it this week, so it's pleasant. It's kind of fun.
\n\nEDDY: Mine is a controversial one.
\n\nDAVE: I will say that I am sincerely saying that I'm enjoying working on this because I feel a little bit vindicated when I work on it. Also, in defense, because I did actually say something about a real company that is doing real work, and I don't want to get yelled at for this, I do want to point out that the developer who did it that way did it in 2015 when it was a best practice. I've written a lot of code that had shared context and riffling the deck to shuffle all the pieces so that they, like, laminates on an overhead projector with multiple layers to make them line up and that kind of thing.
\n\nIt's very satisfying to dry that up in your text editor because you've got it all in your head, and you're like, oh, yes, why should I duplicate this? Let's put this over here. It's not until you come back later that you realize that you have just burned off every entry point for intuition and for someone else to be able to follow your path.
\n\nMIKE: I was thinking about a real-world story as well about avoiding the framework. I'm going to go back a lot farther, I think, like, 2003 [laughs]-ish.
\n\nDAVE: Ooh, okay. So, probably not Rails. It might have been Rails, but probably not Rails.
\n\nMIKE: Not Rails. I don't think Rails was out there. Anyway, this was actually some sort of Visual Basic. I don't remember the exact flavor of it. And there was no database library used whatsoever. It was all just raw rights to the database. And it only takes one unsanitized database input. It only takes one to lose a million dollars [laughs] of your customer's money.
\n\nEDDY: Yeah. Just don’t --
\n\nDAVE: What's the .NET... .NET has a SQL thing, like linker, SkLink. There's a name for it. But yeah...that would've been coming into existence about two years after 2003. So, yeah, if you're going to write SQL, it's going to be in the code. It's going to have to be in the code.
\n\nMIKE: This is back...I remember Hibernate was just getting started in the Java world and, like, wow, this is great. You can use some library and convention to write your SQL rather than hand-coding it all [laughs], but not so in the application that we took over [laughs].
\n\nDAVE: Oh, never switch. There's some people on this call that are going to feel seen and attacked at the same time, but this is actually not. But if you're going to add a new technology, add it. Don't change the existing stuff. You want people to have to maintain both. It's even better if they don't know which one they're working on until it's too late. That's a good one.
\n\nMIKE: As many text stacks as possible?
\n\nDAVE: Mm-hmm. Mm-hmm.
\n\nEDDY: Ship --
\n\nDAVE: For real, I used to walk into stand-ups...if I wanted to terrify everyone, I would give my stand-up report as, "So I did a quick spike, and I rewrote this in Rust." And, if you can sell that with a straight face, you can get, like, the blood to drain out of other people's...they're like, "You're doing what?"
\n\nMIKE: [laughs]
\n\nEDDY: Also, make sure you support multiple versions. I think that's --
\n\nDAVE: Oh.
\n\nMIKE: Simultaneous.
\n\nDAVE: Arbitrarily, arbitrarily. Don't just do it for the interface stability reasons. Do it arbitrarily.
\n\nMIKE: Well, if you don't have three versions of bootstrapping in your codebase, you're not a real project.
\n\nDAVE: What are you doing right? Yeah, and Angular 1 to Angular 2, they redesigned everything. So, you're going to need both, or you're going to be missing stuff out.
\n\nEDDY: It's a good thing that you can't support multiple versions of Ruby, though, like, satire aside, right? Like, you can only have one true Ruby version for the project. You can't support multiple. Is that correct? I see you smirk, Dave. Like, I wonder [chuckles], is that possible?
\n\nDAVE: It's absolutely possible. Like, Ruby 1.0 shipped with a library, dRuby? Distributed Ruby. And it made remote procedure calls very, very easy. You could write your program in two places. And if they knew how to find each other, you could call the function here, and execute it over here, and send it back, and nobody uses it. It was an interesting experiment, and nobody uses it. But 100%.
\n\nAnd, honestly, we do this here, where we've got service-oriented architecture. So, this team is on one version of Ruby, and this team is struggling because they've got this really important science library or finance library that isn't up on the latest. So, they have to stay back on an old version. Yeah, you do see that. So, what you have to do is you have to get out of the processor. You can't share memory with each other. I'm not going to say that super confidently. Somebody will say, "Here's a proof of concept."
\n\nMIKE: [inaudible 46:34]
\n\nDAVE: But, to my knowledge, if you're going to have multiple versions, they're going to have to drop to a protocol and communicate with each other like separate programs.
\n\nEDDY: Not ideal.
\n\nMIKE: We've come up with a lot of great ideas. I think that we could come up with an estimate that's pretty much whatever we want.
\n\nDAVE: We might be able to bring down the whole system.
\n\n[laughter]
\n\nEDDY: I was going to say something controversial, but some people may or may not agree, really just depends on your perspective. But I was going to say, as a satire, make sure you always do integration tests, and use factories to make sure you're testing the real data so that it gets committed to your database, but --
\n\nDAVE: And committed without any trade-offs.
\n\nEDDY: But I feel like some people do agree with that, and that's an interesting [laughs] topic.
\n\nDAVE: As long as you're ignoring your trade-offs so that you've got your test where you need to go really, really fast, as long as they're writing to disk and doing everything slow, and exercising the full-stack, and the stuff where you just need to test an accessor method that doesn't even talk to anything else that should be talking to the database, too, then, yeah, you'll be fine. You'll be fine.
\n\nMIKE: Well, you need to make sure that everything works, right? So, make sure --
\n\nEDDY: Make sure you test Ruby and Rails, too, like --
\n\nMIKE: Well, yeah, you can't trust the framework, and you definitely can't trust your third parties, so make sure that you make live API calls to their sandbox in your integration, you know, in your CI environment.
\n\nDAVE: Oh, yeah. If you come up with a workaround to a problem, solve it as far up the tech stack as possible. Like, I worked with an engineer who would recompile Ruby to add features to it, and we set him straight pretty quickly because [laughter] we're like, "We're not shipping your copy of Ruby to all of our servers. It's not happening. Stop asking." To be fair, he was a genius. He could shatter a human mind at 50 paces just by thinking about it, and he was very, very, very clever, and sometimes he was too clever for all of our good, so...
\n\nKYLE: I'd say –-
\n\nDAVE: I had a funny idea for how to end this podcast, which is to say, "Okay, now we estimated this much time," and then cut off right in the middle of the sentence, just no outro.
\n\n[chuckles]
\n\nEDDY: Kyle, you were going to say something?
\n\nDAVE: Sorry, yeah.
\n\nKYLE: I was just going to say, and don't worry about the performance of your code. We can always throw more hardware at it.
\n\nDAVE: Right [laughs].
\n\nEDDY: It's your computer that's slow, dude, [inaudible 49:11] [laughs].
\n\nKYLE: And we can ship that into the cloud if we need to.
\n\nDAVE: Yes.
\n\nEDDY: Develop to the cloud; it has unlimited resources.
\n\nDAVE: And I will see you in raise. You should care about maximizing performance at the start.
\n\nMIKE: Yes [laughs].
\n\nDAVE: You want to make the code as hard to read and as difficult to maintain as early as possible. And unrolling anything that's readable into something that's just hyper-efficient, go for it. That way, you're guaranteed to optimize things that aren't important. So, we will still need to scale up into the cloud to get around all the bottlenecks that we didn't even look at.
\n\nMIKE: And make sure that you do lots of planning around that optimization during the beginning of your waterfall process.
\n\nDAVE: Yes.
\n\nMIKE: Because that's what's going to matter the most is that optimization.
\n\nEDDY: I was going to say one thing, too. I was going to say, don't add comments and be super brilliant to what you're doing, so it's complicated for everyone else.
\n\nDAVE: Yes.
\n\nEDDY: So that you --
\n\nDAVE: Never ever pave a path through the code. You need to vanish into the jungle and be lost without a trace. Anybody who needs to follow you needs to solve it from first principles. That's important. It builds character.
\n\nEDDY: 100%. Like --
\n\nDAVE: And you need to prove your worth.
\n\nMIKE: So, if you don't have tricky code to read, well, then you're probably doing it wrong, right? I mean, how smart are you if everybody can read what you're writing?
\n\nDAVE: Yeah. We can go into a whole tangent about, like, your ego is more important than right and wrong, and that should be protected at any cost.
\n\nKYLE: I think one thing that goes really good on readability is the largest PRs as possible.
\n\nMIKE: Oh yeah.
\n\nDAVE: Definitely.
\n\nMIKE: You wouldn't want to waste time with QA having to review a bunch of small PRs. So, make sure you release the whole feature in one, that way, they can just test it once –-
\n\nKYLE: Save testing time.
\n\nEDDY: And test in production. That's the best way --
\n\nKYLE: Oh, that's the best one. Yeah, we can go to production first.
\n\nDAVE: Yes --
\n\nEDDY: Who better to tell you that your feature sucks than actual users, you know what I mean?
\n\nDAVE: I have a suggestion for a good final one, which is, if you're listening to this podcast and you think we're making fun of you, ignore it. It's fine. Don't take any lessons away from this. Remember to just stick by your guns, no matter what. Nobody has done any of these things in real. We're not talking about you; it's fine. Yeah, definitely don't take a hint from this to maybe try to improve steadily and stably. If you are going to react, make sure you overreact. I think that's the important takeaway here.
\n\nMIKE: We'll take the same advice because, of course, we've never run into any of these things ourselves.
\n\nDAVE: Mm-mm. Mm-mm. That's fantastic. Are we at a good stopping point, gentlemen?
\n\nEDDY: I think so.
\n\nDAVE: This has been a lot of fun. Thank you, guys, for coming out: Mike, Kyle, Eddy. Will had to drop off for a family issue. But so glad you guys came out. This was a lot of fun. And thank you all for listening and watching The Acima Developer Podcast. We'll see you again in a couple of weeks.
","summary":"","date_published":"2024-09-18T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/675c8758-3a76-4bb7-b6bc-e89c4c315415.mp3","mime_type":"audio/mpeg","size_in_bytes":32818314,"duration_in_seconds":3150}]},{"id":"caf4731c-2d29-4a96-82cb-6b2f38f63dac","title":"Episode 54: Monoliths vs Microservices","url":"https://acima-development.fireside.fm/54","content_text":"In this episode of the Acima Development Podcast, Mike kicks off the discussion with a few personal stories before diving into a technical debate. He recounts his recent epic hike in the Rockies with his son, which turned into a grueling trek due to altitude sickness. He also shares a nostalgic memory of visiting the massive Edmonton Mall in Canada as a teenager, noting the stark contrast between the pre-internet shopping experience and today's online marketplace like Amazon. The conversation then shifts to a comparison of governance structures in various countries, which sets the stage for the episode's main topic: software architecture and the debate between monoliths and microservices.\n\nThe panel explores the evolution of software architecture, with a focus on the trade-offs between large monolithic systems and distributed microservices. Mike and the others reflect on how early approaches to software development often favored building large, cohesive systems, but over time, the trend shifted toward breaking these systems into smaller, independent services. They touch on the challenges of communication and synchronization among microservices, and some express a sense of regret over the movement toward extreme modularity, suggesting that, while microservices have their advantages, they can introduce significant complexity and overhead when overused.\n\nThe conversation also delves into the practicality of maintaining and managing distributed systems, particularly from a DevOps perspective. The panel discusses the fine balance between creating boundaries in code and allowing flexibility for different teams to work on separate components. There is consensus that, while microservices can improve scalability and modularity, they can also lead to what one panelist dubs \"micromonoliths\" if not properly managed. Ultimately, the panel agrees that the choice between monoliths and microservices depends on the specific needs of the system and the organization, underscoring the importance of choosing the right tool for the job.\n\nTranscript:\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm hosting today. We've got a great panel with us here today. We've got Will, Eddy, Adam, Dave, and Kyle. And today...well, I'm going to hold off on what we're talking about. I'm going to give three stories; three things to start us off. \n\nWILL: [laughs]\n\nMIKE: But the first one is a story. I'll start there. So, last week, I was on vacation, drove out west, saw the Rockies, went on a, I'd say, an epic hike, which is true, but it was also just, like [laughs], in some ways, a brutal death mark hike [laughs]. Went on a hike with my oldest son, and we did, like, 8,000 feet of elevation gain, and, like, 20 miles, like, 16-hour hike, just a big, brutal hike. \n\nLoved it, but it was tough, particularly because we got up to the high elevation, and my son got altitude sickness, and he was just sick. I'll spare you the details, but there were some digestive issues going on that were serious [laughs], and that cost us quite a bit of time [laughter]. And he was not having a good time. Everything's fine. We got down to a lower elevation, and he felt a lot better. \n\nAnd it was great, I mean, the view was amazing. Didn't see very many people. It was a gorgeous hike, but [laughs] it was rough. We've been back home this week, and he's been doing some online classes, but, in between, he's been running up and down the stairs for exercise. So, like, you know, go one flight of steps up, and I think he's been doing 60 times up and down the stairs, seeing how low of time he can get it, and no altitude sickness [laughs]. It's working out better for him. So, there's my first story. \n\nSecond story, when I was a kid, and this was a long time ago, I went up to the Edmonton Mall up in Canada. I think it's the largest mall in North America. And I don't know how old I was, like, 14? So, I'd say it was a long time ago. So, I really can't speak to them now, but I can when I was 14. It was this huge mall, and there were several stores. There was, like, three of that store within this mall. It was so big that there was, like, a region where you go to a store and then go to another region of the mall and go to the store again. And you just get lost in this place [laughs]. \n\nI don't know how many, you know, fast food places they had. I remember there's some places that had at least three stores. It was crazy. And they have, like, an indoor amusement park, and water park, big mall. And, you know, thinking about the era that I'm talking about, that was, like, the pinnacle of shopping experiences because you could get all the places, you know, all the stores in one place. Since that time, times have changed. That was pre-internet era. \n\nWell, now, if you want to go to something similar, you just pull up your phone, and you go to Amazon, right [chuckles]? Not that people don't still go to the big mall in Canada; I'm sure they do. And they probably enjoy that experience, but they probably lean more into the experience part of it, your amusement park and water park. Because you go to Amazon, instead of having everything in one place, they have their little stores all over the world, right? \n\nAnd by distributing that work, and just making it a central, like, bazaar, you know, where you come and see all the stores in one place, you get way more selection. And the world's kind of fallen for it. We're not going to debate the pros and cons of Amazon here [laughs] [inaudible 03:54] that they have been widely embraced, that they have been widely embraced with that different model.\n\nThird story. And this one is not so much a story as a comparison. Let me talk a little bit about governments. Now, in most large...I say most, I'm going to mention the United States and the European Union. You do have a central federal government, but you also have a contentious group of states within that central government that don't always agree and regulate themselves internally. And sometimes it works, sometimes it doesn't, but [laughs] it does allow for some local rule and for those independent states to run things, you know, to their own liking. And then, they federate for the big decisions that need to be made together.\n\nThere are nations that don't work that way. I was thinking about Saudi Arabia. Very much, we've got a monarchy [laughs]. We say what you do, and that's it. The interesting thing about that, though, is it's not like those fractious internal debates don't happen in Saudi Arabia. If you read anything about the internals of the ruling family there, it's scary [laughs], murderous sometimes, and I don't want to mess with that. So, it's not like those fractious internal debates go away. They just get handled very differently when you've got kind of a monolithic rule, which brings us to the topic of our discussion today. \n\nWe're going to talk about software architecture and about monoliths versus microservices. This has been an ongoing discussion for a long time now in the community. It used to be kind of everybody went the [inaudible 05:33] think [laughs]. You'd build a big thing and then deal with it. And people start saying, \"Well, no, big is bad. We need to have lots of small things.\" And then, some people pull back and say, \"Well, no, maybe big wasn't so bad after all because there's a lot of issues with communication among lots of small services and keeping those all in sync.\" \n\nI brought up a few examples outside of the software world to give us some fodder to chew on, and I'm going to start off by just asking you all in this spectrum, saying, hey, you know, putting everything in one big application versus breaking everything up into small apps. Where do you stand? Where do you think that right balance should be? \n\nTAD: Can I get a definition of what you would say a monolith is and a microservice? Because I remember way back when we were just...everything was services, and then this huge trend came along of, oh, what if we made, like, really, really small, very, very narrow services and did everything with Sinatra and never touch Rails again because it's too big and bloated? So, what makes something a microservice, versus a service, versus a monolith, versus anything? \n\nMIKE: There you touched it, right [chuckles]? I used the word spectrum deliberately [laughs] because I don't think that anybody has a perfect definition there. And you could certainly, say, \"Hey, we're going to have an architecture where there's no service that has more than one end point.\" Sure, right? I don't think most people would like that. Just going out on a limb --\n\nDAVID: It's arbitrary. That feels like an arbitrary decision, right? \n\nTAD: Well, I've seen that. I've seen places that they're like, oh, we're going to have a routing number validation service. We're going to have a credit card validation service. We're going to have, for any particular thing that you need to do, you've got a service that you hit. And it's divided up amongst...it's almost like functional level [laughs] services. \n\nMIKE: But how did it work? [inaudible 07:43]\n\nTAD: Not great. Not great. You can probably tell that I'm like...every time I hear the word microservice, I just [vocalization] shudder and just, I don't know. \n\nWILL: So, one, I feel like a monolith versus microservices architecture it's like pornography, you know what I mean, it's hard to define, but you know when you see it. And, two, and what I've seen, I have some direct experience, and then I have received...maybe a year and a half, a year, year and a half ago, there was this top-down mandate at the large electronics retailer that I work for that all of the teams are going to be cross-functional teams, right? So, they said like, \"Nah, we're not doing monoliths. Everybody's doing everything,\" right? \n\nAnd almost immediately, all of the cross-functional teams immediately spread out into their, you know what I mean, on a micro level, so instead of having a team of mobile developers, or a team of backend developers, or a team of frontend developers, everybody sort of split out and said, \"All right, I know how to do the mobile app stuff, so I'll do mobile app stuff. You know how to do back-end stuff, so you'll do back-end stuff. And you know front-end stuff, so you'll do front-end stuff.\" And everybody just sort of self-organized into their silos of choice. \n\nAnd even if it was one giant repo with one giant Windows desktop application, right? Like, if you had a team of developers...and they will naturally, instinctively, like honeybees, self-organize into functional groups. It's like how even if you have an open seating plan, everybody will kind of pick a chair, and they will sit in their chair automatically. And they will get familiar with this one siloed piece of the codebase because it takes time to boot up. And so, it's an emergent sort of organizational thing. Microservices will happen instinctually. And they're like, oh, maybe we don't have separate GitHub repos. Even if it's all in just one big pile, humans will instinctively do that, you know what I mean?\n\nMIKE: I think that there's a lot of truth to that. Well, we have limits as to what we can fit in our brains [chuckles]. There's finite limits to human capacity to think through a problem, to think through some domain within a problem. And once something gets outside of that space, you know, once it outgrows that, it becomes really hard to think about. And, you know, you probably have to map something out and think about sub-pieces of it. So, you just naturally look at sub-pieces of it.\n\nAnd there's a few ways to approach that. You can have it within the same repo, right? Not the same repo but the same application. You deploy it all together. And then, you have, you know, lots of units, functional units within a single codebase, or you can just blow it up and have separate, you know, fully independent. If you're out on the web, if you have the advantage of doing so, you can have all these separate units, you know, deployed separately, managed separately. You don't even have to think about the other ones, except via API. And really kind of harden those boundaries to where, you know, you only talk to each other via API. \n\nAnd by enforcing that, now you don't even have to think about those other things, maybe [laughs]. Maybe you don't have to think about them. And I think that's kind of the microservices or the, you know, the small services advocates would say, \"Well, yeah, no, you should definitely make a hard boundary. That way, you're not tempted to cross those boundaries.\" Where people who've seen that go too far tend to say, \"Well, you know, maybe we can maintain boundaries in code, and we don't have to put it, you know, deploy separately.\" You're saying, \"Well, this happens automatically.\" And I think that there's a lot of truth to that. Do you think there's value in hardening those boundaries to enforce an API?\n\nWILL: You know, if I'm being totally honest with you, what I see, like, the difference between sort of a monolith versus a microservice thing is, I see it as analogous to sort of serial versus parallel programming, right? So, with serial programming, you do it right, and then if you do everything right in a row, procedural, like, tick, tick, tick, tick, tick, tick, you know? Add it all up in a line, and then there's my result. I return my result, and I'm good. But it's not as fast. It's not well, you know, broadly. \n\nLike, if I want to write some slick parallel algorithm thing, that's a harder job to do. But you can get that 16 core, you know, server. You can keep them hot, and that's great. But it takes higher skill. And so, similarly, the spectrum you're choosing your path on in terms of microservice versus monolith, if you have a monolith, you're leaning really, really hard as things get bigger. As the monolith becomes larger, you're leaning really, really hard on super high-skill, super domain knowledge engineers that can wrap their heads around everything and understand how to deal with the monolith without knocking it over. Because we think of it like a pyramid, but really, it's like a pillar just swaying in the breeze.\n\nAnd so, when you go over to the microservices thing, then you're leaning on sort of managerial organizational capacity to manage this sort of 16 core. Instead of 16 core CPU, you've got 16 dev engineering team. And you need to make sure that everybody is coordinated and pulling in the same direction and all those things. And so, that's sort of the spectrum. Like everything in engineering, it's not good versus evil, angel versus devil things. It's just sort of where are you on that spectrum, and what's the right tool for the job for where you are right now? \n\nDAVID: And, Mike, you mentioned at the top of the call you were talking about monoliths versus services and whatnot. And do we sit down and write a big thing? And I think, no, when you start out, you always write a small thing that, you know, every monolith started out small somewhere. And, for me, it's always down to a trade-off, right? If you've got services, you now have very expensive communication between those services. But the things that are in those services are now decoupled, which is nice. \n\nIn a monolith, the communication between them is very fast and very easy. I just want to look at that module, just go look at that module. The drawback is that if that other module wants to look into your stuff, they can just do it because they're inside the firewall, and so there's that coupling back and forth. \n\nSo, I made a laundry list as you guys were talking. Tad, you mentioned definition of microservices. What I saw in the teens, the last decade, was a lot of people doing like, oh, monolith's bad; SOA good. And what they went out and wrote was every service was its own monolith. It's like, oh, instead of having one, you know, 100,000-line code base, you now have 500,000-line codebase. This is not moving in the right direction. \n\nTAD: Now you've got two problems.\n\nDAVID: Now you've got two problems, exactly. And so, yeah, every problem in computer science can be solved with another server in the microservice cluster, except for the problem of too many services in the cluster. And I heard a really good definition of what a microservice is, and that is something that you could rip out and rewrite in two weeks. And I've never [laughter] seen somebody write...yeah, exactly. That is the correct reaction. And if you're saying, \"We're doing microservices,\" and your services are all 30,000 lines and have 73 models, those are not micro. You couldn't rip them out and rewrite them. \n\nThe interfaces between things are very expensive. Well, they're much more expensive because you have to negotiate with both sides, and, often, there's, like, three or five different deploys that you have to do to make it possible, and then use it, and then require it, and da da da. And you have to work out that dance. And if you need that secured, and hardened, and guaranteed, then you want that to be formal. You want it to be in a service. So, you want it to be locked down on a contract. But if it's fluid and it's flowing, you're just paying through the nose for something that you could have spiked out with an agile team overnight. But now it's a six-month initiative because you made it as expensive as possible. \n\nEDDY: I'm actually curious to hear this from a DevOps perspective. Do they prefer to maintain microservices over a monolith? \n\nDAVID: Do we have DevOps on...Kyle?\n\nKYLE: Yeah, I was going to say, at least from my perspective, I'm all about orchestration tools, and something like Kubernetes is extremely powerful. So, I would much prefer a microservice, but I do feel like we've kind of talked about it. A lot of microservices end up being micromonoliths, is what I've called them in the past. And it's still one of those things, smaller units that can be divided out. And then, it's, at what point do you continue to divide? Because you can have quote, unquote, \"microservices,\" or you can go [inaudible 16:54] the functions because there's stuff like AWS Lambda or serverless, right? So, at what point do you stop...each rendition complicates the next one. With functions, at what point do you keep them hot? Because that's something with Lambdas. \n\nOriginally, they weren't kept hot, so you had to wait for them to spin up and be able to function; now, they have hot functionality, and the same thing with even running microservices on servers. You have to have hot servers. Otherwise, you're waiting to deploy. And then, you go to the smaller units, at least in my experience, and you've always got that one server that you can deploy to because it's always up. But you start going out. It is nice in the sense that you can divide your workload amongst smaller machines and cut costs and stuff that way at times. But that's a long way of me saying it really depends on the implementation, I guess. I prefer microservices, but not to an exaggeration. \n\nEDDY: So, micromolothiths.\n\nWILL: Well, I always felt like, from a DevOps perspective, you've got really heterogeneous workloads, in that you've got boxes that are like, okay, I'm doing this thing. I need this amount of stuff. And I have other things that, like...and so, the more heterogeneous jobs you have running on the same machine, I feel like, correct me if I'm wrong, because this isn't really my trade, right? It's like, it makes it hard to correctly provision a machine. Because it could be doing anything under the sun, then you have to create a larger machine, larger buffer because the workload could widely vary. \n\nKYLE: Yeah, yeah. And even within inside of our company, we've got services that are doing different things that are different sizes. And we will make it so that they won't land on the same nodes as themselves or the other large services, and sometimes we don't even want some of the small services to land on there. And kind of what you're talking about, we do have more general-type workload servers, along with we have more scheduled workload like our data science teams, where they've got crons that sit there and run more so than anything, maybe serverless is what it would be closer to, where it's just very spiky workloads. It's just, throughout the day, just bam, bam, bam. And, like you're saying, those need very different machines to support them. \n\nWILL: Right. Right, yeah. \n\nDAVID: One of the things about Kubernetes and Docker—and its predecessor Vagrant, and Chef, and Puppet—this idea of, like, oh, you say you're doing microservices, but you need an entire operating system now? Your microservice needs...you got to configure how many CPUs it has? That's not a microservice anymore. If you need to install Ubuntu, all of Ubuntu [laughs], to run your service, it's not a microservice anymore. \n\nWILL: I don't think I track.\n\nDAVID: Oh, just something you can rip out and rewrite in two weeks. Oh, but you're going to do a Docker container. So, you have to provision an entire operating system drive space. That used to be called full-stack dev. And it's like [crosstalk 20:17]\n\nWILL: And maybe I don't understand because, like, I don't know, I'm stupid, you know what I mean? I thought Docker was cool. I was like, oh, I could just do a Docker. Like, I'll fill up a pod, and I don't have to do a full-on EC2 install. This is so great. What should the microservice, I mean, if it's a proper microservice, how should we be doing it if not [inaudible 20:38] a Docker image? [inaudible 20:40]\n\nDAVID: I want to be careful to not walk into the trap of proper because I think the way we do it now is kind of proper. But 15 years ago, all the hardware in the colo was the same. Like, everyone had the same processor. Everyone had the same hard drive. And everyone would say, \"Can I please have more RAM on the server?\" And ops would say, \"No, you can't have another gig of RAM because another gig of RAM on your box means we have to provision every machine in the colo. It's a 20 million upgrade.\" And Docker gets us away from that. And I'm 100% on board that that's a feature. \n\nI'm just saying when I see Docker scripts where it's like, okay, yeah, well, let's go get this thing, oh, and now let's download Python and patch it, and da da da da, and it all becomes part of the entrails that are actually part of what you're working on, suddenly, it's very, very complicated. \n\nMike, you mentioned story time at the top of the hour, and there was a specific story that I think is actually relevant to this. When I was at a company that shall remain nameless because I might still have friends there and I want to keep it that way, they wanted to do a big push for SOA. And we had over 700 separate services at one point, and it was trending up. So, when I parted ways with the company, it was 700 different services, and there was incredibly painful fatigue around adding a new service. Like, if you wanted...oh, I want to do a new service to this thing. You would get...like, everyone would just automatically just...\n\nSorry, Eddy just asked in the chat, \"What is SOA?\" service-oriented architecture. So, take your monolith. Instead of a single architecture, it's spread it out. And then, most people, when they do SOA, they'll take...instead of doing micro, they start tiny, but they get bigger and bigger and bigger. And then, you've got complexity inside each of these distributed services. So, that's where that came from. We had 3 different services that were putting records into the God record, right? Every startup has that one table, right? For us, it's like the contracts that we do. And in a medical company, it'll be your prior authorization request, that kind of thing.\n\nAnd we had three separate services that were creating new items, new documents, which they needed to create, and I can't remember...they could not just stick it in the database and read it back to find out what the primary key was. They were, like, physically disconnected from each other, which means they had to come up with primary keys without colliding with each other. And for whatever reason, it wasn't GUIDs. So, these services had this...I want to point out this was in the last 5 years of my life or 10 years of my life, and I've been here for 4, last 10 years of my life. \n\nEvery time you created one of these documents, it would try to insert, and then we'd go, did it work? Uh, no [laughter]? That primary key was taken? Okay. Here's a new one. Does it...no? Okay. And, yeah, and it was fun because we were running out of key space. We had meetings about exhausting the key space. We had used all of the keys randomly through the entire search space. We had over 50% of them, and so we had this system that would retry 5 times, and it was failing 0.01% of the time, then 0.02%. And we're like, you know what? We're going to retry six times. We're like, this is not solving the problem. We are running out of places to randomly roll dice and try to hit a blank spot somewhere in the key space. \n\nWILL: [laughs]\n\nDAVE: It was a nightmare. And so, I came in and I said, \"Guys, this is the textbook example for a microservice,\" a random number generator that can look at the database and see, is it colliding? No, no, it's not. Great. Oh, and, by the way, we could make the random number generator deterministic. They couldn't have ordinal because they were worried about ID prediction attacks. So, they had to be random. \n\nAnd so, yeah, little microservice. It was five lines of code, baby. Fantastic. And everybody would talk to this to get their primary key and insert it in the database, and it was guaranteed to be available to them. Life was good. And everyone dug their heels in and said, \"No. No more new services. No more.\" And I'm like, primary key on your God object table, if there was a reason for a microservice, this is it. And because we get away from why are we doing this and into this is the right way to do it, we stuck to the doctrine rather than to the principle. And, hmm, yeah, good times, good times.\n\nMIKE: So, they'd done so many microservices that people refused to do another one, even when --\n\nDAVID: Yeah, there were over 700. Somebody came back from DEF CON...I won't name names, but his initials are David Brady. He came back from DEF CON...I told my team, \"You got to see some of this stuff.\" And I started talking about war gaming and red team versus blue team, and, you know, what's our disaster recovery. And the company was in the process of getting a second data center. So, all of a sudden, we went from 700 servers to 1,400 servers because we had to duplicate everything. And the war game plan was, if this colo gets nuked from orbit, we have to be able to fail over to this one. It was a nightmare.\n\nAnd it took over a year to get to a point where we could get everyone together, and we had a war game night. And it was literally when traffic died down on Saturday night. We all lined up, and we started...we basically simulated an outage as politely as possible. We let everybody shut their services down politely so that you didn't have to do data recovery on the restart. But we took everything down out of the Atlanta data center and started bringing everything up in the Chicago data center, and those war games took 9 hours. We started at 6:00 p.m. And we figured this will probably go till midnight. No, it took till 4:00 a.m. It was a nightmare.\n\nAnd the plan was to bring it down, move it over, bring it up, test it, bring it down, come [inaudible 26:17] back. And once we got up on the new data center, we were, like, \"This is our new primary data center. Nobody ever move this again.\" And, a year later, they said we needed to war game again. So, every year, that company swaps data center. I don't know if they're still doing it that way, but that's...yeah. So, too many...literally, just the act of saying, \"Where is the next service going to be?\" It gets expensive. And it's a low exponent, but it is exponential. And if you get enough, that line will start to curve up on you.\n\nMIKE: Well, I think that your story captures something, and it's been touched on a few times in this call, and it goes to the idea of coupling. If your services are tightly coupled, you have not separated out your system. You've just made the same system with a more challenging interface. I've heard it put that a tightly coupled system that's distributed is just a distributed monolith. \n\nDAVID: I like it. I like it. \n\nMIKE: You've got all of the problems of both monolith and a distributed system. And the coupling there is, I think, absolutely the key. If you can't have one of those services go down, then you haven't really extracted it. Anything that's a single point of failure is not really meaningfully extracted. It might as well be inside your system because you depend on it just as much as you did internally. And you have all of the cost of network overhead, and managing that service, and everything else that is involved in the cognitive overhead of having that separate. You really haven't separated it out. \n\nThere are tools, though, I mean, you can have...if you build your system right, you can, many times, have a service that can go down and nobody notices [laughs]. I mean, hopefully, you're monitoring it, and you notice, but the other services can keep running. And there's challenges there. You have to have some data redundancy. You have to have, you know, whatever. It's very situational-dependent, right? So, I'm not even going to drill into that. \n\nDAVID: So, kind of a weird...I was reading on some stuff on how Amazon did their architecture way, way back when. They did things in Lisp because they had a bunch of crazy gearhead PhD doctorate candidates that loved to do stuff in Lisp, which is wildly inefficient, but they were writing this highly distributed, super scalable system, right? And it was because they had everything super, super tiny. The weird thing that they said that I have taken away and I just keep it in my back pocket...and I've forgotten the why. So, I'm going to throw this out there undefended and let you guys just pick it apart. And anybody listening to this can pick this apart but just think about it.\n\nWhen you're building two Rails models, if you do a belongs to in one direction, it's just instinctive, right? You automatically go to the other one and create a...if it belongs to, then you go to the other one and do a has many, right?\n\nTAD: Has many. Sure. \n\nDAVID: Yeah, and the guy that was writing the...I want to say this was the microservices book that came out of Amazon from this guy. He said, \"Resist that temptation.\" Bidirectional communication in CS is often ten times harder than single direction. And he gave a very specific example that if your customer has a shopping cart, okay, if customer, you know, has shopping cart, that's great. If I want to pull up your order page, I have to loop in the customer server, and I have to loop in the shopping cart page. But if it's bidirectional, then if you turn around and you look at the leaf node, as long as you know the customer name or stuff that you can go look up later, that's fine. \n\nBut if it's indexed and it requires this thing to be in the other present, like you said, you now have just duplicated monoliths. You have to have...that's what it was. He was specifically talking about having a database where you might have shopping carts and no customers. Like, you literally don't have customers in that database. You have to go to the service to get it. \n\nBut in the other system, the customer is there, and the shopping carts are there because they're linked, and they have to be efficient. So, that was the rule that I tried. It's like, I try not to just immediately do...and I want to say we actually have a RuboCop rule that says, if you put the one side in, always put the other side back in. And that's not always a bad idea, but it's not always a great idea. \n\nTAD: I think it's pretty surprising to not have bidirectional stuff. Like, if you encounter something, you assume that that relationship goes both ways. So, -- \n\nDAVID: I could give you a better example. If you want to...so, we do leasing here, for those listening online. You need the customer record in order to service the lease. If you're in the call center, you need the lease, and you need the customer. But if you are at the contract origination system, you don't need any of the servicing stuff on the account because the account has...but you do need the customer information. And that was where the argument was. \n\nAnd I agree with you that if you're down over in the servicing side, it should probably be bidirectional because you always need both. But if you're at the other end, single point, and that was the guy's push, was, like, by default, go single directional until you need bidirectional. And I've been caught in the neck with, you know, it's like, I just need this item, and it's over here, but there's no way to propagate. And so, you have to do a refactor PR to add that, so... \n\nTAD: Well, I could understand you don't want to load everything up, but it seems surprising to me that you wouldn't want both things to know about their relationship with each other. \n\nWILL: I'm with David. I'm with David. I'm strongly with David because, like, I don't know whether you guys saw the lightbulb turn on, right? Because one of the easy patterns that I've seen in this sort of database-centric things, I mean, we talked about a Rails application, but there are many where the lines of ownership get really muddy because you can get to anywhere from anything. And you'll find these situations where you'll get sort of, like, hop ons, right?\n\nA better thing is I do have this sort of aggregator object. I've got, let's say, a lease, and I have things attached to a lease. Or I have a customer, and I have things attached to a customer. And it promotes very clear lines of ownership, where if I've got a customer that, I can get what I need from the customer. Or I have a lease, I can get what I need from the lease.\n\nA way to visualize the thing that I'm thinking about, at least, is, like, think about an unstructured graph and traversing this unstructured graph where things can just go topsy turvy, any old place, versus a tree where I go from the node, and I could go to the leaves, but I don't go up, right? There are no cycles in this graph. And think about sort of traversing and just writing sort of traversal algorithms on an extremely structured tree, where it has rules, and the rules must be followed, like a bee tree or whatever. \n\nTAD: But doesn't a tree have a node? Like, the parent node knows about its children, and the children know which node they belong to. \n\nWILL: It depends on the tree, [inaudible 33:13]\n\nTAD: It seems super weird to me that a leaf, you can say like, \"Who's your parent?\" And it says, \"Oh, that guy.\" But I can ask that guy, and he's like, \"I don't have any kids. I don't know of any relationship to my children.\" That just seems really surprising to me. \n\nWILL: I'm thinking about really sticky, complicated, little data graphs, data associations because I've seen, I don't know, I've seen them go off the rails, where there are all these things snarled up together because there isn't clear ownership. There's not a clear, I am the container node that everything sort of spins around. And what I'm thinking about specifically is these situations where you need to put in...so let's say I want...I want to make a service call, and I have to attach a bunch of different extraneous stuff to my thing because it's like, oh, well, I have the shopping cart. \n\nThe shopping cart has orders, but I have to have the customer because the customer has the rewards account index, right? So, I can give them their rewards points. And then, I have to have the associated store because the order is going to be fulfilled from their preferred store. And you get all these things that are just sort of, like, there isn't a reason that they all have to go together, but because these things have not been organized...and, I mean, I don't want to be, like, I'm not a zealot on this. But, as a rule of thumb, making things a one-way hop, unless there's an overriding need for it not to be, that's really compelling as a guiding principle. \n\nDAVE: I may have explained it poorly. Actually, I may have achieved exactly what I said when I started this story, which is I'm defending this poorly, and so it'll start discussion on it. But yeah, it's interesting to kind of push and think about, like, if you've got literally two services, one for orders and one for customers, one of them needs to know about the other one, but the other one might not always need to know, and that's, yeah, even though they do always have that relationship, yeah.\n\nMIKE: Well, I think that's actually kind of important. Let me take your idea a little further. Let's say you have customers, and you've got leases, and you've got locations, and you've got merchants, and you've got shopping carts, and you've got, you know, any number of things. I think that if the customer has to know about all of those things, then it's just a big ball of mud. You've got all of that complexity tied up in the customer. But if you have a customer and it's just customers and your shopping cart is in some other service that handles shopping carts, and they have a reference back to the customer, so they know who the customer is. \n\nBut the customer knows nothing about shopping carts. Doesn't have to know a thing about shopping carts and doesn't even have the ability to look it up because he doesn't know about shopping carts and doesn't have to. But your customer stays simple, and you don't have to deal with that complexity. Shopping cart knows what the customer record is and could look it up if it needed to, right? But that's a one-directional relationship, and it doesn't need to be otherwise.\n\nAnd where those shopping carts are very ephemeral, right? I mean, they come into existence; they pop out of existence; you have many, many of them, and they really have nothing to do with the core idea of the customer, that actually disentangles, I think, your architecture dramatically. And when you have all kinds of things, you know, and I could probably come up with 100 things that need to reference those customers, if the customer has to know about all of those, then your customer gets extremely complex, where I think that you haven't really decoupled, unless the customer doesn't have to know, right?\n\nYou've got something that maintains, here's your customers. And somewhere in a data warehouse, you can map everything together, right? Or maybe even in the frontend, you have some ability to tie things together because you can make the, you know, you can [inaudible 36:56] backend and put things together. But I don't think that whatever is holding, you know, managing your customers should know about what payment you made, you know, what your payment method was that was used three days ago. It gets entangled with something that has nothing to do with that. And that's the idea, I think, in the best sense of what Dave is trying to say.\n\nDAVID: I think I might see a distinction here as well that if you talk to the entire system, you're going to have to know about both and the system output. But if you want to have a conversation about shopping carts, you can't just go talk to the customer service. You have to go talk to the shopping cart service. It's allowed to talk to customer, so there's that direction. But the other direction, there's no link. There's no way to link customers down to their shopping carts because that service is whittled down and kept very, very small. That's the piece that, at the system level, you absolutely can go both directions. I'm not saying sever the link in one way. I'm just saying this particular tiny service we sever it just for that service. \n\nWILL: Well, I like this shopping cart customer kind of thing, right? Because there's a clear ownership thing, right? Customer has a shopping cart, right? But maybe case study, like, what I'm imagining here. It's like, okay, I've got, let's say, I'm trying to do some new feature from this shopping cart, and I want to go out, and I want to say, \"Based on the stuff you've bought, I'm going to machine learning up some things so that when you're in your shopping cart, I can show you some other stuff because you've got cash in hand.\" And I'm like, okay, I got a hot buyer. Let me see if I can upsell them on some stuff based on the things that I know about them. \n\nAnd so, then as developers start developing out the feature, then you start to tunnel through the shopping cart, then through to the customer, and then through to their purchase history. And now you're going from this shopping cart thing, and you're tunneling through, and you're getting into all this other stuff, which is like, whoa, whoa, whoa, whoa, whoa this is a little bit, you know, this is a little funky, and now you're sort of injecting these dependencies by going through the path of least resistance. Like, I have a shopping cart. I'm checking out, right? \n\nSo, rather than pulling in the stuff maybe kind of a top-level way, you're side-loading this relationship, and you're using that to tunnel your way through the system to avoid doing it on a straight-up way, where it's like, hey, I want you to, like, you know, like, you're bringing in a shopping cart, and I want you to bring in some recommendations for me, you know what I mean? Is this analogy coming off the rails? I'm freestyling a little. \n\nTAD: I think what I'm kind of thinking about now is, I think that you need to know the relationship, but you also need to respect the relationship, meaning Eddy and I are coworkers. And he's like, \"Hey, let's go for pizza,\" or something like that, and I'm like, \"Hey, yeah. Can I borrow some money? [laughter]\" He'd be like, \"Sure,\" right? \n\nBut if I reach into his pants and pull out his wallet [laughter] and then grab that money out of his wallet, I've violated that relationship, right? I think it's important that I know like, oh, Eddy and I...Eddy is someone I could borrow money from, right? But if I'm going past that interface of that relationship, I'm violating the boundaries of that relationship. So, I think, that's kind of how I'm seeing it right now. \n\nWILL: Well, yeah. I think we're all seeing it. I think we actually are vigorously agreeing because, like -- \n\nDAVID: Yeah, violent agreement, yeah. \n\nWILL: We all understand that this is maybe a guideline, but not a hard and fast rule, which is why it would be totally fine. And you were like, \"Hey, I need to borrow a couple of bucks for lunch.\" And Eddy was like, \"Yeah, yeah, yeah, just go grab my wallet out of my jacket. It's over there,\" right? Like, obviously, that's not a blank check to just get into Eddy's pockets anytime you'd like, but, like, reasonable people can make exceptions. \n\nAnd the thing that I like about not doing these bidirectional relationships by default is it sort of puts guardrails on the relationship where you need to do it on purpose. Like, I'm doing this on purpose because these things are so coupled, and I actually think shopping cart to customer might be. In the end, it might be one of those such tight relationships, where it's like, yeah, we should probably go both ways. \n\nMIKE: Well, it depends on your business.\n\nWILL: Yeah, exactly. But, on the other hand, I don't trust you guys with nothing. Like, a big piece of my life is just hiding the sharp objects from the junior developers. \n\nEDDY: Jeez, well, I don't know, man, if someone's reaching into my pocket, I want to be able to reach into theirs, too, you know?\n\n[laughter] \n\nDAVID: That's a bidirectional relationship, yeah [laughter]. \n\nTAD: That's a violation.\n\nWILL: [laughs] \n\nDAVE: I just want to say I'm so happy to be on this call with y'all and to not be the person who launched the sentence about reaching into somebody else's pants. That's normally Dave Brady brand but thank you. You did give me a...I'm sorry, go ahead.\n\nMIKE: If HR might need to get involved, then it's a violation of best practices. \n\nDAVE: Yes. Yes. \n\nWILL: That's why I work remote, man.\n\n[laughter]\n\nDAVID: I had a light bulb moment when we were talking about this, that if customers and shopping carts are coupled...and stop me when you've had this...we've had this pain. Everyone in this room, I'll wager...I know, maybe not Will, and maybe not Kyle. I don't know how much coding you're doing lately. But everyone else on this call, I know you've had this problem where it's like, oh, I need to, Will talked about the shopping cart, I need to calculate the shipping and, in order to calculate shipping, I need to know how many boxes and how big the items are. So, what boxes so that I've got to do the packing on it, and then I need the weight on this.\n\nWe can go to a shipping calculator. It needs to know what state we're going to send it to, and that's going to come from the customer. But other than that, the shipping service doesn't need to know anything about the customer. It just needs...and, honestly, the only thing it needs to know from the shopping cart is what items are in it. It needs an inventory list. \n\nAnd if you can say, \"Here's the state, and here's the list of items,\" that service now doesn't need to know anything about the shopping cart or the customer. But we've all written specs, where you're like, okay, I want to do this. Oh, I need...this is a shopping cart. Oh, I need a merchant. Okay, in order to have a merchant, I need a location. And to get a location, I need a merchant, to get a merchant...oh, I need the legal paperwork that says, \"The merchant has been onboarded and has signed the paperwork.\" Because they're a valid merchant, they're supposed to go through the system, so they're going to be checked at every point. \n\nEDDY: You don't have to worry about that if you use factories, Dave. \n\nDAVID: Right? Exactly. Exactly. So, just, you know, we'll just do everything with factories, put it all in the database. And do you want half-hour spec suites? Because this is how you get half-hour spec suites [chuckles]. \n\nWILL: And also, the other thing about shipping is like, maybe it's not for me. And I also said it, like, because I could speak as a large electronics retailer. We do a lot of shipping, and let me assure you, shipping is much more complicated at the state. There's lots of places [inaudible 44:17] you can get stuff the same day, and there's a lot more places in Utah you cannot [laughs]. Like, my dad lives in Michigan, but he lives in the part of Michigan where Prime is not a thing. You'll get it next week, period [laughs]. \n\nDAVID: The last mile problem we were all talking...like, in 2008, we were talking about the...whoever solves the last mile problem...this is before Uber existed, right? I might have that year wrong, but, you know, before Uber existed, solving the last mile problem was the reason why there were only three big, you know, FedEx, UPS, and DHL were it for shipping stuff, and now it's all super federated, and everybody's distributed.\n\nI tracked a package on Amazon yesterday, and I saw a new status update, which said, \"Delivery appointment scheduled,\" And I'm like, \"What?\" I'm used to carrier picked up package, package in transit, received at facility, left facility, you know, out for delivery. That's all you need. And, all of a sudden, we've got a delivery appointment. And I'm like, somebody's working on that last mile problem, and it's not well...what is it? The future is here; it's just not well-distributed, right? \n\nThere's still places...there's a place in Nevada that does not have cell phone services. There's only four pairs of copper going in and out of the town. Great Basin National Park, that's what it is. There's a little town there and a little national park. And yeah, I remember pulling in there, and I'm like, oh, my phone doesn't work. Let's have a modern horror movie now. We've now solved that problem. \n\nWILL: Yeah. I mean, Great Basin, I want to write that down. Like, I want to go camping. I only want to go camping places if there are no bars. \n\nDAVID: It's a...not to turn it into an ad for this, Great Basin National Park is a glacier in Southern Nevada, in the middle of the desert, right adjacent to the Mojave Desert. It's a glacier because it's on a great, big, volcanic talus cone. And you're just driving across the desert, and then, all of a sudden, there's this mountain sticking up out of nowhere, and there's a glacier on top of it. It's crazy. And Lehman caves, which is gorgeous, so...I may have vacationed there recently. \n\nWILL: I'm underlining it [laughs] --\n\nEDDY: So, I kind of want to...Sorry, Will. I just kind of want to go back to where we initially started. So, I guess, essentially, there is no rule of thumb to follow, right?\n\nDAVID: Maybe not a rule of thumb. Well, there's lots of rules of thumb. You just have to remember that they're all based on principles, right? You can distribute something. And if you distribute it in such a way that the distributed nodes have very slow communication between them, and they don't do very much communication, you're great. You can do all your high performance in your silos now, and everything's great. And if you do it wrong, you're going to take the high-performance stuff and then stretch it over a boundary, and now everything is over HTTP that used to be in the CPU cache. Ugh, been there, done that.\n\nWILL: I don't know, I've got a rule of thumb. I've got a rule of thumb in terms of, like, monoliths versus distributed services. And this is going to be on the record hot take right now: You should keep it as monolith for as long as possible.\n\nDAVID: I agree.\n\nWILL: Because, as I see it, the fundamental trade-off that you've got between monoliths and distributed services is you're levering engineering output versus sort of management and the ability to communicate, you know what I mean, to coordinate and keep everybody pulling in the same direction and keep the children from fighting with each other because it's just natural human nature. And, in the end, this is probably my engineering bias, but I've run into a lot more effective engineers than I have effective engineering leadership and [inaudible 48:12], you know what I mean? I see you, Kyle. You can hide behind your hand all you want, but I saw that [laughs]. \n\nEDDY: Isn't there a cost, though, to having a monolith, though? Like, if you say, like, \"Hey, no, like, I have a monolith that was the first service that we developed for their startup. It's been developed actively for 10-plus years,\" right?\n\nDAVID: Sure.\n\nEDDY: And you're like, oh, go and develop for this feature, right? Suddenly, isn't there, like, a higher ceiling to come in and get acquainted with, versus if it had a microservice, a true definition, to Dave's point, to a microservice, right? Wouldn't it be easier for you to hit the ground running because you know how to scope or comb through all this [inaudible 48:57]? \n\nTAD: Well, the company I worked for before, and it's out of business, but I won't say their name anyway, they had the entire company was an entire single Go codebase. And you're talking 60-70 developers all working on a codebase that has to compile. And so, every subdirectory had a README file, and it's like if you want to touch the code in this folder, you got to get sign-off from these three people [laughs]. \n\nDAVE: The stakeholders. \n\nTAD: And that's how they --\n\nWILL: Stakeholders, David, yeah.\n\nTAD: Like, took care of it. And it's like, oh my gosh, like... \n\nWILL: So, what you run into doing that stuff is you'll have these sort of rather than management fiefdoms, you'll have these engineering fiefdoms, where you have this increasing important hardcore set of engineers that know everything and everything has to run through them. It's just like parallel programming.\n\nTAD: Well, I'm just saying, like --\n\nWILL: People will max out, and you'll feel it, you know? \n\nTAD: It felt like the worst parts of a monolith, where I want to change these three files, therefore, I have to get, like, eight people to sign off on it. Oh, two of them are on vacation right now, well...Whereas if it were a single service with five people, any other four people on my team could probably sign it off, and we could roll it out that day, right?\n\nDAVE: Yeah. To Will's point, there's an agile principle, which is to try to defer your decisions as far as possible. The idea is to defer the decision to the point of maximum information because the information increases monotonically over time. So, if you make a decision early before you've got all the data in, and that decision commits you to a path, and then you find out you were wrong, it can get very, very expensive.\n\nIn SOA, once you split, if there's a decision that has to be made on both sides, that affects both sides, that's twice as...well, more than twice as expensive, probably four or eight times more expensive because they both have to change, and they both have to communicate. We've all had that thing where you have to do a tandem deploy because my service wants to change this, and it'll crash you if I do it before, and da da da, and that whole game.\n\nSo, to Will's point, yeah, I think you should start small and start monolith, until there is pressure to do. At Acima, we have a great, big monster service that has been calving icebergs off of it. It's not even a monolith now. It's a continent on it, and it's just, you know, calving little subcontinents across. And that's a great way to do it. I don't know if it's a great way to do it. It's exhausting, and it's painful. And we have architecture meetings every week where we scream about it. But it worked. It started small. It got big. It got too big, and then we broke it down. \n\nAnd if we had started out eight years ago breaking things into, okay, you're going to be this service; you're going to be that service...the first time we tried to change a low-level thing, like, the first time you try to move outside the United States to do business, and, all of a sudden, you need postcodes instead of zip codes, right? If you have to change that in every single service and there's validations that are hard that will crash your service if that's wrong, in every single service, it's going to be a nightmare. If it's a monolith, just update the zip code table, right? Just, right? Less expensive if it's all in one place. Yeah. \n\nTAD: How do you know when to start slicing off baby services from your service? Is it complexity? Is it team size? Like, what's your rule of thumb?\n\nDAVE: I let pain be my guide. Like, when something hurts long enough, when something hurts, I kind of make a mental note, and if it hurts twice or three times, I start going, maybe we should fix this, right? I personally am constantly driven to just polish out the tracks where I'm frequently going. So, if I'm doing something, like, pairing with somebody and I opened up a PR, and then I went back to my terminal, and I typed git set PR number, like, why did you do that? \n\nAnd I switched over on another branch, and I did git open PR. And it opened a browser to the pull request for that thing. And I'm like, well, it's because I wrote a little thing that ties branches to PR numbers. And I'm like, yeah, that's hard work to do that. I'm like, yeah, but it's really painful to not have this. And, for me, it was less painful to stay up over a weekend writing a little PR management, you know, a little number associator. \n\nWILL: I think if you talk to your senior engineers, you'd be like, \"What sucks?\" Like, everybody –-\n\nDAVE: You'll get answers [laughs]. \n\nWILL: Yeah. And they're going to be...I'm saying there's a whole, like, how do you chip away your icebergs? That's a [inaudible 53:56] question that we could spend a series of podcasts on. Honestly, I'm more interested in, how do you maintain the communication and collaboration among teams? Because I have seen the distributed services architecture is a tremendous leadership challenge. \n\nAnd I've seen so much just...we could just call it deadlocks, just like parallel programming. I figured it exactly like parallel programming and sort of deadlocks, and race conditions, and stuff like that with these sort of distributed things. It becomes a leadership problem. I mean, everybody knows the reasons why you should start branching out services, why you spawn a new threat. But how do you keep these things together? How do you keep the teams working with each other, right? \n\nDAVID: Let's do that next week. I think that could be a whole call. How do you keep parallel teams productive? Yeah. \n\nEDDY: I guess to kind of –-\n\nWILL: Absolutely. To keep people from fighting, you know, keep people accountable. \n\nEDDY: I guess the answer really is...it was a long-winded conversation to just say, \"It depends.\" \n\nDAVE: That's the other name of this podcast, a long-winded conversation to say, \"It depends,\" yeah.\n\nWILL: Well, yeah, I mean, it always does. There's no right or wrong in engineering. It's just the right tool for the right job. And, believe me, there can be a wrong tool for the job, and you're going to feel that [laughs].\n\nDAVID: Mm-Hmm. Cool. Well, we have lost our host. Mike got called out to a production issue. Thank you for listening and watching our podcast. We appreciate it.","content_html":"In this episode of the Acima Development Podcast, Mike kicks off the discussion with a few personal stories before diving into a technical debate. He recounts his recent epic hike in the Rockies with his son, which turned into a grueling trek due to altitude sickness. He also shares a nostalgic memory of visiting the massive Edmonton Mall in Canada as a teenager, noting the stark contrast between the pre-internet shopping experience and today's online marketplace like Amazon. The conversation then shifts to a comparison of governance structures in various countries, which sets the stage for the episode's main topic: software architecture and the debate between monoliths and microservices.
\n\nThe panel explores the evolution of software architecture, with a focus on the trade-offs between large monolithic systems and distributed microservices. Mike and the others reflect on how early approaches to software development often favored building large, cohesive systems, but over time, the trend shifted toward breaking these systems into smaller, independent services. They touch on the challenges of communication and synchronization among microservices, and some express a sense of regret over the movement toward extreme modularity, suggesting that, while microservices have their advantages, they can introduce significant complexity and overhead when overused.
\n\nThe conversation also delves into the practicality of maintaining and managing distributed systems, particularly from a DevOps perspective. The panel discusses the fine balance between creating boundaries in code and allowing flexibility for different teams to work on separate components. There is consensus that, while microservices can improve scalability and modularity, they can also lead to what one panelist dubs "micromonoliths" if not properly managed. Ultimately, the panel agrees that the choice between monoliths and microservices depends on the specific needs of the system and the organization, underscoring the importance of choosing the right tool for the job.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm hosting today. We've got a great panel with us here today. We've got Will, Eddy, Adam, Dave, and Kyle. And today...well, I'm going to hold off on what we're talking about. I'm going to give three stories; three things to start us off.
\n\nWILL: [laughs]
\n\nMIKE: But the first one is a story. I'll start there. So, last week, I was on vacation, drove out west, saw the Rockies, went on a, I'd say, an epic hike, which is true, but it was also just, like [laughs], in some ways, a brutal death mark hike [laughs]. Went on a hike with my oldest son, and we did, like, 8,000 feet of elevation gain, and, like, 20 miles, like, 16-hour hike, just a big, brutal hike.
\n\nLoved it, but it was tough, particularly because we got up to the high elevation, and my son got altitude sickness, and he was just sick. I'll spare you the details, but there were some digestive issues going on that were serious [laughs], and that cost us quite a bit of time [laughter]. And he was not having a good time. Everything's fine. We got down to a lower elevation, and he felt a lot better.
\n\nAnd it was great, I mean, the view was amazing. Didn't see very many people. It was a gorgeous hike, but [laughs] it was rough. We've been back home this week, and he's been doing some online classes, but, in between, he's been running up and down the stairs for exercise. So, like, you know, go one flight of steps up, and I think he's been doing 60 times up and down the stairs, seeing how low of time he can get it, and no altitude sickness [laughs]. It's working out better for him. So, there's my first story.
\n\nSecond story, when I was a kid, and this was a long time ago, I went up to the Edmonton Mall up in Canada. I think it's the largest mall in North America. And I don't know how old I was, like, 14? So, I'd say it was a long time ago. So, I really can't speak to them now, but I can when I was 14. It was this huge mall, and there were several stores. There was, like, three of that store within this mall. It was so big that there was, like, a region where you go to a store and then go to another region of the mall and go to the store again. And you just get lost in this place [laughs].
\n\nI don't know how many, you know, fast food places they had. I remember there's some places that had at least three stores. It was crazy. And they have, like, an indoor amusement park, and water park, big mall. And, you know, thinking about the era that I'm talking about, that was, like, the pinnacle of shopping experiences because you could get all the places, you know, all the stores in one place. Since that time, times have changed. That was pre-internet era.
\n\nWell, now, if you want to go to something similar, you just pull up your phone, and you go to Amazon, right [chuckles]? Not that people don't still go to the big mall in Canada; I'm sure they do. And they probably enjoy that experience, but they probably lean more into the experience part of it, your amusement park and water park. Because you go to Amazon, instead of having everything in one place, they have their little stores all over the world, right?
\n\nAnd by distributing that work, and just making it a central, like, bazaar, you know, where you come and see all the stores in one place, you get way more selection. And the world's kind of fallen for it. We're not going to debate the pros and cons of Amazon here [laughs] [inaudible 03:54] that they have been widely embraced, that they have been widely embraced with that different model.
\n\nThird story. And this one is not so much a story as a comparison. Let me talk a little bit about governments. Now, in most large...I say most, I'm going to mention the United States and the European Union. You do have a central federal government, but you also have a contentious group of states within that central government that don't always agree and regulate themselves internally. And sometimes it works, sometimes it doesn't, but [laughs] it does allow for some local rule and for those independent states to run things, you know, to their own liking. And then, they federate for the big decisions that need to be made together.
\n\nThere are nations that don't work that way. I was thinking about Saudi Arabia. Very much, we've got a monarchy [laughs]. We say what you do, and that's it. The interesting thing about that, though, is it's not like those fractious internal debates don't happen in Saudi Arabia. If you read anything about the internals of the ruling family there, it's scary [laughs], murderous sometimes, and I don't want to mess with that. So, it's not like those fractious internal debates go away. They just get handled very differently when you've got kind of a monolithic rule, which brings us to the topic of our discussion today.
\n\nWe're going to talk about software architecture and about monoliths versus microservices. This has been an ongoing discussion for a long time now in the community. It used to be kind of everybody went the [inaudible 05:33] think [laughs]. You'd build a big thing and then deal with it. And people start saying, "Well, no, big is bad. We need to have lots of small things." And then, some people pull back and say, "Well, no, maybe big wasn't so bad after all because there's a lot of issues with communication among lots of small services and keeping those all in sync."
\n\nI brought up a few examples outside of the software world to give us some fodder to chew on, and I'm going to start off by just asking you all in this spectrum, saying, hey, you know, putting everything in one big application versus breaking everything up into small apps. Where do you stand? Where do you think that right balance should be?
\n\nTAD: Can I get a definition of what you would say a monolith is and a microservice? Because I remember way back when we were just...everything was services, and then this huge trend came along of, oh, what if we made, like, really, really small, very, very narrow services and did everything with Sinatra and never touch Rails again because it's too big and bloated? So, what makes something a microservice, versus a service, versus a monolith, versus anything?
\n\nMIKE: There you touched it, right [chuckles]? I used the word spectrum deliberately [laughs] because I don't think that anybody has a perfect definition there. And you could certainly, say, "Hey, we're going to have an architecture where there's no service that has more than one end point." Sure, right? I don't think most people would like that. Just going out on a limb --
\n\nDAVID: It's arbitrary. That feels like an arbitrary decision, right?
\n\nTAD: Well, I've seen that. I've seen places that they're like, oh, we're going to have a routing number validation service. We're going to have a credit card validation service. We're going to have, for any particular thing that you need to do, you've got a service that you hit. And it's divided up amongst...it's almost like functional level [laughs] services.
\n\nMIKE: But how did it work? [inaudible 07:43]
\n\nTAD: Not great. Not great. You can probably tell that I'm like...every time I hear the word microservice, I just [vocalization] shudder and just, I don't know.
\n\nWILL: So, one, I feel like a monolith versus microservices architecture it's like pornography, you know what I mean, it's hard to define, but you know when you see it. And, two, and what I've seen, I have some direct experience, and then I have received...maybe a year and a half, a year, year and a half ago, there was this top-down mandate at the large electronics retailer that I work for that all of the teams are going to be cross-functional teams, right? So, they said like, "Nah, we're not doing monoliths. Everybody's doing everything," right?
\n\nAnd almost immediately, all of the cross-functional teams immediately spread out into their, you know what I mean, on a micro level, so instead of having a team of mobile developers, or a team of backend developers, or a team of frontend developers, everybody sort of split out and said, "All right, I know how to do the mobile app stuff, so I'll do mobile app stuff. You know how to do back-end stuff, so you'll do back-end stuff. And you know front-end stuff, so you'll do front-end stuff." And everybody just sort of self-organized into their silos of choice.
\n\nAnd even if it was one giant repo with one giant Windows desktop application, right? Like, if you had a team of developers...and they will naturally, instinctively, like honeybees, self-organize into functional groups. It's like how even if you have an open seating plan, everybody will kind of pick a chair, and they will sit in their chair automatically. And they will get familiar with this one siloed piece of the codebase because it takes time to boot up. And so, it's an emergent sort of organizational thing. Microservices will happen instinctually. And they're like, oh, maybe we don't have separate GitHub repos. Even if it's all in just one big pile, humans will instinctively do that, you know what I mean?
\n\nMIKE: I think that there's a lot of truth to that. Well, we have limits as to what we can fit in our brains [chuckles]. There's finite limits to human capacity to think through a problem, to think through some domain within a problem. And once something gets outside of that space, you know, once it outgrows that, it becomes really hard to think about. And, you know, you probably have to map something out and think about sub-pieces of it. So, you just naturally look at sub-pieces of it.
\n\nAnd there's a few ways to approach that. You can have it within the same repo, right? Not the same repo but the same application. You deploy it all together. And then, you have, you know, lots of units, functional units within a single codebase, or you can just blow it up and have separate, you know, fully independent. If you're out on the web, if you have the advantage of doing so, you can have all these separate units, you know, deployed separately, managed separately. You don't even have to think about the other ones, except via API. And really kind of harden those boundaries to where, you know, you only talk to each other via API.
\n\nAnd by enforcing that, now you don't even have to think about those other things, maybe [laughs]. Maybe you don't have to think about them. And I think that's kind of the microservices or the, you know, the small services advocates would say, "Well, yeah, no, you should definitely make a hard boundary. That way, you're not tempted to cross those boundaries." Where people who've seen that go too far tend to say, "Well, you know, maybe we can maintain boundaries in code, and we don't have to put it, you know, deploy separately." You're saying, "Well, this happens automatically." And I think that there's a lot of truth to that. Do you think there's value in hardening those boundaries to enforce an API?
\n\nWILL: You know, if I'm being totally honest with you, what I see, like, the difference between sort of a monolith versus a microservice thing is, I see it as analogous to sort of serial versus parallel programming, right? So, with serial programming, you do it right, and then if you do everything right in a row, procedural, like, tick, tick, tick, tick, tick, tick, you know? Add it all up in a line, and then there's my result. I return my result, and I'm good. But it's not as fast. It's not well, you know, broadly.
\n\nLike, if I want to write some slick parallel algorithm thing, that's a harder job to do. But you can get that 16 core, you know, server. You can keep them hot, and that's great. But it takes higher skill. And so, similarly, the spectrum you're choosing your path on in terms of microservice versus monolith, if you have a monolith, you're leaning really, really hard as things get bigger. As the monolith becomes larger, you're leaning really, really hard on super high-skill, super domain knowledge engineers that can wrap their heads around everything and understand how to deal with the monolith without knocking it over. Because we think of it like a pyramid, but really, it's like a pillar just swaying in the breeze.
\n\nAnd so, when you go over to the microservices thing, then you're leaning on sort of managerial organizational capacity to manage this sort of 16 core. Instead of 16 core CPU, you've got 16 dev engineering team. And you need to make sure that everybody is coordinated and pulling in the same direction and all those things. And so, that's sort of the spectrum. Like everything in engineering, it's not good versus evil, angel versus devil things. It's just sort of where are you on that spectrum, and what's the right tool for the job for where you are right now?
\n\nDAVID: And, Mike, you mentioned at the top of the call you were talking about monoliths versus services and whatnot. And do we sit down and write a big thing? And I think, no, when you start out, you always write a small thing that, you know, every monolith started out small somewhere. And, for me, it's always down to a trade-off, right? If you've got services, you now have very expensive communication between those services. But the things that are in those services are now decoupled, which is nice.
\n\nIn a monolith, the communication between them is very fast and very easy. I just want to look at that module, just go look at that module. The drawback is that if that other module wants to look into your stuff, they can just do it because they're inside the firewall, and so there's that coupling back and forth.
\n\nSo, I made a laundry list as you guys were talking. Tad, you mentioned definition of microservices. What I saw in the teens, the last decade, was a lot of people doing like, oh, monolith's bad; SOA good. And what they went out and wrote was every service was its own monolith. It's like, oh, instead of having one, you know, 100,000-line code base, you now have 500,000-line codebase. This is not moving in the right direction.
\n\nTAD: Now you've got two problems.
\n\nDAVID: Now you've got two problems, exactly. And so, yeah, every problem in computer science can be solved with another server in the microservice cluster, except for the problem of too many services in the cluster. And I heard a really good definition of what a microservice is, and that is something that you could rip out and rewrite in two weeks. And I've never [laughter] seen somebody write...yeah, exactly. That is the correct reaction. And if you're saying, "We're doing microservices," and your services are all 30,000 lines and have 73 models, those are not micro. You couldn't rip them out and rewrite them.
\n\nThe interfaces between things are very expensive. Well, they're much more expensive because you have to negotiate with both sides, and, often, there's, like, three or five different deploys that you have to do to make it possible, and then use it, and then require it, and da da da. And you have to work out that dance. And if you need that secured, and hardened, and guaranteed, then you want that to be formal. You want it to be in a service. So, you want it to be locked down on a contract. But if it's fluid and it's flowing, you're just paying through the nose for something that you could have spiked out with an agile team overnight. But now it's a six-month initiative because you made it as expensive as possible.
\n\nEDDY: I'm actually curious to hear this from a DevOps perspective. Do they prefer to maintain microservices over a monolith?
\n\nDAVID: Do we have DevOps on...Kyle?
\n\nKYLE: Yeah, I was going to say, at least from my perspective, I'm all about orchestration tools, and something like Kubernetes is extremely powerful. So, I would much prefer a microservice, but I do feel like we've kind of talked about it. A lot of microservices end up being micromonoliths, is what I've called them in the past. And it's still one of those things, smaller units that can be divided out. And then, it's, at what point do you continue to divide? Because you can have quote, unquote, "microservices," or you can go [inaudible 16:54] the functions because there's stuff like AWS Lambda or serverless, right? So, at what point do you stop...each rendition complicates the next one. With functions, at what point do you keep them hot? Because that's something with Lambdas.
\n\nOriginally, they weren't kept hot, so you had to wait for them to spin up and be able to function; now, they have hot functionality, and the same thing with even running microservices on servers. You have to have hot servers. Otherwise, you're waiting to deploy. And then, you go to the smaller units, at least in my experience, and you've always got that one server that you can deploy to because it's always up. But you start going out. It is nice in the sense that you can divide your workload amongst smaller machines and cut costs and stuff that way at times. But that's a long way of me saying it really depends on the implementation, I guess. I prefer microservices, but not to an exaggeration.
\n\nEDDY: So, micromolothiths.
\n\nWILL: Well, I always felt like, from a DevOps perspective, you've got really heterogeneous workloads, in that you've got boxes that are like, okay, I'm doing this thing. I need this amount of stuff. And I have other things that, like...and so, the more heterogeneous jobs you have running on the same machine, I feel like, correct me if I'm wrong, because this isn't really my trade, right? It's like, it makes it hard to correctly provision a machine. Because it could be doing anything under the sun, then you have to create a larger machine, larger buffer because the workload could widely vary.
\n\nKYLE: Yeah, yeah. And even within inside of our company, we've got services that are doing different things that are different sizes. And we will make it so that they won't land on the same nodes as themselves or the other large services, and sometimes we don't even want some of the small services to land on there. And kind of what you're talking about, we do have more general-type workload servers, along with we have more scheduled workload like our data science teams, where they've got crons that sit there and run more so than anything, maybe serverless is what it would be closer to, where it's just very spiky workloads. It's just, throughout the day, just bam, bam, bam. And, like you're saying, those need very different machines to support them.
\n\nWILL: Right. Right, yeah.
\n\nDAVID: One of the things about Kubernetes and Docker—and its predecessor Vagrant, and Chef, and Puppet—this idea of, like, oh, you say you're doing microservices, but you need an entire operating system now? Your microservice needs...you got to configure how many CPUs it has? That's not a microservice anymore. If you need to install Ubuntu, all of Ubuntu [laughs], to run your service, it's not a microservice anymore.
\n\nWILL: I don't think I track.
\n\nDAVID: Oh, just something you can rip out and rewrite in two weeks. Oh, but you're going to do a Docker container. So, you have to provision an entire operating system drive space. That used to be called full-stack dev. And it's like [crosstalk 20:17]
\n\nWILL: And maybe I don't understand because, like, I don't know, I'm stupid, you know what I mean? I thought Docker was cool. I was like, oh, I could just do a Docker. Like, I'll fill up a pod, and I don't have to do a full-on EC2 install. This is so great. What should the microservice, I mean, if it's a proper microservice, how should we be doing it if not [inaudible 20:38] a Docker image? [inaudible 20:40]
\n\nDAVID: I want to be careful to not walk into the trap of proper because I think the way we do it now is kind of proper. But 15 years ago, all the hardware in the colo was the same. Like, everyone had the same processor. Everyone had the same hard drive. And everyone would say, "Can I please have more RAM on the server?" And ops would say, "No, you can't have another gig of RAM because another gig of RAM on your box means we have to provision every machine in the colo. It's a 20 million upgrade." And Docker gets us away from that. And I'm 100% on board that that's a feature.
\n\nI'm just saying when I see Docker scripts where it's like, okay, yeah, well, let's go get this thing, oh, and now let's download Python and patch it, and da da da da, and it all becomes part of the entrails that are actually part of what you're working on, suddenly, it's very, very complicated.
\n\nMike, you mentioned story time at the top of the hour, and there was a specific story that I think is actually relevant to this. When I was at a company that shall remain nameless because I might still have friends there and I want to keep it that way, they wanted to do a big push for SOA. And we had over 700 separate services at one point, and it was trending up. So, when I parted ways with the company, it was 700 different services, and there was incredibly painful fatigue around adding a new service. Like, if you wanted...oh, I want to do a new service to this thing. You would get...like, everyone would just automatically just...
\n\nSorry, Eddy just asked in the chat, "What is SOA?" service-oriented architecture. So, take your monolith. Instead of a single architecture, it's spread it out. And then, most people, when they do SOA, they'll take...instead of doing micro, they start tiny, but they get bigger and bigger and bigger. And then, you've got complexity inside each of these distributed services. So, that's where that came from. We had 3 different services that were putting records into the God record, right? Every startup has that one table, right? For us, it's like the contracts that we do. And in a medical company, it'll be your prior authorization request, that kind of thing.
\n\nAnd we had three separate services that were creating new items, new documents, which they needed to create, and I can't remember...they could not just stick it in the database and read it back to find out what the primary key was. They were, like, physically disconnected from each other, which means they had to come up with primary keys without colliding with each other. And for whatever reason, it wasn't GUIDs. So, these services had this...I want to point out this was in the last 5 years of my life or 10 years of my life, and I've been here for 4, last 10 years of my life.
\n\nEvery time you created one of these documents, it would try to insert, and then we'd go, did it work? Uh, no [laughter]? That primary key was taken? Okay. Here's a new one. Does it...no? Okay. And, yeah, and it was fun because we were running out of key space. We had meetings about exhausting the key space. We had used all of the keys randomly through the entire search space. We had over 50% of them, and so we had this system that would retry 5 times, and it was failing 0.01% of the time, then 0.02%. And we're like, you know what? We're going to retry six times. We're like, this is not solving the problem. We are running out of places to randomly roll dice and try to hit a blank spot somewhere in the key space.
\n\nWILL: [laughs]
\n\nDAVE: It was a nightmare. And so, I came in and I said, "Guys, this is the textbook example for a microservice," a random number generator that can look at the database and see, is it colliding? No, no, it's not. Great. Oh, and, by the way, we could make the random number generator deterministic. They couldn't have ordinal because they were worried about ID prediction attacks. So, they had to be random.
\n\nAnd so, yeah, little microservice. It was five lines of code, baby. Fantastic. And everybody would talk to this to get their primary key and insert it in the database, and it was guaranteed to be available to them. Life was good. And everyone dug their heels in and said, "No. No more new services. No more." And I'm like, primary key on your God object table, if there was a reason for a microservice, this is it. And because we get away from why are we doing this and into this is the right way to do it, we stuck to the doctrine rather than to the principle. And, hmm, yeah, good times, good times.
\n\nMIKE: So, they'd done so many microservices that people refused to do another one, even when --
\n\nDAVID: Yeah, there were over 700. Somebody came back from DEF CON...I won't name names, but his initials are David Brady. He came back from DEF CON...I told my team, "You got to see some of this stuff." And I started talking about war gaming and red team versus blue team, and, you know, what's our disaster recovery. And the company was in the process of getting a second data center. So, all of a sudden, we went from 700 servers to 1,400 servers because we had to duplicate everything. And the war game plan was, if this colo gets nuked from orbit, we have to be able to fail over to this one. It was a nightmare.
\n\nAnd it took over a year to get to a point where we could get everyone together, and we had a war game night. And it was literally when traffic died down on Saturday night. We all lined up, and we started...we basically simulated an outage as politely as possible. We let everybody shut their services down politely so that you didn't have to do data recovery on the restart. But we took everything down out of the Atlanta data center and started bringing everything up in the Chicago data center, and those war games took 9 hours. We started at 6:00 p.m. And we figured this will probably go till midnight. No, it took till 4:00 a.m. It was a nightmare.
\n\nAnd the plan was to bring it down, move it over, bring it up, test it, bring it down, come [inaudible 26:17] back. And once we got up on the new data center, we were, like, "This is our new primary data center. Nobody ever move this again." And, a year later, they said we needed to war game again. So, every year, that company swaps data center. I don't know if they're still doing it that way, but that's...yeah. So, too many...literally, just the act of saying, "Where is the next service going to be?" It gets expensive. And it's a low exponent, but it is exponential. And if you get enough, that line will start to curve up on you.
\n\nMIKE: Well, I think that your story captures something, and it's been touched on a few times in this call, and it goes to the idea of coupling. If your services are tightly coupled, you have not separated out your system. You've just made the same system with a more challenging interface. I've heard it put that a tightly coupled system that's distributed is just a distributed monolith.
\n\nDAVID: I like it. I like it.
\n\nMIKE: You've got all of the problems of both monolith and a distributed system. And the coupling there is, I think, absolutely the key. If you can't have one of those services go down, then you haven't really extracted it. Anything that's a single point of failure is not really meaningfully extracted. It might as well be inside your system because you depend on it just as much as you did internally. And you have all of the cost of network overhead, and managing that service, and everything else that is involved in the cognitive overhead of having that separate. You really haven't separated it out.
\n\nThere are tools, though, I mean, you can have...if you build your system right, you can, many times, have a service that can go down and nobody notices [laughs]. I mean, hopefully, you're monitoring it, and you notice, but the other services can keep running. And there's challenges there. You have to have some data redundancy. You have to have, you know, whatever. It's very situational-dependent, right? So, I'm not even going to drill into that.
\n\nDAVID: So, kind of a weird...I was reading on some stuff on how Amazon did their architecture way, way back when. They did things in Lisp because they had a bunch of crazy gearhead PhD doctorate candidates that loved to do stuff in Lisp, which is wildly inefficient, but they were writing this highly distributed, super scalable system, right? And it was because they had everything super, super tiny. The weird thing that they said that I have taken away and I just keep it in my back pocket...and I've forgotten the why. So, I'm going to throw this out there undefended and let you guys just pick it apart. And anybody listening to this can pick this apart but just think about it.
\n\nWhen you're building two Rails models, if you do a belongs to in one direction, it's just instinctive, right? You automatically go to the other one and create a...if it belongs to, then you go to the other one and do a has many, right?
\n\nTAD: Has many. Sure.
\n\nDAVID: Yeah, and the guy that was writing the...I want to say this was the microservices book that came out of Amazon from this guy. He said, "Resist that temptation." Bidirectional communication in CS is often ten times harder than single direction. And he gave a very specific example that if your customer has a shopping cart, okay, if customer, you know, has shopping cart, that's great. If I want to pull up your order page, I have to loop in the customer server, and I have to loop in the shopping cart page. But if it's bidirectional, then if you turn around and you look at the leaf node, as long as you know the customer name or stuff that you can go look up later, that's fine.
\n\nBut if it's indexed and it requires this thing to be in the other present, like you said, you now have just duplicated monoliths. You have to have...that's what it was. He was specifically talking about having a database where you might have shopping carts and no customers. Like, you literally don't have customers in that database. You have to go to the service to get it.
\n\nBut in the other system, the customer is there, and the shopping carts are there because they're linked, and they have to be efficient. So, that was the rule that I tried. It's like, I try not to just immediately do...and I want to say we actually have a RuboCop rule that says, if you put the one side in, always put the other side back in. And that's not always a bad idea, but it's not always a great idea.
\n\nTAD: I think it's pretty surprising to not have bidirectional stuff. Like, if you encounter something, you assume that that relationship goes both ways. So, --
\n\nDAVID: I could give you a better example. If you want to...so, we do leasing here, for those listening online. You need the customer record in order to service the lease. If you're in the call center, you need the lease, and you need the customer. But if you are at the contract origination system, you don't need any of the servicing stuff on the account because the account has...but you do need the customer information. And that was where the argument was.
\n\nAnd I agree with you that if you're down over in the servicing side, it should probably be bidirectional because you always need both. But if you're at the other end, single point, and that was the guy's push, was, like, by default, go single directional until you need bidirectional. And I've been caught in the neck with, you know, it's like, I just need this item, and it's over here, but there's no way to propagate. And so, you have to do a refactor PR to add that, so...
\n\nTAD: Well, I could understand you don't want to load everything up, but it seems surprising to me that you wouldn't want both things to know about their relationship with each other.
\n\nWILL: I'm with David. I'm with David. I'm strongly with David because, like, I don't know whether you guys saw the lightbulb turn on, right? Because one of the easy patterns that I've seen in this sort of database-centric things, I mean, we talked about a Rails application, but there are many where the lines of ownership get really muddy because you can get to anywhere from anything. And you'll find these situations where you'll get sort of, like, hop ons, right?
\n\nA better thing is I do have this sort of aggregator object. I've got, let's say, a lease, and I have things attached to a lease. Or I have a customer, and I have things attached to a customer. And it promotes very clear lines of ownership, where if I've got a customer that, I can get what I need from the customer. Or I have a lease, I can get what I need from the lease.
\n\nA way to visualize the thing that I'm thinking about, at least, is, like, think about an unstructured graph and traversing this unstructured graph where things can just go topsy turvy, any old place, versus a tree where I go from the node, and I could go to the leaves, but I don't go up, right? There are no cycles in this graph. And think about sort of traversing and just writing sort of traversal algorithms on an extremely structured tree, where it has rules, and the rules must be followed, like a bee tree or whatever.
\n\nTAD: But doesn't a tree have a node? Like, the parent node knows about its children, and the children know which node they belong to.
\n\nWILL: It depends on the tree, [inaudible 33:13]
\n\nTAD: It seems super weird to me that a leaf, you can say like, "Who's your parent?" And it says, "Oh, that guy." But I can ask that guy, and he's like, "I don't have any kids. I don't know of any relationship to my children." That just seems really surprising to me.
\n\nWILL: I'm thinking about really sticky, complicated, little data graphs, data associations because I've seen, I don't know, I've seen them go off the rails, where there are all these things snarled up together because there isn't clear ownership. There's not a clear, I am the container node that everything sort of spins around. And what I'm thinking about specifically is these situations where you need to put in...so let's say I want...I want to make a service call, and I have to attach a bunch of different extraneous stuff to my thing because it's like, oh, well, I have the shopping cart.
\n\nThe shopping cart has orders, but I have to have the customer because the customer has the rewards account index, right? So, I can give them their rewards points. And then, I have to have the associated store because the order is going to be fulfilled from their preferred store. And you get all these things that are just sort of, like, there isn't a reason that they all have to go together, but because these things have not been organized...and, I mean, I don't want to be, like, I'm not a zealot on this. But, as a rule of thumb, making things a one-way hop, unless there's an overriding need for it not to be, that's really compelling as a guiding principle.
\n\nDAVE: I may have explained it poorly. Actually, I may have achieved exactly what I said when I started this story, which is I'm defending this poorly, and so it'll start discussion on it. But yeah, it's interesting to kind of push and think about, like, if you've got literally two services, one for orders and one for customers, one of them needs to know about the other one, but the other one might not always need to know, and that's, yeah, even though they do always have that relationship, yeah.
\n\nMIKE: Well, I think that's actually kind of important. Let me take your idea a little further. Let's say you have customers, and you've got leases, and you've got locations, and you've got merchants, and you've got shopping carts, and you've got, you know, any number of things. I think that if the customer has to know about all of those things, then it's just a big ball of mud. You've got all of that complexity tied up in the customer. But if you have a customer and it's just customers and your shopping cart is in some other service that handles shopping carts, and they have a reference back to the customer, so they know who the customer is.
\n\nBut the customer knows nothing about shopping carts. Doesn't have to know a thing about shopping carts and doesn't even have the ability to look it up because he doesn't know about shopping carts and doesn't have to. But your customer stays simple, and you don't have to deal with that complexity. Shopping cart knows what the customer record is and could look it up if it needed to, right? But that's a one-directional relationship, and it doesn't need to be otherwise.
\n\nAnd where those shopping carts are very ephemeral, right? I mean, they come into existence; they pop out of existence; you have many, many of them, and they really have nothing to do with the core idea of the customer, that actually disentangles, I think, your architecture dramatically. And when you have all kinds of things, you know, and I could probably come up with 100 things that need to reference those customers, if the customer has to know about all of those, then your customer gets extremely complex, where I think that you haven't really decoupled, unless the customer doesn't have to know, right?
\n\nYou've got something that maintains, here's your customers. And somewhere in a data warehouse, you can map everything together, right? Or maybe even in the frontend, you have some ability to tie things together because you can make the, you know, you can [inaudible 36:56] backend and put things together. But I don't think that whatever is holding, you know, managing your customers should know about what payment you made, you know, what your payment method was that was used three days ago. It gets entangled with something that has nothing to do with that. And that's the idea, I think, in the best sense of what Dave is trying to say.
\n\nDAVID: I think I might see a distinction here as well that if you talk to the entire system, you're going to have to know about both and the system output. But if you want to have a conversation about shopping carts, you can't just go talk to the customer service. You have to go talk to the shopping cart service. It's allowed to talk to customer, so there's that direction. But the other direction, there's no link. There's no way to link customers down to their shopping carts because that service is whittled down and kept very, very small. That's the piece that, at the system level, you absolutely can go both directions. I'm not saying sever the link in one way. I'm just saying this particular tiny service we sever it just for that service.
\n\nWILL: Well, I like this shopping cart customer kind of thing, right? Because there's a clear ownership thing, right? Customer has a shopping cart, right? But maybe case study, like, what I'm imagining here. It's like, okay, I've got, let's say, I'm trying to do some new feature from this shopping cart, and I want to go out, and I want to say, "Based on the stuff you've bought, I'm going to machine learning up some things so that when you're in your shopping cart, I can show you some other stuff because you've got cash in hand." And I'm like, okay, I got a hot buyer. Let me see if I can upsell them on some stuff based on the things that I know about them.
\n\nAnd so, then as developers start developing out the feature, then you start to tunnel through the shopping cart, then through to the customer, and then through to their purchase history. And now you're going from this shopping cart thing, and you're tunneling through, and you're getting into all this other stuff, which is like, whoa, whoa, whoa, whoa, whoa this is a little bit, you know, this is a little funky, and now you're sort of injecting these dependencies by going through the path of least resistance. Like, I have a shopping cart. I'm checking out, right?
\n\nSo, rather than pulling in the stuff maybe kind of a top-level way, you're side-loading this relationship, and you're using that to tunnel your way through the system to avoid doing it on a straight-up way, where it's like, hey, I want you to, like, you know, like, you're bringing in a shopping cart, and I want you to bring in some recommendations for me, you know what I mean? Is this analogy coming off the rails? I'm freestyling a little.
\n\nTAD: I think what I'm kind of thinking about now is, I think that you need to know the relationship, but you also need to respect the relationship, meaning Eddy and I are coworkers. And he's like, "Hey, let's go for pizza," or something like that, and I'm like, "Hey, yeah. Can I borrow some money? [laughter]" He'd be like, "Sure," right?
\n\nBut if I reach into his pants and pull out his wallet [laughter] and then grab that money out of his wallet, I've violated that relationship, right? I think it's important that I know like, oh, Eddy and I...Eddy is someone I could borrow money from, right? But if I'm going past that interface of that relationship, I'm violating the boundaries of that relationship. So, I think, that's kind of how I'm seeing it right now.
\n\nWILL: Well, yeah. I think we're all seeing it. I think we actually are vigorously agreeing because, like --
\n\nDAVID: Yeah, violent agreement, yeah.
\n\nWILL: We all understand that this is maybe a guideline, but not a hard and fast rule, which is why it would be totally fine. And you were like, "Hey, I need to borrow a couple of bucks for lunch." And Eddy was like, "Yeah, yeah, yeah, just go grab my wallet out of my jacket. It's over there," right? Like, obviously, that's not a blank check to just get into Eddy's pockets anytime you'd like, but, like, reasonable people can make exceptions.
\n\nAnd the thing that I like about not doing these bidirectional relationships by default is it sort of puts guardrails on the relationship where you need to do it on purpose. Like, I'm doing this on purpose because these things are so coupled, and I actually think shopping cart to customer might be. In the end, it might be one of those such tight relationships, where it's like, yeah, we should probably go both ways.
\n\nMIKE: Well, it depends on your business.
\n\nWILL: Yeah, exactly. But, on the other hand, I don't trust you guys with nothing. Like, a big piece of my life is just hiding the sharp objects from the junior developers.
\n\nEDDY: Jeez, well, I don't know, man, if someone's reaching into my pocket, I want to be able to reach into theirs, too, you know?
\n\n[laughter]
\n\nDAVID: That's a bidirectional relationship, yeah [laughter].
\n\nTAD: That's a violation.
\n\nWILL: [laughs]
\n\nDAVE: I just want to say I'm so happy to be on this call with y'all and to not be the person who launched the sentence about reaching into somebody else's pants. That's normally Dave Brady brand but thank you. You did give me a...I'm sorry, go ahead.
\n\nMIKE: If HR might need to get involved, then it's a violation of best practices.
\n\nDAVE: Yes. Yes.
\n\nWILL: That's why I work remote, man.
\n\n[laughter]
\n\nDAVID: I had a light bulb moment when we were talking about this, that if customers and shopping carts are coupled...and stop me when you've had this...we've had this pain. Everyone in this room, I'll wager...I know, maybe not Will, and maybe not Kyle. I don't know how much coding you're doing lately. But everyone else on this call, I know you've had this problem where it's like, oh, I need to, Will talked about the shopping cart, I need to calculate the shipping and, in order to calculate shipping, I need to know how many boxes and how big the items are. So, what boxes so that I've got to do the packing on it, and then I need the weight on this.
\n\nWe can go to a shipping calculator. It needs to know what state we're going to send it to, and that's going to come from the customer. But other than that, the shipping service doesn't need to know anything about the customer. It just needs...and, honestly, the only thing it needs to know from the shopping cart is what items are in it. It needs an inventory list.
\n\nAnd if you can say, "Here's the state, and here's the list of items," that service now doesn't need to know anything about the shopping cart or the customer. But we've all written specs, where you're like, okay, I want to do this. Oh, I need...this is a shopping cart. Oh, I need a merchant. Okay, in order to have a merchant, I need a location. And to get a location, I need a merchant, to get a merchant...oh, I need the legal paperwork that says, "The merchant has been onboarded and has signed the paperwork." Because they're a valid merchant, they're supposed to go through the system, so they're going to be checked at every point.
\n\nEDDY: You don't have to worry about that if you use factories, Dave.
\n\nDAVID: Right? Exactly. Exactly. So, just, you know, we'll just do everything with factories, put it all in the database. And do you want half-hour spec suites? Because this is how you get half-hour spec suites [chuckles].
\n\nWILL: And also, the other thing about shipping is like, maybe it's not for me. And I also said it, like, because I could speak as a large electronics retailer. We do a lot of shipping, and let me assure you, shipping is much more complicated at the state. There's lots of places [inaudible 44:17] you can get stuff the same day, and there's a lot more places in Utah you cannot [laughs]. Like, my dad lives in Michigan, but he lives in the part of Michigan where Prime is not a thing. You'll get it next week, period [laughs].
\n\nDAVID: The last mile problem we were all talking...like, in 2008, we were talking about the...whoever solves the last mile problem...this is before Uber existed, right? I might have that year wrong, but, you know, before Uber existed, solving the last mile problem was the reason why there were only three big, you know, FedEx, UPS, and DHL were it for shipping stuff, and now it's all super federated, and everybody's distributed.
\n\nI tracked a package on Amazon yesterday, and I saw a new status update, which said, "Delivery appointment scheduled," And I'm like, "What?" I'm used to carrier picked up package, package in transit, received at facility, left facility, you know, out for delivery. That's all you need. And, all of a sudden, we've got a delivery appointment. And I'm like, somebody's working on that last mile problem, and it's not well...what is it? The future is here; it's just not well-distributed, right?
\n\nThere's still places...there's a place in Nevada that does not have cell phone services. There's only four pairs of copper going in and out of the town. Great Basin National Park, that's what it is. There's a little town there and a little national park. And yeah, I remember pulling in there, and I'm like, oh, my phone doesn't work. Let's have a modern horror movie now. We've now solved that problem.
\n\nWILL: Yeah. I mean, Great Basin, I want to write that down. Like, I want to go camping. I only want to go camping places if there are no bars.
\n\nDAVID: It's a...not to turn it into an ad for this, Great Basin National Park is a glacier in Southern Nevada, in the middle of the desert, right adjacent to the Mojave Desert. It's a glacier because it's on a great, big, volcanic talus cone. And you're just driving across the desert, and then, all of a sudden, there's this mountain sticking up out of nowhere, and there's a glacier on top of it. It's crazy. And Lehman caves, which is gorgeous, so...I may have vacationed there recently.
\n\nWILL: I'm underlining it [laughs] --
\n\nEDDY: So, I kind of want to...Sorry, Will. I just kind of want to go back to where we initially started. So, I guess, essentially, there is no rule of thumb to follow, right?
\n\nDAVID: Maybe not a rule of thumb. Well, there's lots of rules of thumb. You just have to remember that they're all based on principles, right? You can distribute something. And if you distribute it in such a way that the distributed nodes have very slow communication between them, and they don't do very much communication, you're great. You can do all your high performance in your silos now, and everything's great. And if you do it wrong, you're going to take the high-performance stuff and then stretch it over a boundary, and now everything is over HTTP that used to be in the CPU cache. Ugh, been there, done that.
\n\nWILL: I don't know, I've got a rule of thumb. I've got a rule of thumb in terms of, like, monoliths versus distributed services. And this is going to be on the record hot take right now: You should keep it as monolith for as long as possible.
\n\nDAVID: I agree.
\n\nWILL: Because, as I see it, the fundamental trade-off that you've got between monoliths and distributed services is you're levering engineering output versus sort of management and the ability to communicate, you know what I mean, to coordinate and keep everybody pulling in the same direction and keep the children from fighting with each other because it's just natural human nature. And, in the end, this is probably my engineering bias, but I've run into a lot more effective engineers than I have effective engineering leadership and [inaudible 48:12], you know what I mean? I see you, Kyle. You can hide behind your hand all you want, but I saw that [laughs].
\n\nEDDY: Isn't there a cost, though, to having a monolith, though? Like, if you say, like, "Hey, no, like, I have a monolith that was the first service that we developed for their startup. It's been developed actively for 10-plus years," right?
\n\nDAVID: Sure.
\n\nEDDY: And you're like, oh, go and develop for this feature, right? Suddenly, isn't there, like, a higher ceiling to come in and get acquainted with, versus if it had a microservice, a true definition, to Dave's point, to a microservice, right? Wouldn't it be easier for you to hit the ground running because you know how to scope or comb through all this [inaudible 48:57]?
\n\nTAD: Well, the company I worked for before, and it's out of business, but I won't say their name anyway, they had the entire company was an entire single Go codebase. And you're talking 60-70 developers all working on a codebase that has to compile. And so, every subdirectory had a README file, and it's like if you want to touch the code in this folder, you got to get sign-off from these three people [laughs].
\n\nDAVE: The stakeholders.
\n\nTAD: And that's how they --
\n\nWILL: Stakeholders, David, yeah.
\n\nTAD: Like, took care of it. And it's like, oh my gosh, like...
\n\nWILL: So, what you run into doing that stuff is you'll have these sort of rather than management fiefdoms, you'll have these engineering fiefdoms, where you have this increasing important hardcore set of engineers that know everything and everything has to run through them. It's just like parallel programming.
\n\nTAD: Well, I'm just saying, like --
\n\nWILL: People will max out, and you'll feel it, you know?
\n\nTAD: It felt like the worst parts of a monolith, where I want to change these three files, therefore, I have to get, like, eight people to sign off on it. Oh, two of them are on vacation right now, well...Whereas if it were a single service with five people, any other four people on my team could probably sign it off, and we could roll it out that day, right?
\n\nDAVE: Yeah. To Will's point, there's an agile principle, which is to try to defer your decisions as far as possible. The idea is to defer the decision to the point of maximum information because the information increases monotonically over time. So, if you make a decision early before you've got all the data in, and that decision commits you to a path, and then you find out you were wrong, it can get very, very expensive.
\n\nIn SOA, once you split, if there's a decision that has to be made on both sides, that affects both sides, that's twice as...well, more than twice as expensive, probably four or eight times more expensive because they both have to change, and they both have to communicate. We've all had that thing where you have to do a tandem deploy because my service wants to change this, and it'll crash you if I do it before, and da da da, and that whole game.
\n\nSo, to Will's point, yeah, I think you should start small and start monolith, until there is pressure to do. At Acima, we have a great, big monster service that has been calving icebergs off of it. It's not even a monolith now. It's a continent on it, and it's just, you know, calving little subcontinents across. And that's a great way to do it. I don't know if it's a great way to do it. It's exhausting, and it's painful. And we have architecture meetings every week where we scream about it. But it worked. It started small. It got big. It got too big, and then we broke it down.
\n\nAnd if we had started out eight years ago breaking things into, okay, you're going to be this service; you're going to be that service...the first time we tried to change a low-level thing, like, the first time you try to move outside the United States to do business, and, all of a sudden, you need postcodes instead of zip codes, right? If you have to change that in every single service and there's validations that are hard that will crash your service if that's wrong, in every single service, it's going to be a nightmare. If it's a monolith, just update the zip code table, right? Just, right? Less expensive if it's all in one place. Yeah.
\n\nTAD: How do you know when to start slicing off baby services from your service? Is it complexity? Is it team size? Like, what's your rule of thumb?
\n\nDAVE: I let pain be my guide. Like, when something hurts long enough, when something hurts, I kind of make a mental note, and if it hurts twice or three times, I start going, maybe we should fix this, right? I personally am constantly driven to just polish out the tracks where I'm frequently going. So, if I'm doing something, like, pairing with somebody and I opened up a PR, and then I went back to my terminal, and I typed git set PR number, like, why did you do that?
\n\nAnd I switched over on another branch, and I did git open PR. And it opened a browser to the pull request for that thing. And I'm like, well, it's because I wrote a little thing that ties branches to PR numbers. And I'm like, yeah, that's hard work to do that. I'm like, yeah, but it's really painful to not have this. And, for me, it was less painful to stay up over a weekend writing a little PR management, you know, a little number associator.
\n\nWILL: I think if you talk to your senior engineers, you'd be like, "What sucks?" Like, everybody –-
\n\nDAVE: You'll get answers [laughs].
\n\nWILL: Yeah. And they're going to be...I'm saying there's a whole, like, how do you chip away your icebergs? That's a [inaudible 53:56] question that we could spend a series of podcasts on. Honestly, I'm more interested in, how do you maintain the communication and collaboration among teams? Because I have seen the distributed services architecture is a tremendous leadership challenge.
\n\nAnd I've seen so much just...we could just call it deadlocks, just like parallel programming. I figured it exactly like parallel programming and sort of deadlocks, and race conditions, and stuff like that with these sort of distributed things. It becomes a leadership problem. I mean, everybody knows the reasons why you should start branching out services, why you spawn a new threat. But how do you keep these things together? How do you keep the teams working with each other, right?
\n\nDAVID: Let's do that next week. I think that could be a whole call. How do you keep parallel teams productive? Yeah.
\n\nEDDY: I guess to kind of –-
\n\nWILL: Absolutely. To keep people from fighting, you know, keep people accountable.
\n\nEDDY: I guess the answer really is...it was a long-winded conversation to just say, "It depends."
\n\nDAVE: That's the other name of this podcast, a long-winded conversation to say, "It depends," yeah.
\n\nWILL: Well, yeah, I mean, it always does. There's no right or wrong in engineering. It's just the right tool for the right job. And, believe me, there can be a wrong tool for the job, and you're going to feel that [laughs].
\n\nDAVID: Mm-Hmm. Cool. Well, we have lost our host. Mike got called out to a production issue. Thank you for listening and watching our podcast. We appreciate it.
","summary":"","date_published":"2024-09-04T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/caf4731c-2d29-4a96-82cb-6b2f38f63dac.mp3","mime_type":"audio/mpeg","size_in_bytes":34156258,"duration_in_seconds":3359}]},{"id":"cb1c6dd8-7b12-4d77-9a26-9f27c69484d1","title":"Episode 53: Velocity vs Thoroughness","url":"https://acima-development.fireside.fm/53","content_text":"In this episode of the Acima Development Podcast, Mike shares a personal story about his father, a custom staircase builder, to illustrate the importance of balancing speed and thoroughness in work. Mike’s father, known for his meticulous craftsmanship, often took extra time to perfect even the smallest details of his projects. Mike contrasts this with a quick-fix job he once helped with, where speed was prioritized over perfection to meet a deadline. Both situations were appropriate for their respective contexts, highlighting the need to adjust the level of care based on the type of project at hand.\n\nThe hosts dive deeper into this theme, exploring how the right balance between velocity and thoroughness can differ depending on a company’s stage of growth. Will points out that startups often need to prioritize speed to survive, while established companies must focus more on quality and performance. They discuss the challenges of maintaining speed when stakes are high, particularly in large organizations where even small inefficiencies can have significant financial impacts. The conversation emphasizes the importance of adapting processes and expectations based on the specific goals and constraints of the work.\n\nFinally, the episode touches on the crucial role of communication and knowledge sharing within development teams. Pair programming, mentoring, and asking questions openly are all identified as valuable practices for ensuring that team members can move quickly while maintaining quality. The hosts stress that leadership should stay involved in the coding process to maintain a connection with the work, encourage a culture of learning, and foster an environment where mistakes are seen as opportunities for growth, ultimately helping teams strike the right balance between speed and quality.\n\nTranscript:\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I am hosting again today. With me, I have Dave and Will. \n\nDAVE: Howdy, howdy. \n\nMIKE: I'm going to start with a story, actually, well, two kind of connected stories. I'm going to talk about my dad. He's a builder. Well, he's retired, but [laughs] he spent most of his career as a builder. And most of what he did was custom stairs. Most people don't want custom stairs [chuckles]. It's the people who can afford the custom stairs who ask for the custom stairs. So, he did a lot of work for, you know, people who can afford to pay to have custom stairs done. And the people who pay to have custom stairs done are looking for a certain kind of work, right?\n\nWILL: Gone with the wind, grand entrance, duh. Yeah, I didn't get the Scarlett O'Hara dress for nothing. \n\nMIKE: [laughs] So, circular stairs, you know, he did the spiral stairs, and that was kind of his specialty. And it's not just my dad; he did it with his brothers. He's got two brothers he did with. And they, you know, built stairs for years. And in my...well, I have personal experience. So, my dad built a house to sell, and this was in the late '70s. Everybody knows a big economic issue happened then, and people weren't buying. So...\n\nDAVE: That was like the gas crunch, right? \n\nMIKE: Yeah, exactly. So, the house didn't sell. He ended up moving in, and he's still there. [laughter] So, he probably over-housed, but he's been there. But, you know, he just can't...he spent his career doing this custom work, this custom, you know, the best quality you can get, right? And he's continued to work on the house. Can't help himself [laughs]. And so, everything he does, the floor and the kitchen, it's amazing. But you wouldn't pay for it because you couldn't pay for it. \n\nHe found an apple orchard where they were getting rid of their trees, and he cut the trees into layers and dried the wood, and then sanded it down, and cut it into the right shape. Well, cut it into shape, then sand it down because it warps after you've cut it. And so, it had to be cut thick, and then process every one of those pieces to get it to the right shape. And it's like every one is, like, at the heart of the tree. Once it was sanded, laid it all down, put epoxy on it instead of, like, your standard polyurethane, so it will last forever. It is just absolutely stunning.\n\nBut it's the thing you can only get by doing custom work, right? And when I've helped him...and I've helped him a lot. I've done some work there, and I, of course, worked with him when he was working outside the house, and [laughs] his standards are exacting. He's not a jerk, but [laughs], you know, he does quality work. And people work for him; he wants that work done. \n\nAnd so [laughs], the work is great. Everything he does is done, exacting perfection. A lot of the work he does himself because he knows he's the only one who will give it that kind of attention [laughs] to actually get it done the way he wants it done. The one time when I've been doing a lot of work with my dad, I went and helped a cousin of mine who was moving out of the trailer he'd been living in. Though it was kind of a dump, and they wanted to make it look nicer before they moved out.\n\nAnd I remember I was putting in some molding along the floor, just some cheap, little, thin stuff, and they asked me if I could do the corners. I was like, \"Yeah, sure.\" And the speed at which we did the work in that trailer...I was getting together some, you know, some other family folks. And we got together and quickly did a whole bunch of work, you know, got together in three hours and redid all kinds of stuff in this trailer. \n\nThe floor was totally out of true, right [laughs]? So, trying to get that corner right was nearly impossible. I think, eventually, I put some sand under the linoleum to get it [laughs] leveled so [laughs] [inaudible 04:11]. And we got it all together. It looked a lot nicer, so we could sell it. And we were done. And here's the thing: in both situations, the right work was done. If you're going build a custom stair for somebody who wants a custom stair, well, you're going to give that every little bit of attention to detail that it deserves. If you were getting that trailer ready to go so you can quickly sell it, you're going to do that quick because that's what it deserves. \n\nAnd that's not to say that the trailer doesn't deserve care, but it would be incongruous [chuckles] with the rest of it. It wouldn't be worth the value of that whole structure. You know, there's people who actually make a small home look really nice. I've seen that before. This one was not. This was not one of those homes [laughs]. This was not [laughs] one of them. But both of them were right. \n\nThere's a balance that you have to strike based on the work at hand, and sometimes you got to get that done. And, in fact, most of the time, the work we do is probably more like that trailer, right [chuckles]? We need to get the work done. And I'd say this: I say more like, I don't like to do shoddy work. I want to do quality work, but some things need to get done. \n\nBut then there are other things, you know, if I'm building something that has anything to do with money [chuckles], I want that to be done right. And I want somebody inspecting that [laughs], going over with the white glove to make sure there's no dust on it, you know, because you do not want to mess that up. And, you know, there's a time and a place for both. \n\nWhat we're going to talk...I'm leading with a story. I haven't even talked about our topic today. We're going to talk about the trade-off between velocity, you know, between working fast, getting things done, and being thorough. And I thought about, you know, the stories because it is a trade-off. If there was a clean answer, then we'd all be doing it. \n\nAnd the problem is we often tend to err on one side or the other, right? We tend to maybe go the wrong way for the work at hand, and we get in trouble. And sometimes, you maybe get...and we've probably all worked with somebody who had the work to do, and then they just didn't do it at all, you know, they're off [inaudible 06:37] [laughs]. \n\nI did some construction work in New Orleans area. I used to work for a construction company in New Orleans. And there was one job we'd worked on it for months, and, basically, it was done, right? It was done, but we weren't ready to move on to the other contract. And there was a couple of days where there was nothing to do. So, they said, you know, \"Go around and look busy.\" I spent two days polishing the outlet covers [laughs]. So, when somebody came in, it looked like we knew what we were doing. \n\nAnd there were some people who probably spent more time polishing those outlet covers on other days [laughs] than they should have. There's that problem, too. I think we may delve a little bit into that, but starting with the topic of balancing this work of, you know, this balancing between being thorough and being fast. I've been talking a lot. I heard that Will had a story. I'm interested in what y'all's thoughts are and how you'd link it up. \n\nWILL: So, more I have a thought to share because I think a big piece of the thoroughness is sort of the phase of the company that you're in, right? But when you're in a startup and you're throwing features out the door as fast as you possibly can, and maybe you're going to take down the app; it'll come back up, there's not that much...you have different set of risk, right? Like, the risk you have now is you're fundamentally insolvent. You're going to run out of money. You're going to run out of time. And you have to figure out how to make a product that is worth buying. And that is your existential risk. \n\nHowever, if you're working for a large, multi-billion dollar company and you screw something up, and your page loads 5% slower, you know, there are direct correlations to sort of website performance and click-through rate, and conversion, sales conversion, right? Like, Amazon did studies on this stuff, and if your stuff is too slow, people don't buy. If your site is not fast to navigate around, people will leave. And so, that stuff is really, really important. \n\nAnd so, I'm talking about sort of a thoroughness-fitted finish kind of a thing. I'm not even talking about your stuff crashing. I'm talking about your stuff not being fast enough. It's like, oh, well, what if I lose five basis points worth of sales because I just didn't do as good a job as maybe I could have? Five basis points. A basis point is a percent of a percent, right? I just burned my salary for the year, just like that. \n\nThis is the phase of the company, and there are indisputable properties of just having a going concern that makes a lot of money. The impacts to the bottom line are substantial. You do need to be thorough, and I would...I always advocate for my developers. Like, if you've got a billion-dollar business, you should pay more for the people working on your site because it makes a difference, whether they're good or bad.\n\nAnd one of the things...and maybe I'm going to answer your question with a question, or maybe I'll just add on another one. How do you maintain velocity in a situation where you have a big enterprise; you have a going concern; you have stakes? If you screw something up, how do you keep that velocity? Because it's easy to analyze yourself into a state of paralysis. You still need to innovate. You still need to develop products. You need to be, you know, delivering results on a quarterly basis. Because, on every level of the company, they demand that, and that is what you're getting paid for. How do you balance that, right? Because both things are true. You can't screw up, but you got to get things out. \n\nMIKE: That's a good question. \n\nDAVE: I keep coming back to this idea of, what are you really trying to do? What are you trying to accomplish? If you're in a startup, you're not going to be taking on IBM or Amazon. You're not competing at that level. And there's a phrase that you'll hear a lot which is, \"The ideas that got us here won't get us there,\" when you're trying to scale. And the ideas that got you out of startup mode into productivity those ideas will not get you to scaled enterprise-level stuff. But the reverse is true.\n\n When you transcend the old ideas, don't discard the old ideas because what gets us there won't get the next cohort here. You end up transcending, and then pulling the ladder up behind you. I don't know if I'm making sense with that, but it's like, you start saying, \"Hey, we need to have SOX compliance. We need to have peer review. The person who writes the code should not be deploying the code.\"\n\nAnd then, you bring in a scrap team that are going to do a skunk work thing of like, \"Hey, we want to stand up a quick, little server that will just check this thing on this rating service.\" And you're like, \"Okay, cool. Where's my SOX team? Where's...\" no, no, no. You have 30 days to ship this, and the right solution is to just ship it. Cut features until you ship. When you have to play at that level, like, if that little service is going to connect to the accounting database, okay, no, you cannot ship this in 30 days. That is not a working solution. But if you're just trying to do something like, oh, I just want to check your membership loyalty points, that's easy. It doesn't need auditing. It doesn't need review. Just ship what they need. \n\nI'm sure you've all heard this. Growing up, I grew up in a kind of rural, you know, redneck part of the country. And I always heard all the time, \"If you don't do it right the first time, when will you have time to do it over?\" And then, I got into the software business, and I realized, no, the mantra in startups is, if you don't do it wrong fast, when are you going to get the cash flow to fix it and do it right? \n\nAnd so, yeah, the ideas that get us to here are not the same ideas that will get us to there. And you need both, but not at the same time. You have to stay alert to, which mode am I in? Am I in enterprise, secure mode? Am I trying not to lose the eggs that we've collected into our basket? Or am I desperately trying to forage quickly and get as many eggs into the basket as I can, and then we'll sort out if I accidentally stole your eggs, or whatever; we'll sort that out later? But at the enterprise level, I don't need that level of security. I have to get the eggs collected. That's 17 metaphors rolled up in a weird ball, but there you go.\n\nMIKE: You know, you're talking, Will, yes, you know, how do you keep the velocity going when you have those constraints? Another story [laughs]. I ride bikes a lot with my kids, bicycles, not motorbikes, but, you know, pedal-powered. And I discovered something great [laughs], and it took me years to find this, and I'm glad I did. \n\nYou can attach a tow...it's not a rope. You can attach a tow cable. Basically, it's a bungee cord that's wrapped in ripstop nylon that's been scrunched, so it's tough. You got the bungee cord inside. So, you don't have all the problems with a bungee cord, where it's going to have that hook, and it's going to tear your eye out [laughs]. But it, you know, it expands and contracts. \n\nSo, I attach it to the back of my bike, and then I attach it to the bike of one of my kids, right? And then, I've actually got two of them, so then I attach it again in a daisy chain [laughs]. And I've got my three-year-old that I'll put on a seat on my rack. So, I've got three kids, you know, all in a line behind me, and I'll go for a ride. And I've been doing that a lot over the last year. \n\nAnd I'll tell you, the first time was hard [laughs] because that adjustment from riding, you know, riding with no constraints on you to riding with three people pulling behind you is a shift [chuckles]. And I even had to make a change. The bike that I was riding a lot...well, I've got a fat bike. So, I've got fat tires that are, like, four and a half inches wide, so I can ride in winter right on the snow, packed snow. It still doesn't work in too deep snow [chuckles]. And I've done a lot of riding on that and some mountain biking stuff. Even though it was made to go up some steep stuff, it wasn't geared low enough. So, I've got a gravel bike that's got a...lots of stories about bike, but we need it for context here [chuckles]. \n\nDAVE: It's okay. \n\nMIKE: It's got a huge gear ratio. It's got a gearbox. It's got a huge gear ratio. And I can go really slow. And I can go pretty fast, too. But I can drop that thing down into an incredibly low gear. I have never gotten to the bottom gear yet, even pulling three kids, even going up a steep hill. I've never gotten to the bottom gear. I rarely get below...like, the lowest I ever get is, like, fourth [chuckles] out of 12. So, I'll give you a sense that, you know, this thing goes way low. It's awesome. \n\nBut [laughs] I had to change the way I rode my bike so I could keep moving forward, right? I had to change. And then, the reverse is also true. On the occasions I go out alone, I, like, almost fall down [laughs] because I'm used to having all of this mass behind me. And I have to rethink my riding style. We've got the same kind of thing, you know, thinking about this velocity. One time, I went on a longer ride with my kids, and I went up this, like, mile-long hill. And there was a headwind, a really strong headwind. And I was going mostly up that hill at, like, between three and five miles an hour, so, basically, at a walking pace. \n\nDAVE: Just fast enough to keep the bike from tipping over. \n\nMIKE: Exactly. Fast enough to keep the bike from tipping over. And if you were trying to do that, like, most people on a bicycle would just agonize over that because you're just not getting...that spot in the distance is not getting there very quickly. But the important part was not to get there quickly. I had a headwind. That was just the reality, right? I'm going up a hill. That's the reality. I've got all this weight, and this is the reality. \n\nThe important thing is that I keep pedaling. And as long as I'm keeping on moving, you know, your brain, you can adjust to it, right? You can adjust to these new constraints, and you just keep on going, right? You're not going to go as far. You're not going to go as fast, but it doesn't matter. The important thing is that you don't stop. Because you could think, well, I'm not going very fast. What difference does it make if I just stop? Well, it makes a huge difference [chuckles]. Stopped is very different from moving forward.\n\nWe're going to be in different situations, right? Sometimes we're going to have the headwind. Sometimes we're going to have a bunch of constraints we have to deal with, a bunch of weight we pull along with SOX compliance, you name it. But you can still set up the processes and run basically the same, right? If you're moving forward, you're moving forward. \n\nThe key thing is that you never get in that situation like, well, we're not going as fast as we were over there. So, what we're doing doesn't work. We've got to break everything, either by stopping because, like, well, this doesn't even matter. Very bad choice. Or saying, \"Well, we need to completely reorganize our process. We need to get our velocity up to exactly this.\" Well, that's not realistic either. Because if you've got all these constraints, I think they're there, and you got to just deal with that. And you can adjust to it. Like, you can adjust to a lot, as long as you're keeping on moving. And it's really critical not to try to compare different kinds of work because they really don't correlate. \n\nDAVE: You just connected two epiphanies that I've been carrying around for 20 years. This is exciting. When you mentioned that the important thing is to keep peddling, to keep moving, I had a job very early on in my career. I was moving out of, like, minimum wage jobs and into, like, my career. I was actually writing software for a living. I was on the networking side, so I was pulling cable as well. I was literally, like, crawling around behind people's desks and dragging cable. And if there was a hardware problem, I had to deal with the hardware. I ran a soldering iron at one point, right? I was all over the map.\n\nAnd my job was to be the network guy. My job was not to break down boxes in the shipping room. My job was not to, you know, manage the sales cycle. My job was the networking stuff. And I came in and the stockroom in the back was getting piled and piled up and piled up with supplies of stuff. And I was in this mentality of, hey, I got to get this network stuff. It's not my job to do this. \n\nAnd I walked in, and my boss was in the back room cutting down boxes and breaking everything down. And I'm like, \"Wait a minute, if it's not my job, it's really not your job. What are you doing?\" And he just looked at me, and he's like, \"We need the space in order to get our job done. I'm an expensive stock boy, but I'm going to get it done.\"\n\nAnd that was the epiphany for me of; sometimes the objective is, am I doing the job that I'm supposed to be doing? And sometimes, the focus is what do we need to accomplish? The how doesn't matter, but the what is what matters. So, I've literally carried that around in my head: I'm an expensive stock boy. I carry that around, and it has availed me very good over the years.\n\nThere's been times when it's like, there's this big, messy part of the project that nobody wants to touch, and I don't want to touch it either. But then I look, and I'm like, well, that is between us and done. So, I'm going to go be an expensive stock boy and just take care of it. And, usually, somebody higher up on the chain will go, \"Ooh, that's an expensive stock boy. Let's get a stock boy.\" Or they go, \"Yeah, we just needed that room cleaned out once, and it needed to be done. So, that was the right price to pay for it once.\" \n\nWILL: I think that's a big...I've seen it a lot as sort of like, you know, teams specialize, right? And they sort of fragment into this archipelago of little islands, you know, that make up this country. And then, you have, you know, directors and VPs and stuff that they have their little region, their little fiefdom. \n\nAnd I think that is one of the hardest things in terms of scalability, in that you still need people who take ownership of the entire organization, the entire app, the entire end-to-end experience. And, honestly, like, one of the things...I was just talking about this today. Like, where I think that breaks down really badly is sort of in the corporate hierarchy, like, the people you'll have are, like, VP or a director that isn't in the code every day, doesn't know where the bodies are buried, doesn't know how all these things interoperate. They have the visibility, but because they're not in it every day, they're very detached.\n\nAnd I think there's a little bit of a black spot in the industry for somebody who is VP level or whatever your broad organizational level leadership. But they're an engineer. They're doing work. They will cut down boxes. Oh, this ticket was screwed up? I'm going to clear the ticket, and if you can't...I mean, bluntly, I know a lot of smart people, and I know a lot of smart people who've moved into management, you know, leadership positions. But you have to pay your dues. You have to pay the toll. If you want to ship code, you got to ship code. You got to put in your [inaudible 22:46]. Nobody gets an out.\n\nIf you are rusting, you know, then you're rusting. I mean, just like after a year on the bench as the manager of the team, like, you're going to have to ramp up just like a new hire would, maybe not that bad. I've seen it fixed places, you know, with things like principal engineers and stuff like that, but it's a systemic problem. And I haven't really seen a systemic solution other than senior, senior leadership recognizing the problem and being proactive and making sure those people are there and empowered.\n\nBecause a lot of the stuff you'll see is, they'll go around peeing in some Cheerios. There are a lot of people who have pet projects. They have things that they're doing. They have deliverables and stuff. And somebody comes in and says, \"Hey, like, the interop between this department and this other department is all screwed up. Our codebase is all screwed up. We have technical debt. We've got performance and security considerations. And I'm going to have to like, you know, I'm going to screw up your quarterly results because this broad thing happens at like...\" you know, there are a lot of smart people with interests in kneecapping those kinds of systemic engineering initiatives and accountabilities and stuff like that, you know, it's a ferociously difficult problem. \n\nAnd I was contending with that earlier today, like, wanting that person in that role to come save me like Superman. I need heads cracked, and I don't have the juice to call these people, you know, behind the [inaudible 24:44] I can't do it. I know it's screwed up. They know it's screwed up. Anybody who's looking at it knows it's screwed up, but, like, the people that can can't [laughs], you know what I mean? I suppose a tangent, but a thought that was on my mind.\n\nMIKE: Well, you said something. It's something I've thought about a lot. I've heard a lot of times, people who do hands-on, you know, typically blue-collar work, working with their hands, talk about how much the leadership doesn't get it. Like, \"They just don't understand the work we do.\" And I can't count the number of times I've heard that. \n\nAnd I think it's generally, like, I almost take it as a truism because I've heard it so many times that if you have somebody who hasn't done the work or is not connected to the work, they're going to miss things that are important. They're not actually going to understand what's going on. And, to your point, it doesn't matter how much you're looking at it if you don't know what to see. And it seems like there is a critical need for leadership to actually have either gotten their hands dirty or be willing to listen to the people who have and actually respect what they have to say. \n\nWILL: Well, I don't want to be a jerk about it, but I will say this directly. You got to keep on paying the toll. Rust never sleeps. Every...I don't want to say every but, virtually, every senior engineering, leadership, management person that I have worked with I know in my bones started out as an extremely competent individual contributor. At one point, they were all good. They were all really good. I mean, once you get to the director and above level, present company accepted; once you get to that level and above, it starts to catch up with you because you know what your schedule looks like. Mike's shown me his calendar.\n\nMIKE: [laughs]\n\nWILL: When are you going to get your hands on the iron and do it? It's a luxury. That's like a day off. And if you don't do it, it catches up with you because everybody has to pay the same toll. If you want to be good, you have to continue sharpening the saw. Rust never sleeps. And that's when you run into these sorts of difficulties, the very difficult line to walk.\n\nDAVE: It works backwards as well. I remember the first time I worked for a manager who had a string of managers in the early noughties and mid-noughties. They were, like, senior developers. And cowboy coders didn't get along with anybody, but they were very, very good. And they ended up in, like, CTO positions, and nobody wanted to work for them, right? Because they had no people skills. And the ones that had people skills weren't necessarily applying themselves to what type of battles do I need to fight at this level? They were still trying to focus down here.\n\nAnd the first time I worked with a manager who came in and said, \"Yeah, I used to be a developer, but now I'm a manager, and this is my job,\" and, like, the first three or four months working for him I hated because he would actually make me do one on ones.\n\nWILL: [laughs]\n\nDAVE: And I'm like, no, everyone knows that one-on-ones are uncomfortable, and nobody likes doing them. And after three or four of them, I'm like, this is really productive. I actually feel like I'm driving my career in a great direction because I'm actually doing this. \n\nAnd that was the time that I finally realized that...and it goes back to what I said earlier. The ideas that will get us there are not the ideas that got us here, right? You need that reference. You need that empathy for the people working under you. And you need to be able to look beyond and say, \"What...\" It's the same thing. If you're not focused on what it costs to write code, you're going to have some struggles. \n\nBut if you are the manager and your job is to be aware of like, oh, AI is coming, and we need to be ready, or we're going to wake up, and our industry is going to be gone, you know. And do we want to have gone with it wherever it goes? And, I mean, that's one example. Somebody will react too strong to the mention of AI, but you get what I mean, right? There'll be something that, like, we're going to do this initiative.\n\nWe talked about this in a meeting earlier today about a manager who said, \"We're going to pursue this initiative.\" And it was the wrong initiative. Turned out we got there, and there was no opportunity there. And it cost some people their jobs as a result, and that was no fun. And it was failure in both directions. Like, this person didn't understand the engineering, and they also didn't understand...they had a view of what ecosystem they wanted to put in place. And they managed to solve the wrong problem in both directions. \n\nWILL: [laughs]\n\nDAVE: Somebody said, \"We're leveraging the inefficiencies of both approaches. [laughter]\" That was, like, anti-synergy.\n\nWILL: That's almost impressive. \n\nDAVE: And I've been there. I've been on a team where I had a cowboy coder working with me, and I was, like, the meticulous, make sure your tests pass; make sure your code is expressive; make sure to actually dah, dah, dah. And there were times when I'm like, \"You're going so fast, and you're breaking things.\" And he was like, \"You're dragging an anchor when we need to get stuff done.\" And there were times when we got so much at loggerheads that we ended up shipping too little, too low quality and too late because we leveraged both of us. We both dug in our heels, and we ended up with nothing. \n\nAnd I think I've told this story here, but I worked with a guy named TJ at CoverMyMeds who was astonishingly good at picking his battles. And he and I were really good friends, and he got really, really good at seeing when I was about to turn and go down a rabbit hole. And he would just kind of put his hand on the back of my belt, and say, \"Whoa, whoa, whoa, whoa, wait, we don't need to go down that rabbit hole.\" And we fought a few times over [inaudible 30:55]. And I finally said, \"You know what? You're right. We don't need to go down that rabbit hole.\" \n\nHe was one of the first people I've ever worked with where pair programming delivered on every promise pair programming has ever promised anyone. And we were also linearly faster. Like, the two of us could complete a sprint's worth of work for two people in, you know, a week and a half. We literally...every way we went faster because the synergy worked so, so well because we were solving the right problems, and we were leaving the wrong problems alone. And that...oh, so good. \n\nWILL: I'm a pair programming seller, and I always evangelize pair programming.\n\nDAVE: Amen.\n\nWILL: I think it's good. It's not a silver bullet. It shouldn't always be everythings all the time, but I think it should be...I think we should do a lot more of it. You know, pair programming now, pair programming, you know, forever. Like, that's all. That's all I'll say on that. That's all I'll say right now. \n\n[laughter]\n\nMIKE: I got to say, it's one of my favorite things to do because the amount that you learn on both sides of a pair [inaudible 32:11]... a lot of times, you have a more senior, a more junior person, but it tends to flow both ways. The amount of knowledge transfer that happens there is unlike anything else that I've experienced in software development.\n\nLike, you can read documentation, and a majority of that is just going to pass right through your brain [laughs], not that it's not technically possible to go read some dry technical documentation and get lots of clarity from it. But when you're watching somebody work, or they're watching you work and seeing how you make each of those decisions, it just changes that equation typically. You see all that weren't captured in the documentation that you just wouldn't see otherwise. \n\nWILL: Yeah, well, I mean, and if it's your stuff, you know you didn't write everything down. You know you didn't do it. But, anyway, a lot of stuff you're talking about, I really do feel like a lot of those that, as line-level managers, I'm going to say flat out, I'll take my hot take; this is your hot take of the session, I think all line-level engineering managers should spend 25% of their week, maybe 20%, right? Eight hours a week, a full workday, every single week should be pairing with the people on their team so that they have both an understanding of like, okay, here's what's going on. \n\nIf you're a line-level manager, you should be a very proficient coder. You should be a senior-level engineer. You should be good at that. You can't be like, \"I'm a VP. I don't care anymore.\" No, no, no, you don't get that out anymore. You should be providing that kind of judgment, that kind of insight, that kind of understanding. You should be working with your team and figuring out where everybody is. Don't [inaudible 34:15] like a one-on-one. Get in there and feel it. \n\nAll right. Are you writing tests good? Are you thinking about parallelism? Are you thinking about error handling? Are you thinking about design? You know, all this stuff. You get paid for that. That's why people pay you to be around. And it keeps your hands, you know, in the iron, and you have a feeling for how things are going. \n\nI'm actually on a Slack thread right now with three, four staff engineers who are like, \"Why are my builds so slow on these laptops?\" And I have been fighting the good fight. There is a security team that has installed real-time virus checking on all engineering workstations. And it is virus scanning intermediate build products in real-time. It's a substantial CPU hit. I have been wrestling with these guys for a long time, many months. And these guys didn't even know. They're just like, \"Wait. Wait, what? It's doing what?\" \n\nAnd I'm like, \"Yeah, man.\" I've been arm-wrestling these guys to try and find a more economical accommodation to satisfy their security concerns while I can still ship these features. And if you never code, okay, you know what I mean? You're a director. You're a VP. You're up the levels. That's not actually your job anymore. You probably are wasting your time doing that. \n\nBut, like, line-level managers, I want your hands...I want you in the muck with the rest of us, at least a little bit, so you know what the hell's going on. Because even when that front line, you know, your NCOs or whatever you want to call them, you know, the people who are on the front line, if they've checked out, how's the information going to filter up? You know what I mean? Anyway, my two cents. \n\nDAVE: It's how do you get feedback? Yeah. \n\nMIKE: I've got one pushback against your hot take. I don't think 20% is enough [chuckles]. \n\nWILL: Yeah, sure. I mean, you're right. I agree. I think 25%...I think 50% is probably where I would cap it, but it's somewhere in between there. But I don't think...how do I put it? Like, I'm not asking for 30% and expecting to get 20%. This isn't like a negotiation where I know I'm not going to get everything I want. Like, I'm just saying what I need. This is the real number. I want a real 20%, and getting 8 hours consistently every week out of a manager's schedule to pair program is a substantial ask. That's hard to do. You need support. That is a rare bird to make even that happen. \n\nMIKE: I stepped into leading an internship once, where the person who was leading it...I say an internship, it was an apprenticeship. There were some people that we wanted to bring in to be full-time engineers. They weren't coming straight out of college. These were generally people who'd maybe been in another profession, and they were ready to come and learn what they're doing. And I'm not the one who started it. The one who did left, and I stepped into it. This was a number of years ago.\n\nMy manager at the time said, \"I think you should be spending 50% of your time writing code.\" And I laughed at him [laughs] because I was spending, you know, like, 80% of my time pairing with those apprentices. Because how else were they going to learn the ropes unless they were working with somebody? And --\n\nWILL: Well, but that counts. Pairing time is coding time. \n\nMIKE: That's true. Fair. Fair.\n\nDAVE: I remember pairing with Eddy Lopez here at Acima when he was fresh out of it. He was fresh on the engineering team from QA. He might have still been on QA. And he and I were pairing, and I asked him something, you know, \"Where's this in the source control?\" And he wasn't sure how to...and he's like...And I'm like, \"Okay, hang on.\" And I cracked open a terminal, and we spent an hour playing with Git. \"And I'm like, here's where to put it. Here's where your sandbox is. Here's the distributed nature. I can be the server. You can connect to me, and I've got all the changes because da da da da da.\" And I was explaining where the deltas go and all that stuff. \n\nAnd we were on the podcast a few months ago and Eddy pulled this story from his perspective, which is that he has paid that forward so many times. And I'm like, that was probably one of the most effective hours of my entire career because I invested in someone who then has now paid in, you know, bazillions of dividends. And I'm not trying to blow my own horn. I'm really happy that that happened. When Eddy was like, \"Oh, yeah, you did this, and I love it,\" I'm like [vocalization], I'm going to go for a long time on that compliment. So, it's awesome. \n\nMIKE: We landed into the value of sharing information. We've rerouted a little bit because [laughs] it was just such an important topic. Have we really hit how you keep that velocity going, how you keep moving? Because you asked, I think, a vital question, Will. And I gave kind of a metaphor, but I don't know if I got really into the technical details, how you do it on a development team. How do you keep that motion going? \n\nWILL: And, you know, actually, like, so there's another issue. Like, I have a lot of meetings on Friday. I'm trying to put my meetings on Fridays, because, listen, man, I'm going to show up to work on Friday because they're paying me, and I will do it, but they're not spending their best [laughter]. It's a fairly linear degradation of my engineering effectiveness. I'm still not bad, okay? You got your money's worth out of me today, but yeah, you know.\n\nAnd so, I was talking with my boss, so my boss long-time consultant. And he sort of, like, you know, went full-time and moved into engineering management. But he spent a lot of time as a consultant freelance, you know, developer, you know, that's me. Like I'm, you know, technically unemployed. Like, I've got a long-term contract with my large electronics retailer.\n\nAnd it's sort of like my team, you know, that I run sort of runs things my way, which is sort of very like, what have you done for me lately? Like, because I'm just used to the mentality of, like, people are writing me a substantial check for my services every week, and I want them to know what they're getting all the time, and that gets my contract renewed. I got another year. And it's a mentality that sort of the boss shares, and I share. And he's working with another team, and they don't necessarily think about things the same way because they were not brought up in an environment of existential fear [laughs] the way we were. \n\nSo, I have a story, right? And it's my mom. She had dogs for a long time. She had greyhounds. Greyhounds were her favorite dogs. She had greyhounds. And she liked to get, like, rescue greyhounds, like, retired dog track racers. I don't know if that's such a thing anymore. I think we've kind of phased out dog racing, which is probably good. But, you know, they would retire. They couldn't run anymore. They tore their ACL. Whatever. And they'd just be like, well, we're just going to dump them in a landfill. But I guess if you want them, you can have them, right? \n\nSo, she would get these dogs. And they were the laziest animals that have ever lived. You'll roll home, and you'll have a golden retriever, and it'll just be ecstatic beside itself, jumping on you, giving you kisses in the face. Almost, if not literally, like, wetting itself because it's so excited that its people are home. It's so happy. The greyhound version of that was...they would lift their head off the ground as they were lounging [laughter], look at you, and their tail would wag three times [laughter], wag, wag, wag. Boom. \n\nDAVE: Head back down.\n\nWILL: Head back down. But every time you would take them out in the backyard to feed them, you would get the most magnificent, beautiful, joyous, absolutely astounding run. They would tear around the backyard in a figure 8 at 30 miles an hour. I swear to God. \n\nMIKE: [laughs]\n\nWILL: It was magnificent. Magnificent. The most beautiful thing you've ever seen in the world would be just to see the beautiful athletic power and grace of a greyhound, wholesale. Because they had grown up in this environment [laughs] of existential fear, where literally, if they wanted to eat, they needed to run like their lives depended on it because they kind of did. \n\nAnd sort of like, you know, so my boss and I were talking about how can we...it's not that this other team doesn't have...it's not that they're not smart. It's not that they're not hardworking. It's nothing of the kind, but they don't necessarily have that mentality. And so, the question was like, we've got these sort of deadlines, you know what I mean? Economy is tough. Macro is tough. The business is like...it's not bad, but it's certainly challenging. Everybody is pushing really hard to keep their head above water. Everybody's working hard. And how do we get this team to do the thing? \n\nAnd what he settled on, and it's been on my mind since we had this meeting, and now that we have this conversation, it kind of brings it full circle, what he settled on was he just sat down with them, and he's like, \"Okay, you know, this is our thing.\" And he just started coding it up.\n\nAnd he exhibited the mindset of like, okay, we've got to move fast, so let's move fast. Let's do this then. Let's just put it together. Let's get the scaffold up. Let's get the skeleton, the framework. We're going to make some...we're going to build a jig. We're going to make some operating assumptions that allow us to move forward. And we're going to sort of start the rough sketch, and then we start filling in the outline, filling in the details. We're going to paint the color, and the shading, and all those things.\n\nAnd the only way he could really get this mindset onto these people, you know, which comes from decades of high pressure, high production consulting is to just get in there and show it to them, show them how it feels. And then, as he did it, the clouds parted. And they were like, \"Oh, okay, I see what you need. I see what you want to do.\" And that kind of knowledge transfer, endemic to the work we do. That's why I'm a paring zealot because I don't know of a better way to do it. I don't know of any other way to do it. And I am fully aware of how fantastically indulgent it seems on the surface, and the sort of visceral, like, oh my God, I'm going to pay two of you to just sit there on a single keyboard all day? \n\nMIKE: [laughs]\n\nDAVE: That's twice as expensive. \n\nWILL: Do you have any idea how much this is costing me, you know, to do this? But I just don't have a better --\n\nDAVE: And then, you let that stop you out, and you're like, okay, well, I'm going to work alone. And you just kind of sit there and go, do you have any idea how much it's costing you to have me work on this without a second brain? It's, you know, yeah.\n\nMIKE: Well, that's it, right? That what works is what works. It doesn't matter how much you don't like seeing 2 people sitting next to each other on 1 keyboard. It's what works [laughs]. \n\nDAVE: And if you're banging out 30 controllers with just RESTful actions, then one or two for pairing to make sure everybody understands this is how we roll this out. And then, yeah, go to your office and just I'll do these 15. You do those 15. Let's meet back up at 5:00, and we'll review each other's stuff because you're just banging out boilerplate at that point. But you do the first ones together because there's knowledge transfer going on, and yeah. \n\nWILL: Yeah, absolutely. The question that we had was sort of, like, how do you get that mentality? Because it wasn't even a technical thing. These guys don't know how to do the work. They understand the work. They're very competent programmers. They're really good. But that sort of, you know, that piece wasn't something that they really understood until they saw it. And then, once they saw it, they're like, \"Oh, oh, okay, I get it. I understand now. All right, let's go.\" And then, you know, boom, that's how I [inaudible 48:00]\n\nMIKE: You know, the kind of meta stuff around software development is so vital. It ends being most of what we talk about on the podcast because [chuckles] it's critically important. But you're probably not going to learn it in school because it's...I don't know if it's...it's probably hard to communicate about but it also sometimes, I think, seems trivial. \n\nYou think, well, we need to teach you the hard stuff. We need to teach you about writing code, and writing code is critical, right? Learning to express yourself in that way is a change in mindset that does not generally come naturally. And you have to bang on that for years to get good at it. But if you just focus on that, you're missing half the picture. \n\nLike, Dave, you talked about spending an hour teaching somebody Git. I mean, that is important, learning how to use those command line tools, you know, whatever tools that you use, you know, that are on the command line. Like, learning the tools for your job —that's important. And without that, you're not going to be able to work very effectively. And there are so many things like that. \n\nWILL: I thought so many people like the debugging, you know what I mean? Like debugging. Like, hey, how to use a debugger. Like, some people don't like using debuggers. Like, you should know how because a well-configured debugger where you could just stop the code, it's like, whoa, whoa, whoa, hang on. What are we doing? Why is that X instead of Y? That's critical. Just the idea, the mentality of debugging. \n\nI taught some kid just today, you know, another one of my golden bedrock principles, which Mike has heard out of my mouth many times, and I'll repeat it a thousand times more with no shame at all: Always debug from the known to the unknown. I had a guy, he was like, \"Oh, my analytics, they're not working. I thought I turned this analytics thing off, but I'm still seeing [inaudible 50:17]. This is all screwed up.\" I'm like, \"Known to the unknown,\" you know what I mean? And I'm like, \"Okay, I wish you'd check out the whole component.\"\n\nAnd he's like, \"Okay.\" But the analytics are still fine, but known to the unknown, take out more, delete more code. You got version control. Rampage. Don't do the thing. And he's like, \"Oh my God, you know, 15 minutes of just taking a [inaudible 50:40] at this thing until I finally made the noises stop.\" And I was like, oh, somebody duplicated it. Like, this thing exists in two places from, like, known to the unknown, always go from the known to the unknown. However, you can make it work, make it work, and then move from there. \n\nI'm like, that's just the kind of thing where it's just like, I think, hopefully, if I got it into his head, that was another one of those, like, one-hour conversations that he'll be like, \"Old man Archer said, 'Known to the unknown.'\" And I'm going to pop up over his shoulder like Yoda, if I did it right. And I will save him a thousand times [laughs].\n\nDAVE: Amen. \n\nMIKE: It's interesting the arc this conversation has followed because we talked about velocity and balancing that. And, certainly, there's a balancing act. But we didn't really linger much on that idea because maybe it's clear in all these different kinds of work. We've talked about how to communicate with each other, and share information, and keep organizational structures effective. \n\nWILL: Going fast is a feeling. You got to feel it. When you're on a team, and it's clicking, when you're writing code, and it's clicking, when you have the feeling of like, you know, mastering the command of your tools, understanding the organization, the needs, the codebase, it's a feeling. When it all comes together, you feel it in your gut. It feels good. I can't explain it to you, but I can show you how it feels. \n\nDAVE: It feels like flow, right?\n\nWILL: Yeah.\n\nDAVE: You get into it, and you're excited, and then, all of a sudden, it's 6:30, and your wife is like, \"Are you coming home?\" And I'm like, \"Oh, did I miss lunch?\" And she's like, \"Yeah, you missed lunch. Come home. You're missing dinner.\" \n\nWILL: Like, you know, the mentality of like, you know, we need this thing out. We are going to make compromises. If we are going to cut some corners, we're going to cut the right corners, not the wrong corners. We're going to give an appropriate amount of spit and polish to this thing. How do you make those judgment calls? I mean, you just got to know it, and you can get it through osmosis by sitting here with me, or with my boss, with whoever.\n\nDAVE: Sure.\n\nWILL: But I can't give you a book and just be like, \"Here you go.\" And that's the weird part of engineering; you got to feel it. \n\nDAVE: I think it's interesting that we're in a phone call talking about velocity versus thoroughness and all three of us are bringing communication. And what I realize is I think at intermediate to senior levels in your career, interpersonal communication becomes the most difficult technical skill that you want to scale. And if I was having this conversation with you 25 years ago, I would be like, you got to know your text editor. You got to know how to do da da da da. You got to know this tool and that tool, and you got to know this other thing. And, oh, you need to learn this other thing.\n\nAnd it was all the kind of things that a junior to intermediate level developer would be focusing on, mastery of what's right in front of me. And then, you start realizing, oh, I spend all my time tackling problems that are bigger than 12 people together. We need to learn how to communicate. And I'm no longer in a spot...\n\nAnd the great thing is, we end up hiring juniors who are trying to master their tools and, like, don't bother me about communication. I got to figure out how to use this tool to do this thing. And you're like, yes, you need to keep mastering your basics, but while you're doing that, I need you to come talk to me about...And I think it's interesting that the higher up in the seniority you go, the larger the problems you take down, and then, all of a sudden, the problems that you've experienced are at that level instead of one level down. \n\nWILL: Well, I mean, I also say this. I think one of the real bear traps in the industry, another [inaudible 54:48] difficult problem in the industry is not knowledge transfer from juniors. Juniors are actually pretty comfortable, usually. Usually, they're very comfortable. The really tough ones are the seniors. \n\nMIKE: [laughs]\n\nWILL: That's leadership with a capital L because, like, you know what I mean? You're going to take Ls. Things are going to move. Things are going to change. The needs of the organization are going to change. The needs of the industry are going to change. Like, things are going to move, and there's a natural human reluctance to look foolish to, like, be a beginner again, and again, and again, and again, and again, and again, and again. Knowledge transfer among seniors, and keeping seniors current, and keeping seniors flexible and empathetic, and stuff like that, that's the real challenge. \n\nDAVE: Convincing somebody that this style of code is more readable than this other style when they are utterly familiar with that other style, and they're like, \"Well, clearly, it's readable.\" And I'm like, \"Nobody else on the team agrees with you. It's familiar to you. It is unreadable to us. Would you consider doing it this way?\" \n\nAnd you get that spot where, as a junior, you're humble, and you're willing to change anything. And you get to intermediate, and you're like, \"What I know works.\" And then, to get from there to senior, you have to go, \"What I know works, and what you know will also work, and we're going to do it your way because we need to move.\"\n\nMIKE: And that is hard. I read an article the other day by a scholar of the Hebrew scripture. The specific text isn't that important. The important thing is that it was written a long time ago. And what he said was that there's this recurring theme that you have a leader who starts out humble, and they apply that humility, and they become very prosperous, and they get set in their ways, and it causes all kinds of trouble [laughs]. And it's not a new problem. It's not a new...but we still have to fight it, you know [laughs]? And we have to be willing to do some introspection and say, \"I'm that guy now. And I need to be willing to humiliate myself.\"\n\nWILL: Well, I mean...so, go ahead.\n\nDAVE: I'll just say the biggest compliment, I think, I have ever been given in the last year was also from Eddy, ironically. I like Eddy. He says nice things about me.\n\nWILL: [laughs]\n\nDAVE: But we were in a meeting, and I asked, like, a bone stupid...I mean, like, the kind of question that everyone in the room was like, you're asking that? I won't go into the question now because if I don't give you enough context, it's going to sound like an offensively stupid question.\n\nWILL: [laughs]\n\nDAVE: And it was, it was borderline offensively stupid. But as soon as I asked it, all the juniors went, \"Yeah, I want to know the answer to that, too.\" And so, we realized we had zero knowledge share. Like, everyone on the team thought everyone else on the team knew the answer, so they didn't want to ask. And Eddy turns to me, and he says, \"You are fearless about asking stupid questions.\" \n\n[laughter] \n\nAnd momentarily, I was kind of offended. And I'm like, no, he meant that as a compliment, and he's sincere, and he's right. I'm willing to ask really, really dumb questions. If I feel guilty, if I'm self-conscious, I will say, \"I know the answer to this, but just so everyone else knows, you know, it's like, how is this working?\" And you got to be willing to do it. I've had people get impatient with a stupid question, but I've never had somebody think I was stupid for asking a stupid question. I've never had somebody think I was a coward for asking a stupid question, to put it that way. \n\nWILL: Do you guys want a life hack for embracing your inner idiot?\n\nDAVE: Oh yeah. \n\nMIKE: Yeah.\n\nWILL: All right, so this is what I do. This is, like, actionable stuff. This is the Slack life hack. I won't discuss ticket work in a DM, and I won't tolerate other people discussing ticket work in DM. If you got a question about how to do your job, it goes in a channel. Maybe the team channel. It doesn't have to be in a public channel. You don't have to put it on general, or whatever, but everything. \n\nIf it's like, \"How does this work? Hey, do you remember how to do this API?\" Anything. Anything at all. I mean, if you want to have a private conversation with me, it's totally fine. Let's talk about our weekend. Let's talk about the dumb thing that thus and such said in thus and such meeting. Like, \"I can't believe David had to ask that, Jesus, that guy [laughs].\" But, like, none. Ever. None. Zero. No chance.\n\nDAVE: There's a countervailing force that you have to be very vigilant for, which is all it takes is one VP to say, \"Just get it done,\" when somebody asks a question. Those questions will evaporate because, all of a sudden...we've talked about psychological safety before on the podcast, right? Where it's like, if you have someone out there...when somebody asks a question like that, the response from the people who know the answer should never be, \"You should know this.\" \n\nThe answer should be, \"Yeah, you should know this. Let me tell you. Thank you for asking this because I should have told you this.\" And that is so, so helpful is to be welcoming of the dumb questions because if somebody's not willing to ask a dumb question, you got a lot of people walking around with a dumb question unasked, which means they don't have the obvious answer, which means they're dumb. It's...yeah.\n\nWILL: And, I mean, the other thing that is like, you know, to be perfectly honest with you, I mean, there's always teams shifts and teams ebb and flow, and people come in. And conventional wisdom that everybody knew six months ago it's like, well, you got three new devs on the team. They don't know that. How could they? They weren't there.\n\nAnd sometimes I just forget, okay? Like, I'm lazy, okay? I am. I'm as lazy as I can get away with being. And also, also, also, it becomes, like, an unofficial Wiki. I'll search a Slack, you know what I mean? I'll search a Slack Channel. Oh, weren't we talking about that thing the other day? And then, I'll find it, and I'll probably post it again. I'll probably repost that link because that's just how it goes. \n\nI mean, in terms of VPs just being like, \"Just get it done,\" you want to be out of this thread because you got other stuff? The response to that is, \"No problem, Jim Bob. We're going to work it out.\" I'm going to start another thread, and Dave and Mike, and I are going to figure out exactly how this thing gets done, right? \n\nIf VP is saying, \"I'm delegating this,\" that's fine. The only thing I want to hear is, \"We got you.\" And then, the team figures out how to do it, and, like, they don't pinged every 30 seconds as we're hashing it out. That's fine. If he wants to go cook, let him cook. It's fine. This is my job. I got it.\n\nMIKE: I think that's a pretty good stopping spot.\n\nDAVE: It is. This was awesome [laughter]. You know it's a good podcast when you want to do two more hours on the tangents that you've dug up part way along the thing, yeah.\n\nWILL: Well, happy Friday, gentlemen.\n\nDAVE: All right.\n\nWILL: You all be well.\n\nDAVE: Have a good one. Cheers.\n\nMIKE: Thank you. Until next time on the Acima Development Podcast.","content_html":"In this episode of the Acima Development Podcast, Mike shares a personal story about his father, a custom staircase builder, to illustrate the importance of balancing speed and thoroughness in work. Mike’s father, known for his meticulous craftsmanship, often took extra time to perfect even the smallest details of his projects. Mike contrasts this with a quick-fix job he once helped with, where speed was prioritized over perfection to meet a deadline. Both situations were appropriate for their respective contexts, highlighting the need to adjust the level of care based on the type of project at hand.
\n\nThe hosts dive deeper into this theme, exploring how the right balance between velocity and thoroughness can differ depending on a company’s stage of growth. Will points out that startups often need to prioritize speed to survive, while established companies must focus more on quality and performance. They discuss the challenges of maintaining speed when stakes are high, particularly in large organizations where even small inefficiencies can have significant financial impacts. The conversation emphasizes the importance of adapting processes and expectations based on the specific goals and constraints of the work.
\n\nFinally, the episode touches on the crucial role of communication and knowledge sharing within development teams. Pair programming, mentoring, and asking questions openly are all identified as valuable practices for ensuring that team members can move quickly while maintaining quality. The hosts stress that leadership should stay involved in the coding process to maintain a connection with the work, encourage a culture of learning, and foster an environment where mistakes are seen as opportunities for growth, ultimately helping teams strike the right balance between speed and quality.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I am hosting again today. With me, I have Dave and Will.
\n\nDAVE: Howdy, howdy.
\n\nMIKE: I'm going to start with a story, actually, well, two kind of connected stories. I'm going to talk about my dad. He's a builder. Well, he's retired, but [laughs] he spent most of his career as a builder. And most of what he did was custom stairs. Most people don't want custom stairs [chuckles]. It's the people who can afford the custom stairs who ask for the custom stairs. So, he did a lot of work for, you know, people who can afford to pay to have custom stairs done. And the people who pay to have custom stairs done are looking for a certain kind of work, right?
\n\nWILL: Gone with the wind, grand entrance, duh. Yeah, I didn't get the Scarlett O'Hara dress for nothing.
\n\nMIKE: [laughs] So, circular stairs, you know, he did the spiral stairs, and that was kind of his specialty. And it's not just my dad; he did it with his brothers. He's got two brothers he did with. And they, you know, built stairs for years. And in my...well, I have personal experience. So, my dad built a house to sell, and this was in the late '70s. Everybody knows a big economic issue happened then, and people weren't buying. So...
\n\nDAVE: That was like the gas crunch, right?
\n\nMIKE: Yeah, exactly. So, the house didn't sell. He ended up moving in, and he's still there. [laughter] So, he probably over-housed, but he's been there. But, you know, he just can't...he spent his career doing this custom work, this custom, you know, the best quality you can get, right? And he's continued to work on the house. Can't help himself [laughs]. And so, everything he does, the floor and the kitchen, it's amazing. But you wouldn't pay for it because you couldn't pay for it.
\n\nHe found an apple orchard where they were getting rid of their trees, and he cut the trees into layers and dried the wood, and then sanded it down, and cut it into the right shape. Well, cut it into shape, then sand it down because it warps after you've cut it. And so, it had to be cut thick, and then process every one of those pieces to get it to the right shape. And it's like every one is, like, at the heart of the tree. Once it was sanded, laid it all down, put epoxy on it instead of, like, your standard polyurethane, so it will last forever. It is just absolutely stunning.
\n\nBut it's the thing you can only get by doing custom work, right? And when I've helped him...and I've helped him a lot. I've done some work there, and I, of course, worked with him when he was working outside the house, and [laughs] his standards are exacting. He's not a jerk, but [laughs], you know, he does quality work. And people work for him; he wants that work done.
\n\nAnd so [laughs], the work is great. Everything he does is done, exacting perfection. A lot of the work he does himself because he knows he's the only one who will give it that kind of attention [laughs] to actually get it done the way he wants it done. The one time when I've been doing a lot of work with my dad, I went and helped a cousin of mine who was moving out of the trailer he'd been living in. Though it was kind of a dump, and they wanted to make it look nicer before they moved out.
\n\nAnd I remember I was putting in some molding along the floor, just some cheap, little, thin stuff, and they asked me if I could do the corners. I was like, "Yeah, sure." And the speed at which we did the work in that trailer...I was getting together some, you know, some other family folks. And we got together and quickly did a whole bunch of work, you know, got together in three hours and redid all kinds of stuff in this trailer.
\n\nThe floor was totally out of true, right [laughs]? So, trying to get that corner right was nearly impossible. I think, eventually, I put some sand under the linoleum to get it [laughs] leveled so [laughs] [inaudible 04:11]. And we got it all together. It looked a lot nicer, so we could sell it. And we were done. And here's the thing: in both situations, the right work was done. If you're going build a custom stair for somebody who wants a custom stair, well, you're going to give that every little bit of attention to detail that it deserves. If you were getting that trailer ready to go so you can quickly sell it, you're going to do that quick because that's what it deserves.
\n\nAnd that's not to say that the trailer doesn't deserve care, but it would be incongruous [chuckles] with the rest of it. It wouldn't be worth the value of that whole structure. You know, there's people who actually make a small home look really nice. I've seen that before. This one was not. This was not one of those homes [laughs]. This was not [laughs] one of them. But both of them were right.
\n\nThere's a balance that you have to strike based on the work at hand, and sometimes you got to get that done. And, in fact, most of the time, the work we do is probably more like that trailer, right [chuckles]? We need to get the work done. And I'd say this: I say more like, I don't like to do shoddy work. I want to do quality work, but some things need to get done.
\n\nBut then there are other things, you know, if I'm building something that has anything to do with money [chuckles], I want that to be done right. And I want somebody inspecting that [laughs], going over with the white glove to make sure there's no dust on it, you know, because you do not want to mess that up. And, you know, there's a time and a place for both.
\n\nWhat we're going to talk...I'm leading with a story. I haven't even talked about our topic today. We're going to talk about the trade-off between velocity, you know, between working fast, getting things done, and being thorough. And I thought about, you know, the stories because it is a trade-off. If there was a clean answer, then we'd all be doing it.
\n\nAnd the problem is we often tend to err on one side or the other, right? We tend to maybe go the wrong way for the work at hand, and we get in trouble. And sometimes, you maybe get...and we've probably all worked with somebody who had the work to do, and then they just didn't do it at all, you know, they're off [inaudible 06:37] [laughs].
\n\nI did some construction work in New Orleans area. I used to work for a construction company in New Orleans. And there was one job we'd worked on it for months, and, basically, it was done, right? It was done, but we weren't ready to move on to the other contract. And there was a couple of days where there was nothing to do. So, they said, you know, "Go around and look busy." I spent two days polishing the outlet covers [laughs]. So, when somebody came in, it looked like we knew what we were doing.
\n\nAnd there were some people who probably spent more time polishing those outlet covers on other days [laughs] than they should have. There's that problem, too. I think we may delve a little bit into that, but starting with the topic of balancing this work of, you know, this balancing between being thorough and being fast. I've been talking a lot. I heard that Will had a story. I'm interested in what y'all's thoughts are and how you'd link it up.
\n\nWILL: So, more I have a thought to share because I think a big piece of the thoroughness is sort of the phase of the company that you're in, right? But when you're in a startup and you're throwing features out the door as fast as you possibly can, and maybe you're going to take down the app; it'll come back up, there's not that much...you have different set of risk, right? Like, the risk you have now is you're fundamentally insolvent. You're going to run out of money. You're going to run out of time. And you have to figure out how to make a product that is worth buying. And that is your existential risk.
\n\nHowever, if you're working for a large, multi-billion dollar company and you screw something up, and your page loads 5% slower, you know, there are direct correlations to sort of website performance and click-through rate, and conversion, sales conversion, right? Like, Amazon did studies on this stuff, and if your stuff is too slow, people don't buy. If your site is not fast to navigate around, people will leave. And so, that stuff is really, really important.
\n\nAnd so, I'm talking about sort of a thoroughness-fitted finish kind of a thing. I'm not even talking about your stuff crashing. I'm talking about your stuff not being fast enough. It's like, oh, well, what if I lose five basis points worth of sales because I just didn't do as good a job as maybe I could have? Five basis points. A basis point is a percent of a percent, right? I just burned my salary for the year, just like that.
\n\nThis is the phase of the company, and there are indisputable properties of just having a going concern that makes a lot of money. The impacts to the bottom line are substantial. You do need to be thorough, and I would...I always advocate for my developers. Like, if you've got a billion-dollar business, you should pay more for the people working on your site because it makes a difference, whether they're good or bad.
\n\nAnd one of the things...and maybe I'm going to answer your question with a question, or maybe I'll just add on another one. How do you maintain velocity in a situation where you have a big enterprise; you have a going concern; you have stakes? If you screw something up, how do you keep that velocity? Because it's easy to analyze yourself into a state of paralysis. You still need to innovate. You still need to develop products. You need to be, you know, delivering results on a quarterly basis. Because, on every level of the company, they demand that, and that is what you're getting paid for. How do you balance that, right? Because both things are true. You can't screw up, but you got to get things out.
\n\nMIKE: That's a good question.
\n\nDAVE: I keep coming back to this idea of, what are you really trying to do? What are you trying to accomplish? If you're in a startup, you're not going to be taking on IBM or Amazon. You're not competing at that level. And there's a phrase that you'll hear a lot which is, "The ideas that got us here won't get us there," when you're trying to scale. And the ideas that got you out of startup mode into productivity those ideas will not get you to scaled enterprise-level stuff. But the reverse is true.
\n\nWhen you transcend the old ideas, don't discard the old ideas because what gets us there won't get the next cohort here. You end up transcending, and then pulling the ladder up behind you. I don't know if I'm making sense with that, but it's like, you start saying, "Hey, we need to have SOX compliance. We need to have peer review. The person who writes the code should not be deploying the code."
\n\nAnd then, you bring in a scrap team that are going to do a skunk work thing of like, "Hey, we want to stand up a quick, little server that will just check this thing on this rating service." And you're like, "Okay, cool. Where's my SOX team? Where's..." no, no, no. You have 30 days to ship this, and the right solution is to just ship it. Cut features until you ship. When you have to play at that level, like, if that little service is going to connect to the accounting database, okay, no, you cannot ship this in 30 days. That is not a working solution. But if you're just trying to do something like, oh, I just want to check your membership loyalty points, that's easy. It doesn't need auditing. It doesn't need review. Just ship what they need.
\n\nI'm sure you've all heard this. Growing up, I grew up in a kind of rural, you know, redneck part of the country. And I always heard all the time, "If you don't do it right the first time, when will you have time to do it over?" And then, I got into the software business, and I realized, no, the mantra in startups is, if you don't do it wrong fast, when are you going to get the cash flow to fix it and do it right?
\n\nAnd so, yeah, the ideas that get us to here are not the same ideas that will get us to there. And you need both, but not at the same time. You have to stay alert to, which mode am I in? Am I in enterprise, secure mode? Am I trying not to lose the eggs that we've collected into our basket? Or am I desperately trying to forage quickly and get as many eggs into the basket as I can, and then we'll sort out if I accidentally stole your eggs, or whatever; we'll sort that out later? But at the enterprise level, I don't need that level of security. I have to get the eggs collected. That's 17 metaphors rolled up in a weird ball, but there you go.
\n\nMIKE: You know, you're talking, Will, yes, you know, how do you keep the velocity going when you have those constraints? Another story [laughs]. I ride bikes a lot with my kids, bicycles, not motorbikes, but, you know, pedal-powered. And I discovered something great [laughs], and it took me years to find this, and I'm glad I did.
\n\nYou can attach a tow...it's not a rope. You can attach a tow cable. Basically, it's a bungee cord that's wrapped in ripstop nylon that's been scrunched, so it's tough. You got the bungee cord inside. So, you don't have all the problems with a bungee cord, where it's going to have that hook, and it's going to tear your eye out [laughs]. But it, you know, it expands and contracts.
\n\nSo, I attach it to the back of my bike, and then I attach it to the bike of one of my kids, right? And then, I've actually got two of them, so then I attach it again in a daisy chain [laughs]. And I've got my three-year-old that I'll put on a seat on my rack. So, I've got three kids, you know, all in a line behind me, and I'll go for a ride. And I've been doing that a lot over the last year.
\n\nAnd I'll tell you, the first time was hard [laughs] because that adjustment from riding, you know, riding with no constraints on you to riding with three people pulling behind you is a shift [chuckles]. And I even had to make a change. The bike that I was riding a lot...well, I've got a fat bike. So, I've got fat tires that are, like, four and a half inches wide, so I can ride in winter right on the snow, packed snow. It still doesn't work in too deep snow [chuckles]. And I've done a lot of riding on that and some mountain biking stuff. Even though it was made to go up some steep stuff, it wasn't geared low enough. So, I've got a gravel bike that's got a...lots of stories about bike, but we need it for context here [chuckles].
\n\nDAVE: It's okay.
\n\nMIKE: It's got a huge gear ratio. It's got a gearbox. It's got a huge gear ratio. And I can go really slow. And I can go pretty fast, too. But I can drop that thing down into an incredibly low gear. I have never gotten to the bottom gear yet, even pulling three kids, even going up a steep hill. I've never gotten to the bottom gear. I rarely get below...like, the lowest I ever get is, like, fourth [chuckles] out of 12. So, I'll give you a sense that, you know, this thing goes way low. It's awesome.
\n\nBut [laughs] I had to change the way I rode my bike so I could keep moving forward, right? I had to change. And then, the reverse is also true. On the occasions I go out alone, I, like, almost fall down [laughs] because I'm used to having all of this mass behind me. And I have to rethink my riding style. We've got the same kind of thing, you know, thinking about this velocity. One time, I went on a longer ride with my kids, and I went up this, like, mile-long hill. And there was a headwind, a really strong headwind. And I was going mostly up that hill at, like, between three and five miles an hour, so, basically, at a walking pace.
\n\nDAVE: Just fast enough to keep the bike from tipping over.
\n\nMIKE: Exactly. Fast enough to keep the bike from tipping over. And if you were trying to do that, like, most people on a bicycle would just agonize over that because you're just not getting...that spot in the distance is not getting there very quickly. But the important part was not to get there quickly. I had a headwind. That was just the reality, right? I'm going up a hill. That's the reality. I've got all this weight, and this is the reality.
\n\nThe important thing is that I keep pedaling. And as long as I'm keeping on moving, you know, your brain, you can adjust to it, right? You can adjust to these new constraints, and you just keep on going, right? You're not going to go as far. You're not going to go as fast, but it doesn't matter. The important thing is that you don't stop. Because you could think, well, I'm not going very fast. What difference does it make if I just stop? Well, it makes a huge difference [chuckles]. Stopped is very different from moving forward.
\n\nWe're going to be in different situations, right? Sometimes we're going to have the headwind. Sometimes we're going to have a bunch of constraints we have to deal with, a bunch of weight we pull along with SOX compliance, you name it. But you can still set up the processes and run basically the same, right? If you're moving forward, you're moving forward.
\n\nThe key thing is that you never get in that situation like, well, we're not going as fast as we were over there. So, what we're doing doesn't work. We've got to break everything, either by stopping because, like, well, this doesn't even matter. Very bad choice. Or saying, "Well, we need to completely reorganize our process. We need to get our velocity up to exactly this." Well, that's not realistic either. Because if you've got all these constraints, I think they're there, and you got to just deal with that. And you can adjust to it. Like, you can adjust to a lot, as long as you're keeping on moving. And it's really critical not to try to compare different kinds of work because they really don't correlate.
\n\nDAVE: You just connected two epiphanies that I've been carrying around for 20 years. This is exciting. When you mentioned that the important thing is to keep peddling, to keep moving, I had a job very early on in my career. I was moving out of, like, minimum wage jobs and into, like, my career. I was actually writing software for a living. I was on the networking side, so I was pulling cable as well. I was literally, like, crawling around behind people's desks and dragging cable. And if there was a hardware problem, I had to deal with the hardware. I ran a soldering iron at one point, right? I was all over the map.
\n\nAnd my job was to be the network guy. My job was not to break down boxes in the shipping room. My job was not to, you know, manage the sales cycle. My job was the networking stuff. And I came in and the stockroom in the back was getting piled and piled up and piled up with supplies of stuff. And I was in this mentality of, hey, I got to get this network stuff. It's not my job to do this.
\n\nAnd I walked in, and my boss was in the back room cutting down boxes and breaking everything down. And I'm like, "Wait a minute, if it's not my job, it's really not your job. What are you doing?" And he just looked at me, and he's like, "We need the space in order to get our job done. I'm an expensive stock boy, but I'm going to get it done."
\n\nAnd that was the epiphany for me of; sometimes the objective is, am I doing the job that I'm supposed to be doing? And sometimes, the focus is what do we need to accomplish? The how doesn't matter, but the what is what matters. So, I've literally carried that around in my head: I'm an expensive stock boy. I carry that around, and it has availed me very good over the years.
\n\nThere's been times when it's like, there's this big, messy part of the project that nobody wants to touch, and I don't want to touch it either. But then I look, and I'm like, well, that is between us and done. So, I'm going to go be an expensive stock boy and just take care of it. And, usually, somebody higher up on the chain will go, "Ooh, that's an expensive stock boy. Let's get a stock boy." Or they go, "Yeah, we just needed that room cleaned out once, and it needed to be done. So, that was the right price to pay for it once."
\n\nWILL: I think that's a big...I've seen it a lot as sort of like, you know, teams specialize, right? And they sort of fragment into this archipelago of little islands, you know, that make up this country. And then, you have, you know, directors and VPs and stuff that they have their little region, their little fiefdom.
\n\nAnd I think that is one of the hardest things in terms of scalability, in that you still need people who take ownership of the entire organization, the entire app, the entire end-to-end experience. And, honestly, like, one of the things...I was just talking about this today. Like, where I think that breaks down really badly is sort of in the corporate hierarchy, like, the people you'll have are, like, VP or a director that isn't in the code every day, doesn't know where the bodies are buried, doesn't know how all these things interoperate. They have the visibility, but because they're not in it every day, they're very detached.
\n\nAnd I think there's a little bit of a black spot in the industry for somebody who is VP level or whatever your broad organizational level leadership. But they're an engineer. They're doing work. They will cut down boxes. Oh, this ticket was screwed up? I'm going to clear the ticket, and if you can't...I mean, bluntly, I know a lot of smart people, and I know a lot of smart people who've moved into management, you know, leadership positions. But you have to pay your dues. You have to pay the toll. If you want to ship code, you got to ship code. You got to put in your [inaudible 22:46]. Nobody gets an out.
\n\nIf you are rusting, you know, then you're rusting. I mean, just like after a year on the bench as the manager of the team, like, you're going to have to ramp up just like a new hire would, maybe not that bad. I've seen it fixed places, you know, with things like principal engineers and stuff like that, but it's a systemic problem. And I haven't really seen a systemic solution other than senior, senior leadership recognizing the problem and being proactive and making sure those people are there and empowered.
\n\nBecause a lot of the stuff you'll see is, they'll go around peeing in some Cheerios. There are a lot of people who have pet projects. They have things that they're doing. They have deliverables and stuff. And somebody comes in and says, "Hey, like, the interop between this department and this other department is all screwed up. Our codebase is all screwed up. We have technical debt. We've got performance and security considerations. And I'm going to have to like, you know, I'm going to screw up your quarterly results because this broad thing happens at like..." you know, there are a lot of smart people with interests in kneecapping those kinds of systemic engineering initiatives and accountabilities and stuff like that, you know, it's a ferociously difficult problem.
\n\nAnd I was contending with that earlier today, like, wanting that person in that role to come save me like Superman. I need heads cracked, and I don't have the juice to call these people, you know, behind the [inaudible 24:44] I can't do it. I know it's screwed up. They know it's screwed up. Anybody who's looking at it knows it's screwed up, but, like, the people that can can't [laughs], you know what I mean? I suppose a tangent, but a thought that was on my mind.
\n\nMIKE: Well, you said something. It's something I've thought about a lot. I've heard a lot of times, people who do hands-on, you know, typically blue-collar work, working with their hands, talk about how much the leadership doesn't get it. Like, "They just don't understand the work we do." And I can't count the number of times I've heard that.
\n\nAnd I think it's generally, like, I almost take it as a truism because I've heard it so many times that if you have somebody who hasn't done the work or is not connected to the work, they're going to miss things that are important. They're not actually going to understand what's going on. And, to your point, it doesn't matter how much you're looking at it if you don't know what to see. And it seems like there is a critical need for leadership to actually have either gotten their hands dirty or be willing to listen to the people who have and actually respect what they have to say.
\n\nWILL: Well, I don't want to be a jerk about it, but I will say this directly. You got to keep on paying the toll. Rust never sleeps. Every...I don't want to say every but, virtually, every senior engineering, leadership, management person that I have worked with I know in my bones started out as an extremely competent individual contributor. At one point, they were all good. They were all really good. I mean, once you get to the director and above level, present company accepted; once you get to that level and above, it starts to catch up with you because you know what your schedule looks like. Mike's shown me his calendar.
\n\nMIKE: [laughs]
\n\nWILL: When are you going to get your hands on the iron and do it? It's a luxury. That's like a day off. And if you don't do it, it catches up with you because everybody has to pay the same toll. If you want to be good, you have to continue sharpening the saw. Rust never sleeps. And that's when you run into these sorts of difficulties, the very difficult line to walk.
\n\nDAVE: It works backwards as well. I remember the first time I worked for a manager who had a string of managers in the early noughties and mid-noughties. They were, like, senior developers. And cowboy coders didn't get along with anybody, but they were very, very good. And they ended up in, like, CTO positions, and nobody wanted to work for them, right? Because they had no people skills. And the ones that had people skills weren't necessarily applying themselves to what type of battles do I need to fight at this level? They were still trying to focus down here.
\n\nAnd the first time I worked with a manager who came in and said, "Yeah, I used to be a developer, but now I'm a manager, and this is my job," and, like, the first three or four months working for him I hated because he would actually make me do one on ones.
\n\nWILL: [laughs]
\n\nDAVE: And I'm like, no, everyone knows that one-on-ones are uncomfortable, and nobody likes doing them. And after three or four of them, I'm like, this is really productive. I actually feel like I'm driving my career in a great direction because I'm actually doing this.
\n\nAnd that was the time that I finally realized that...and it goes back to what I said earlier. The ideas that will get us there are not the ideas that got us here, right? You need that reference. You need that empathy for the people working under you. And you need to be able to look beyond and say, "What..." It's the same thing. If you're not focused on what it costs to write code, you're going to have some struggles.
\n\nBut if you are the manager and your job is to be aware of like, oh, AI is coming, and we need to be ready, or we're going to wake up, and our industry is going to be gone, you know. And do we want to have gone with it wherever it goes? And, I mean, that's one example. Somebody will react too strong to the mention of AI, but you get what I mean, right? There'll be something that, like, we're going to do this initiative.
\n\nWe talked about this in a meeting earlier today about a manager who said, "We're going to pursue this initiative." And it was the wrong initiative. Turned out we got there, and there was no opportunity there. And it cost some people their jobs as a result, and that was no fun. And it was failure in both directions. Like, this person didn't understand the engineering, and they also didn't understand...they had a view of what ecosystem they wanted to put in place. And they managed to solve the wrong problem in both directions.
\n\nWILL: [laughs]
\n\nDAVE: Somebody said, "We're leveraging the inefficiencies of both approaches. [laughter]" That was, like, anti-synergy.
\n\nWILL: That's almost impressive.
\n\nDAVE: And I've been there. I've been on a team where I had a cowboy coder working with me, and I was, like, the meticulous, make sure your tests pass; make sure your code is expressive; make sure to actually dah, dah, dah. And there were times when I'm like, "You're going so fast, and you're breaking things." And he was like, "You're dragging an anchor when we need to get stuff done." And there were times when we got so much at loggerheads that we ended up shipping too little, too low quality and too late because we leveraged both of us. We both dug in our heels, and we ended up with nothing.
\n\nAnd I think I've told this story here, but I worked with a guy named TJ at CoverMyMeds who was astonishingly good at picking his battles. And he and I were really good friends, and he got really, really good at seeing when I was about to turn and go down a rabbit hole. And he would just kind of put his hand on the back of my belt, and say, "Whoa, whoa, whoa, whoa, wait, we don't need to go down that rabbit hole." And we fought a few times over [inaudible 30:55]. And I finally said, "You know what? You're right. We don't need to go down that rabbit hole."
\n\nHe was one of the first people I've ever worked with where pair programming delivered on every promise pair programming has ever promised anyone. And we were also linearly faster. Like, the two of us could complete a sprint's worth of work for two people in, you know, a week and a half. We literally...every way we went faster because the synergy worked so, so well because we were solving the right problems, and we were leaving the wrong problems alone. And that...oh, so good.
\n\nWILL: I'm a pair programming seller, and I always evangelize pair programming.
\n\nDAVE: Amen.
\n\nWILL: I think it's good. It's not a silver bullet. It shouldn't always be everythings all the time, but I think it should be...I think we should do a lot more of it. You know, pair programming now, pair programming, you know, forever. Like, that's all. That's all I'll say on that. That's all I'll say right now.
\n\n[laughter]
\n\nMIKE: I got to say, it's one of my favorite things to do because the amount that you learn on both sides of a pair [inaudible 32:11]... a lot of times, you have a more senior, a more junior person, but it tends to flow both ways. The amount of knowledge transfer that happens there is unlike anything else that I've experienced in software development.
\n\nLike, you can read documentation, and a majority of that is just going to pass right through your brain [laughs], not that it's not technically possible to go read some dry technical documentation and get lots of clarity from it. But when you're watching somebody work, or they're watching you work and seeing how you make each of those decisions, it just changes that equation typically. You see all that weren't captured in the documentation that you just wouldn't see otherwise.
\n\nWILL: Yeah, well, I mean, and if it's your stuff, you know you didn't write everything down. You know you didn't do it. But, anyway, a lot of stuff you're talking about, I really do feel like a lot of those that, as line-level managers, I'm going to say flat out, I'll take my hot take; this is your hot take of the session, I think all line-level engineering managers should spend 25% of their week, maybe 20%, right? Eight hours a week, a full workday, every single week should be pairing with the people on their team so that they have both an understanding of like, okay, here's what's going on.
\n\nIf you're a line-level manager, you should be a very proficient coder. You should be a senior-level engineer. You should be good at that. You can't be like, "I'm a VP. I don't care anymore." No, no, no, you don't get that out anymore. You should be providing that kind of judgment, that kind of insight, that kind of understanding. You should be working with your team and figuring out where everybody is. Don't [inaudible 34:15] like a one-on-one. Get in there and feel it.
\n\nAll right. Are you writing tests good? Are you thinking about parallelism? Are you thinking about error handling? Are you thinking about design? You know, all this stuff. You get paid for that. That's why people pay you to be around. And it keeps your hands, you know, in the iron, and you have a feeling for how things are going.
\n\nI'm actually on a Slack thread right now with three, four staff engineers who are like, "Why are my builds so slow on these laptops?" And I have been fighting the good fight. There is a security team that has installed real-time virus checking on all engineering workstations. And it is virus scanning intermediate build products in real-time. It's a substantial CPU hit. I have been wrestling with these guys for a long time, many months. And these guys didn't even know. They're just like, "Wait. Wait, what? It's doing what?"
\n\nAnd I'm like, "Yeah, man." I've been arm-wrestling these guys to try and find a more economical accommodation to satisfy their security concerns while I can still ship these features. And if you never code, okay, you know what I mean? You're a director. You're a VP. You're up the levels. That's not actually your job anymore. You probably are wasting your time doing that.
\n\nBut, like, line-level managers, I want your hands...I want you in the muck with the rest of us, at least a little bit, so you know what the hell's going on. Because even when that front line, you know, your NCOs or whatever you want to call them, you know, the people who are on the front line, if they've checked out, how's the information going to filter up? You know what I mean? Anyway, my two cents.
\n\nDAVE: It's how do you get feedback? Yeah.
\n\nMIKE: I've got one pushback against your hot take. I don't think 20% is enough [chuckles].
\n\nWILL: Yeah, sure. I mean, you're right. I agree. I think 25%...I think 50% is probably where I would cap it, but it's somewhere in between there. But I don't think...how do I put it? Like, I'm not asking for 30% and expecting to get 20%. This isn't like a negotiation where I know I'm not going to get everything I want. Like, I'm just saying what I need. This is the real number. I want a real 20%, and getting 8 hours consistently every week out of a manager's schedule to pair program is a substantial ask. That's hard to do. You need support. That is a rare bird to make even that happen.
\n\nMIKE: I stepped into leading an internship once, where the person who was leading it...I say an internship, it was an apprenticeship. There were some people that we wanted to bring in to be full-time engineers. They weren't coming straight out of college. These were generally people who'd maybe been in another profession, and they were ready to come and learn what they're doing. And I'm not the one who started it. The one who did left, and I stepped into it. This was a number of years ago.
\n\nMy manager at the time said, "I think you should be spending 50% of your time writing code." And I laughed at him [laughs] because I was spending, you know, like, 80% of my time pairing with those apprentices. Because how else were they going to learn the ropes unless they were working with somebody? And --
\n\nWILL: Well, but that counts. Pairing time is coding time.
\n\nMIKE: That's true. Fair. Fair.
\n\nDAVE: I remember pairing with Eddy Lopez here at Acima when he was fresh out of it. He was fresh on the engineering team from QA. He might have still been on QA. And he and I were pairing, and I asked him something, you know, "Where's this in the source control?" And he wasn't sure how to...and he's like...And I'm like, "Okay, hang on." And I cracked open a terminal, and we spent an hour playing with Git. "And I'm like, here's where to put it. Here's where your sandbox is. Here's the distributed nature. I can be the server. You can connect to me, and I've got all the changes because da da da da da." And I was explaining where the deltas go and all that stuff.
\n\nAnd we were on the podcast a few months ago and Eddy pulled this story from his perspective, which is that he has paid that forward so many times. And I'm like, that was probably one of the most effective hours of my entire career because I invested in someone who then has now paid in, you know, bazillions of dividends. And I'm not trying to blow my own horn. I'm really happy that that happened. When Eddy was like, "Oh, yeah, you did this, and I love it," I'm like [vocalization], I'm going to go for a long time on that compliment. So, it's awesome.
\n\nMIKE: We landed into the value of sharing information. We've rerouted a little bit because [laughs] it was just such an important topic. Have we really hit how you keep that velocity going, how you keep moving? Because you asked, I think, a vital question, Will. And I gave kind of a metaphor, but I don't know if I got really into the technical details, how you do it on a development team. How do you keep that motion going?
\n\nWILL: And, you know, actually, like, so there's another issue. Like, I have a lot of meetings on Friday. I'm trying to put my meetings on Fridays, because, listen, man, I'm going to show up to work on Friday because they're paying me, and I will do it, but they're not spending their best [laughter]. It's a fairly linear degradation of my engineering effectiveness. I'm still not bad, okay? You got your money's worth out of me today, but yeah, you know.
\n\nAnd so, I was talking with my boss, so my boss long-time consultant. And he sort of, like, you know, went full-time and moved into engineering management. But he spent a lot of time as a consultant freelance, you know, developer, you know, that's me. Like I'm, you know, technically unemployed. Like, I've got a long-term contract with my large electronics retailer.
\n\nAnd it's sort of like my team, you know, that I run sort of runs things my way, which is sort of very like, what have you done for me lately? Like, because I'm just used to the mentality of, like, people are writing me a substantial check for my services every week, and I want them to know what they're getting all the time, and that gets my contract renewed. I got another year. And it's a mentality that sort of the boss shares, and I share. And he's working with another team, and they don't necessarily think about things the same way because they were not brought up in an environment of existential fear [laughs] the way we were.
\n\nSo, I have a story, right? And it's my mom. She had dogs for a long time. She had greyhounds. Greyhounds were her favorite dogs. She had greyhounds. And she liked to get, like, rescue greyhounds, like, retired dog track racers. I don't know if that's such a thing anymore. I think we've kind of phased out dog racing, which is probably good. But, you know, they would retire. They couldn't run anymore. They tore their ACL. Whatever. And they'd just be like, well, we're just going to dump them in a landfill. But I guess if you want them, you can have them, right?
\n\nSo, she would get these dogs. And they were the laziest animals that have ever lived. You'll roll home, and you'll have a golden retriever, and it'll just be ecstatic beside itself, jumping on you, giving you kisses in the face. Almost, if not literally, like, wetting itself because it's so excited that its people are home. It's so happy. The greyhound version of that was...they would lift their head off the ground as they were lounging [laughter], look at you, and their tail would wag three times [laughter], wag, wag, wag. Boom.
\n\nDAVE: Head back down.
\n\nWILL: Head back down. But every time you would take them out in the backyard to feed them, you would get the most magnificent, beautiful, joyous, absolutely astounding run. They would tear around the backyard in a figure 8 at 30 miles an hour. I swear to God.
\n\nMIKE: [laughs]
\n\nWILL: It was magnificent. Magnificent. The most beautiful thing you've ever seen in the world would be just to see the beautiful athletic power and grace of a greyhound, wholesale. Because they had grown up in this environment [laughs] of existential fear, where literally, if they wanted to eat, they needed to run like their lives depended on it because they kind of did.
\n\nAnd sort of like, you know, so my boss and I were talking about how can we...it's not that this other team doesn't have...it's not that they're not smart. It's not that they're not hardworking. It's nothing of the kind, but they don't necessarily have that mentality. And so, the question was like, we've got these sort of deadlines, you know what I mean? Economy is tough. Macro is tough. The business is like...it's not bad, but it's certainly challenging. Everybody is pushing really hard to keep their head above water. Everybody's working hard. And how do we get this team to do the thing?
\n\nAnd what he settled on, and it's been on my mind since we had this meeting, and now that we have this conversation, it kind of brings it full circle, what he settled on was he just sat down with them, and he's like, "Okay, you know, this is our thing." And he just started coding it up.
\n\nAnd he exhibited the mindset of like, okay, we've got to move fast, so let's move fast. Let's do this then. Let's just put it together. Let's get the scaffold up. Let's get the skeleton, the framework. We're going to make some...we're going to build a jig. We're going to make some operating assumptions that allow us to move forward. And we're going to sort of start the rough sketch, and then we start filling in the outline, filling in the details. We're going to paint the color, and the shading, and all those things.
\n\nAnd the only way he could really get this mindset onto these people, you know, which comes from decades of high pressure, high production consulting is to just get in there and show it to them, show them how it feels. And then, as he did it, the clouds parted. And they were like, "Oh, okay, I see what you need. I see what you want to do." And that kind of knowledge transfer, endemic to the work we do. That's why I'm a paring zealot because I don't know of a better way to do it. I don't know of any other way to do it. And I am fully aware of how fantastically indulgent it seems on the surface, and the sort of visceral, like, oh my God, I'm going to pay two of you to just sit there on a single keyboard all day?
\n\nMIKE: [laughs]
\n\nDAVE: That's twice as expensive.
\n\nWILL: Do you have any idea how much this is costing me, you know, to do this? But I just don't have a better --
\n\nDAVE: And then, you let that stop you out, and you're like, okay, well, I'm going to work alone. And you just kind of sit there and go, do you have any idea how much it's costing you to have me work on this without a second brain? It's, you know, yeah.
\n\nMIKE: Well, that's it, right? That what works is what works. It doesn't matter how much you don't like seeing 2 people sitting next to each other on 1 keyboard. It's what works [laughs].
\n\nDAVE: And if you're banging out 30 controllers with just RESTful actions, then one or two for pairing to make sure everybody understands this is how we roll this out. And then, yeah, go to your office and just I'll do these 15. You do those 15. Let's meet back up at 5:00, and we'll review each other's stuff because you're just banging out boilerplate at that point. But you do the first ones together because there's knowledge transfer going on, and yeah.
\n\nWILL: Yeah, absolutely. The question that we had was sort of, like, how do you get that mentality? Because it wasn't even a technical thing. These guys don't know how to do the work. They understand the work. They're very competent programmers. They're really good. But that sort of, you know, that piece wasn't something that they really understood until they saw it. And then, once they saw it, they're like, "Oh, oh, okay, I get it. I understand now. All right, let's go." And then, you know, boom, that's how I [inaudible 48:00]
\n\nMIKE: You know, the kind of meta stuff around software development is so vital. It ends being most of what we talk about on the podcast because [chuckles] it's critically important. But you're probably not going to learn it in school because it's...I don't know if it's...it's probably hard to communicate about but it also sometimes, I think, seems trivial.
\n\nYou think, well, we need to teach you the hard stuff. We need to teach you about writing code, and writing code is critical, right? Learning to express yourself in that way is a change in mindset that does not generally come naturally. And you have to bang on that for years to get good at it. But if you just focus on that, you're missing half the picture.
\n\nLike, Dave, you talked about spending an hour teaching somebody Git. I mean, that is important, learning how to use those command line tools, you know, whatever tools that you use, you know, that are on the command line. Like, learning the tools for your job —that's important. And without that, you're not going to be able to work very effectively. And there are so many things like that.
\n\nWILL: I thought so many people like the debugging, you know what I mean? Like debugging. Like, hey, how to use a debugger. Like, some people don't like using debuggers. Like, you should know how because a well-configured debugger where you could just stop the code, it's like, whoa, whoa, whoa, hang on. What are we doing? Why is that X instead of Y? That's critical. Just the idea, the mentality of debugging.
\n\nI taught some kid just today, you know, another one of my golden bedrock principles, which Mike has heard out of my mouth many times, and I'll repeat it a thousand times more with no shame at all: Always debug from the known to the unknown. I had a guy, he was like, "Oh, my analytics, they're not working. I thought I turned this analytics thing off, but I'm still seeing [inaudible 50:17]. This is all screwed up." I'm like, "Known to the unknown," you know what I mean? And I'm like, "Okay, I wish you'd check out the whole component."
\n\nAnd he's like, "Okay." But the analytics are still fine, but known to the unknown, take out more, delete more code. You got version control. Rampage. Don't do the thing. And he's like, "Oh my God, you know, 15 minutes of just taking a [inaudible 50:40] at this thing until I finally made the noises stop." And I was like, oh, somebody duplicated it. Like, this thing exists in two places from, like, known to the unknown, always go from the known to the unknown. However, you can make it work, make it work, and then move from there.
\n\nI'm like, that's just the kind of thing where it's just like, I think, hopefully, if I got it into his head, that was another one of those, like, one-hour conversations that he'll be like, "Old man Archer said, 'Known to the unknown.'" And I'm going to pop up over his shoulder like Yoda, if I did it right. And I will save him a thousand times [laughs].
\n\nDAVE: Amen.
\n\nMIKE: It's interesting the arc this conversation has followed because we talked about velocity and balancing that. And, certainly, there's a balancing act. But we didn't really linger much on that idea because maybe it's clear in all these different kinds of work. We've talked about how to communicate with each other, and share information, and keep organizational structures effective.
\n\nWILL: Going fast is a feeling. You got to feel it. When you're on a team, and it's clicking, when you're writing code, and it's clicking, when you have the feeling of like, you know, mastering the command of your tools, understanding the organization, the needs, the codebase, it's a feeling. When it all comes together, you feel it in your gut. It feels good. I can't explain it to you, but I can show you how it feels.
\n\nDAVE: It feels like flow, right?
\n\nWILL: Yeah.
\n\nDAVE: You get into it, and you're excited, and then, all of a sudden, it's 6:30, and your wife is like, "Are you coming home?" And I'm like, "Oh, did I miss lunch?" And she's like, "Yeah, you missed lunch. Come home. You're missing dinner."
\n\nWILL: Like, you know, the mentality of like, you know, we need this thing out. We are going to make compromises. If we are going to cut some corners, we're going to cut the right corners, not the wrong corners. We're going to give an appropriate amount of spit and polish to this thing. How do you make those judgment calls? I mean, you just got to know it, and you can get it through osmosis by sitting here with me, or with my boss, with whoever.
\n\nDAVE: Sure.
\n\nWILL: But I can't give you a book and just be like, "Here you go." And that's the weird part of engineering; you got to feel it.
\n\nDAVE: I think it's interesting that we're in a phone call talking about velocity versus thoroughness and all three of us are bringing communication. And what I realize is I think at intermediate to senior levels in your career, interpersonal communication becomes the most difficult technical skill that you want to scale. And if I was having this conversation with you 25 years ago, I would be like, you got to know your text editor. You got to know how to do da da da da. You got to know this tool and that tool, and you got to know this other thing. And, oh, you need to learn this other thing.
\n\nAnd it was all the kind of things that a junior to intermediate level developer would be focusing on, mastery of what's right in front of me. And then, you start realizing, oh, I spend all my time tackling problems that are bigger than 12 people together. We need to learn how to communicate. And I'm no longer in a spot...
\n\nAnd the great thing is, we end up hiring juniors who are trying to master their tools and, like, don't bother me about communication. I got to figure out how to use this tool to do this thing. And you're like, yes, you need to keep mastering your basics, but while you're doing that, I need you to come talk to me about...And I think it's interesting that the higher up in the seniority you go, the larger the problems you take down, and then, all of a sudden, the problems that you've experienced are at that level instead of one level down.
\n\nWILL: Well, I mean, I also say this. I think one of the real bear traps in the industry, another [inaudible 54:48] difficult problem in the industry is not knowledge transfer from juniors. Juniors are actually pretty comfortable, usually. Usually, they're very comfortable. The really tough ones are the seniors.
\n\nMIKE: [laughs]
\n\nWILL: That's leadership with a capital L because, like, you know what I mean? You're going to take Ls. Things are going to move. Things are going to change. The needs of the organization are going to change. The needs of the industry are going to change. Like, things are going to move, and there's a natural human reluctance to look foolish to, like, be a beginner again, and again, and again, and again, and again, and again, and again. Knowledge transfer among seniors, and keeping seniors current, and keeping seniors flexible and empathetic, and stuff like that, that's the real challenge.
\n\nDAVE: Convincing somebody that this style of code is more readable than this other style when they are utterly familiar with that other style, and they're like, "Well, clearly, it's readable." And I'm like, "Nobody else on the team agrees with you. It's familiar to you. It is unreadable to us. Would you consider doing it this way?"
\n\nAnd you get that spot where, as a junior, you're humble, and you're willing to change anything. And you get to intermediate, and you're like, "What I know works." And then, to get from there to senior, you have to go, "What I know works, and what you know will also work, and we're going to do it your way because we need to move."
\n\nMIKE: And that is hard. I read an article the other day by a scholar of the Hebrew scripture. The specific text isn't that important. The important thing is that it was written a long time ago. And what he said was that there's this recurring theme that you have a leader who starts out humble, and they apply that humility, and they become very prosperous, and they get set in their ways, and it causes all kinds of trouble [laughs]. And it's not a new problem. It's not a new...but we still have to fight it, you know [laughs]? And we have to be willing to do some introspection and say, "I'm that guy now. And I need to be willing to humiliate myself."
\n\nWILL: Well, I mean...so, go ahead.
\n\nDAVE: I'll just say the biggest compliment, I think, I have ever been given in the last year was also from Eddy, ironically. I like Eddy. He says nice things about me.
\n\nWILL: [laughs]
\n\nDAVE: But we were in a meeting, and I asked, like, a bone stupid...I mean, like, the kind of question that everyone in the room was like, you're asking that? I won't go into the question now because if I don't give you enough context, it's going to sound like an offensively stupid question.
\n\nWILL: [laughs]
\n\nDAVE: And it was, it was borderline offensively stupid. But as soon as I asked it, all the juniors went, "Yeah, I want to know the answer to that, too." And so, we realized we had zero knowledge share. Like, everyone on the team thought everyone else on the team knew the answer, so they didn't want to ask. And Eddy turns to me, and he says, "You are fearless about asking stupid questions."
\n\n[laughter]
\n\nAnd momentarily, I was kind of offended. And I'm like, no, he meant that as a compliment, and he's sincere, and he's right. I'm willing to ask really, really dumb questions. If I feel guilty, if I'm self-conscious, I will say, "I know the answer to this, but just so everyone else knows, you know, it's like, how is this working?" And you got to be willing to do it. I've had people get impatient with a stupid question, but I've never had somebody think I was stupid for asking a stupid question. I've never had somebody think I was a coward for asking a stupid question, to put it that way.
\n\nWILL: Do you guys want a life hack for embracing your inner idiot?
\n\nDAVE: Oh yeah.
\n\nMIKE: Yeah.
\n\nWILL: All right, so this is what I do. This is, like, actionable stuff. This is the Slack life hack. I won't discuss ticket work in a DM, and I won't tolerate other people discussing ticket work in DM. If you got a question about how to do your job, it goes in a channel. Maybe the team channel. It doesn't have to be in a public channel. You don't have to put it on general, or whatever, but everything.
\n\nIf it's like, "How does this work? Hey, do you remember how to do this API?" Anything. Anything at all. I mean, if you want to have a private conversation with me, it's totally fine. Let's talk about our weekend. Let's talk about the dumb thing that thus and such said in thus and such meeting. Like, "I can't believe David had to ask that, Jesus, that guy [laughs]." But, like, none. Ever. None. Zero. No chance.
\n\nDAVE: There's a countervailing force that you have to be very vigilant for, which is all it takes is one VP to say, "Just get it done," when somebody asks a question. Those questions will evaporate because, all of a sudden...we've talked about psychological safety before on the podcast, right? Where it's like, if you have someone out there...when somebody asks a question like that, the response from the people who know the answer should never be, "You should know this."
\n\nThe answer should be, "Yeah, you should know this. Let me tell you. Thank you for asking this because I should have told you this." And that is so, so helpful is to be welcoming of the dumb questions because if somebody's not willing to ask a dumb question, you got a lot of people walking around with a dumb question unasked, which means they don't have the obvious answer, which means they're dumb. It's...yeah.
\n\nWILL: And, I mean, the other thing that is like, you know, to be perfectly honest with you, I mean, there's always teams shifts and teams ebb and flow, and people come in. And conventional wisdom that everybody knew six months ago it's like, well, you got three new devs on the team. They don't know that. How could they? They weren't there.
\n\nAnd sometimes I just forget, okay? Like, I'm lazy, okay? I am. I'm as lazy as I can get away with being. And also, also, also, it becomes, like, an unofficial Wiki. I'll search a Slack, you know what I mean? I'll search a Slack Channel. Oh, weren't we talking about that thing the other day? And then, I'll find it, and I'll probably post it again. I'll probably repost that link because that's just how it goes.
\n\nI mean, in terms of VPs just being like, "Just get it done," you want to be out of this thread because you got other stuff? The response to that is, "No problem, Jim Bob. We're going to work it out." I'm going to start another thread, and Dave and Mike, and I are going to figure out exactly how this thing gets done, right?
\n\nIf VP is saying, "I'm delegating this," that's fine. The only thing I want to hear is, "We got you." And then, the team figures out how to do it, and, like, they don't pinged every 30 seconds as we're hashing it out. That's fine. If he wants to go cook, let him cook. It's fine. This is my job. I got it.
\n\nMIKE: I think that's a pretty good stopping spot.
\n\nDAVE: It is. This was awesome [laughter]. You know it's a good podcast when you want to do two more hours on the tangents that you've dug up part way along the thing, yeah.
\n\nWILL: Well, happy Friday, gentlemen.
\n\nDAVE: All right.
\n\nWILL: You all be well.
\n\nDAVE: Have a good one. Cheers.
\n\nMIKE: Thank you. Until next time on the Acima Development Podcast.
","summary":"","date_published":"2024-08-21T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/cb1c6dd8-7b12-4d77-9a26-9f27c69484d1.mp3","mime_type":"audio/mpeg","size_in_bytes":37500010,"duration_in_seconds":3764}]},{"id":"cd80c813-86b0-4c92-bbb6-41972cc98925","title":"Episode 52: Scary Code","url":"https://acima-development.fireside.fm/52","content_text":"In this episode of the Acima Development Podcast, the panelists join forces and discuss the things that scare them in code and how to avoid these pitfalls. Mike begins by recounting his experience with a fast-growing startup that used a poorly managed customer management system. This system lacked version control, searchability, and a test environment, which forced developers to tweak code in production. Additionally, Mike shares another experience with a codebase riddled with security vulnerabilities, illustrating the dangers of inheriting poorly written third-party code.\n\nWill adds to the discussion by highlighting the broader organizational issues that can lead to scary situations in coding. He emphasizes the importance of maintaining a strong chain of trust within a distributed workforce and ensuring diligent code reviews. Will warns that when organizational control breaks down, it becomes a significant concern, especially with large volumes of foreign code entering the system. He argues that fostering a sense of ownership and responsibility among team members is crucial for maintaining code quality and preventing issues.\n\nThe conversation then shifts to strategies for cultivating ownership and responsibility in coding teams. Mike and Will discuss the importance of giving developers genuine control over their work to foster investment and care. They touch on the challenges of balancing team freedom with organizational needs, noting that allowing developers to make decisions, even if it means making mistakes, can lead to better long-term outcomes. Eddy also emphasizes the value of training and mentoring junior developers to ensure consistent code quality and adherence to best practices.\n\nTranscript:\n\n MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I am hosting again today. With me today, I have Eddy and Will. There's a chance we may have some additional folks coming and going. We're kind of in an influx today [laughs], but we're going to start here. I am excited about what we're talking about today because I think it'll be fun.\n\nAnd I'll just lead with the topic. We're going to talk about things that scare us in code. And how do we avoid having some of those things happen? Because I'm hosting, I get to start with some stories [laughs], and I'm going to start with stories that are long enough ago that the victims are not obvious [laughs]. And the companies are likely, well, more than likely; the companies are out of business, so we don't have to [laughs] be too sensitive about it. \n\nThere's one example I think illustrates kind of everything, maybe not everything, but many of the things that scared me about code. I worked at this place early in my career, a fast-growing startup, really fast-growing startup. They were growing like crazy, and they needed to have a customer management system to manage all of the new customers they had. And somebody knew a guy who [laughs] had built something, and they paid for it, and we got it. \n\nAnd this system consisted of a Microsoft SQL Server having a whole bunch of custom extensions added to it and a whole bunch of queries so that the entire system ran inside of the Microsoft SQL Server. And some of the components they called out to were compiled code for which we didn't have the source code. And the areas for which we did have the source code, that source code was just stored procedures inside the database, and that's where most of the code was. \n\nSome things about that. There was absolutely no version control [laughs], which means any code there is, the only chance you have to do anything about it is to tweak it in production because there was no test system. There's only the production system, and there's no code repository. There is only the production system. If you want to change something, you go change that stored procedure live and hope for the best. And [laughs] further, because it's just stored in the database, all you have is those stored procedures, and you want to find anything, there's no search system. You just have to try to figure it out. And they referenced each other all over the place. So [laughs], you had to go find them.\n\nAnd sometimes you drilled all the way down, and you found a compiled component for which we didn't have a source code, and you just hoped it did the right thing [laughs]. Maybe it was sending out emails. Who knows what it was doing? You didn't have access to it anyway. And we used that thing for years. Oh, that was an interesting piece of software. I ended up making a number of changes in there that we needed. But I could go on. I'll mention some of those key characteristics again. No version control. No searchability. No test system. You can only test it in production. And it came from a third party. It came from a third party. The development team didn't have any choice over it. \n\nAt that same company, we inherited a codebase. Our company decided to bring it on to try to bring in some customers. And I didn't know about this codebase ahead of time, and none of us did. But apparently, they had some security holes before we acquired it that were actively being exploited. At least there was something like version control in this system. However, this was their SQL injection. They were handcrafting all of their queries. In this case, they hadn't sanitized their SQL. And this was in processing financial data. And they'd already lost, I think, over a million dollars before we found the hole. You imagine that didn't go over very well [laughs], especially this small startup. And probably led to the demise of the company shortly thereafter. \n\nSome things in common between those. Notice the third party. Developers having no access until afterwards, so inheriting a codebase. And a lot of times, you don't acquire code from a third party, but it's handed off, and you don't have the insight, and lack of adherence to anything like best practices and difficulty in searchability. There's a couple of worse stories [laughs], but they also illustrate a lot of the things that I think are worst in code, scariest in the code, which are stuff that I don't understand, and I have to go dig in because I'm inheriting it, and I have to go figure it out. \n\nPoor adherence to good practices [laughs]. Lack of searchability. Lack of test environment. Man, all of those are horrible. And both of those projects kind of checked all of the boxes. And I could go on, but I'm going to give you all a chance. Will, you've been around in this industry for a while. You've probably got your own stories. What have you seen that scares you in the code, and what have you learned from it? \n\nWILL: If I'm talking about things that scare me, it really honestly goes [inaudible 05:11] time. I can remember the time where I deleted the prod database or the various things I screwed up. But really, they all had this one centralized theme, I think, which is when sort of organizational control kind of breaks down. That's really the thing that concerns me the most with sort of bigger organizations, like if you're an organization where they're really pushing sort of a distributed outsourced workforce, right? Like, I might be experiencing some of that right now. And there is...a lot of people have, like [inaudible], is minding the store. \n\nCode reviews are really, really difficult. And it is still very difficult to find people who are diligent in their code reviews and making sure that people are really looking after stuff. And that's when things start to go bad, especially when you get this sort of injections of a large volume of foreign code into your organization, your distributed system. So, that's really what keeps me up at night, where it's like, people are checking things into production. People are checking things into the app all the time. Who is minding the store? \n\nAnd it becomes, you know, past a certain point, you're doing a trust fall by necessity. You physically cannot manage all of the code. You can't do it. It cannot be done by any single person. And so, you're just sort of...you trust the people and that sort of chain of trust is a very fragile thing and shockingly easy to break down.\n\nMIKE: Yeah, I think my experience is totally -- \n\nWILL: It's just sort of like this organizational chain of trust. \n\nMIKE: Yeah, I was just saying my experience is totally consistent with yours. And [laughs] the way you say that organization breaking down, and it doesn't have to be inheriting a bunch of that outside code, like you say. You can have just something as simple as a change in organizational structure so that you don't have the same team cohesion that you had previously. And say the people watching the store were out taking care of something else; stuff starts to fall apart. \n\nWILL: Let's talk about this. Let's talk about maintaining that chain of trust and how do you do it. Because I'd say the best model maybe that I've seen that is scalable, not without faults but scalable and practical is, you know, each sort of section of the code, you know, major subsystems are owned by a team. And they have a watchdog who is responsible and proactive enough to keep this subsystem under their thumb. And I don't know if I have a better working model, really. \n\nMIKE: Well, that watchdog you talk about, I feel like if somebody feels like they own it, that is [laughs] not told that they own it, but genuinely has some opportunity to get invested in something, it makes a huge difference. I know when I build something, I care about it, even if it's something, you know, that's not that important. If you make a pile of rocks, you can get a little fond of that pile of rocks because [laughs] I built that. That act of creation binds you to it. \n\nI think that some of that applies in our jobs as well; if we feel we had say in what we're building, feel because we actually did. I'm trying to make the distinction here. Because you can have kind of faux control where somebody says, \"Yeah, you own this. You're on call tonight.\" But you don't get to make any of the decisions. Well, you don't really have control. You have responsibility without control in that case. \n\nAnd that's where I think is kind of an anti-pattern because if you have the responsibility without any control, it just burns you out because you're disempowered. On the flip side, if somebody gets to actually make decisions, creative decisions of what they're doing because, you know, they own it, they get to make those decisions, then they become much more invested. You know, it sounds like I'm talking about a trick like, here's how you get your team invested. Rather, I'm saying you've got to surrender some control. \n\nYou've got to, as leadership, be willing to say, \"I don't get to call all the shots here because I'm not close enough to be able to make the good decisions.\" And if you're making those decisions, you may make the wrong ones. And there's always cases like this where there's more art than science, where it could go either way. If you don't have enough trust in your team to make their own decision, then you're seizing that ownership for yourself for no gain. It's just hogging the ball, right [laughs], and not letting anybody else play. And that, I think, really poisons things. I think that in order to get the ownership that Will was talking about, to have somebody really claim the code and be willing to care enough about it, they have to actually have it genuinely be theirs. \n\nEDDY: There's a few key things that both of you said that I kind of want to elaborate a little bit on. And losing control of the codebase is a little interesting because if the staff is trained right with the expected conventions and what we have planted for team rules and such, that can be mitigated. But also, there was a joke that was said [chuckles] a few weeks ago. I'm not going to name-drop the person just because he's not here. \n\nBut it basically said, I'm paraphrasing, but it basically said, as a senior developer, if you take a junior developer under your wing and cultivate their decision making, you can then, at that point, have a proxy battle from them in your behalf in order to enforce some of those decisions that you want. It's kind of funny. But the more that I've adapted to that ideology, I've found myself also enforcing some of the ideologies from my peers, which is another benefit, I guess, to that fear.\n\nMIKE: You know, a few hundred years ago, for any skilled trade, maybe not any, but a large number of skilled trades, people learned the trade by apprenticing with a master in the field. And, to your point, one of the best ways to learn something is to watch somebody else do it and you apprentice with somebody. Well, and you can see this in the works of, say, artists, where artists who apprenticed with the master end up having work that looks very similar. Of course, they diverge in their own way, but the apprentice does tend to follow the master. And I don't think that we should shy away from that. \n\nCertainly, people are going to diverge and go their own direction. But there's real value in not having to make some of the hard decisions yourself when you're getting started. And you're going to rely on the expertise of the master while you're still learning. That's what kids do with parents. And, of course, parents sometimes get it wrong. And a lot of times, you know, the basics of adulting [laughs], you're going to pick up by watching. And they're probably going to have at least somewhat right, and you're going to pick up on that and learn the things to do. That's how we learn as humans. We learn from more experienced members of the tribe and don't have to make the decisions: hey, should I eat this berry? Is this going to kill me? And look [laughs] to somebody else who might know that answer already. \n\nAnd so, you know, I think that it's worth leaning in, leaning in there. And if you are a leader, it's okay to tell people, \"Hey, that berry, I saw that make somebody really sick the other day,\" or maybe \"20 years ago. I've been doing it for a while. And I don't want that to happen to you all, so don't eat those berries. There's a reason we don't eat those berries.\" Maybe there's a reason we don't test in production. And follow the best practices of setting up a test environment, setting up a staging environment that you can test in so that you can test things. And put a lot of investment into that so that you can do solid testing before you get to production. You're not going to get poisoned that way, in the way that you would if you go straight out... \n\nEDDY: I want to say that it's kind of funny because you say if you've lived that pain, you're saying, \"Don't eat it. It's bad for you.\" But sometimes, your body acclimates to that substance that you're eating, right? And then, you just don't notice that it just tastes awful. And that's kind of just what happens in code. It's like, you might be doing a bad practice, but you're just so used to doing it. Your body just got so used to doing that that you just don't realize, you know, that it's bad [laughs] until you have someone else who's trying it for the first time, and they're like, \"Oh, dude, this is pretty gross, dude.\" \n\nMIKE: [laughs] Yeah, it's true. \n\nWILL: There's a lot of things that were, you know, they were good until they were bad, or even worse, more commonly, they were relatively benign diseases. They weren't going to kill you until you got to a particular stage. I've done all kinds of things in a small team, small, high velocity, tightly integrated team, but we're fine. They were all fine. But on a more, call it, enterprise scale, you know, organization, they would kill you dead as fried chicken. So, it's not a cut-and-dry thing. The argument would be that for those small, high-velocity teams, if you're not moving fast, if you're not cutting corners, you're not going to make it to enterprise scale where you can go so slow. \n\nMIKE: That's a really interesting point. You can get away with a lot of stuff when it's just yourself. You can get away with a lot of stuff. \n\nWILL: And you have to. Let's talk about the things that are going to kill you when it's just you out there on a wing and a prayer. Like, you need to ship, and you need to ship today. And like, oh, you don't know how to do that? Well then, you're just going to do the best you can. Overwhelmingly, the thing that is going to kill you is running out of time or money, right? Like, 10 [inaudible], if not higher. And so, it's like, oh, security is not so tight here, and I'm like, no, it's not [laughs], you know? It's not. \n\nEDDY: There's an estimation of good time for half a day. So, you need prep time to get there. But sometimes the party is in the next hour, right?\n\nMIKE: [laughs].\n\nEDDY: So, you're like, well, dang [laughs]. Well, I guess I'll just put in an extra cook to turn on the heat a little bit, you know, get it done in an hour, and hope that it tastes the same. \n\nWILL: Exactly. I mean, being worth robbing, you know, by cybercriminals, being considered worthy of being a ransomware target is, you know, that's first world problems, baby. You made it [laughs]. It's like getting sued by a patent control. Like, hey, there you go, like a disturbing truism that, like, a rite of passage to be like, oh, I've got an actual business now. I'm actually a businessman now, is getting sued for the first time. Your first legal letter where somebody tries to shake you down. It's like, oh, you made it, baby. There you go. Look at us now. \n\nMIKE: [laughs]\n\nWILL: I'm worth robbing. \n\nMIKE: So, we're digging into this idea that the consistency that is absolutely critical for managing a larger organization can be less so when you're working with a smaller organization because your circle of trust with a smaller organization is so easy to maintain. You all know where things are bad when you've got the small team. I'll say, \"Oh yeah, there's that bad thing. We all know it's terrible. Don't step there.\" \n\nBut as you grow, that shared knowledge becomes harder and harder to maintain, and it becomes more and more important to have standardized practices, standardized ways of sharing information, ways to replace people when they move on or, you know, otherwise removed from the organization. And that's a challenge as you grow, and it's going to chafe a little bit. And you're going to be like, \"Hey, I miss my freedom to do whatever I wanted.\" And to have the maturity [chuckles] to say, \"You know what? I need to change. I need to change what I'm doing, or else I'm going to cause harm because being a cowboy is not going to work anymore.\" \n\nEDDY: There was an off comment, you know, that was kind of relevant to what you're saying but I kind of want to expand on a little bit. It was, you can tell someone the direction and tell them, \"Hey, don't step there, right? There's a trap door. You're going to fall.\" But what do you do in the instance when you tell someone, \"Don't step there.\" And they respond with, \"Oh, it's okay. I can fly,\" right? Like, what do you do [chuckles] in that circumstance? You're like, \"No, dude, you can't fly. I've been there.\" And they're like, \"Oh, no, no, it's fine. I'll be fine.\" Like, what do you do? How do you keep quality when the individual believes that they're not affected? \n\nWILL: It depends on the blast radius of the problem. I am a believer in sort of you break it, you bought it. If somebody is willing to say like, \"I want to do this thing. This is my thing. I will take ownership of it,\" and the blast radii is small enough so that if it goes bad, then...you know what I mean? Like, it is a human-sized error with a human-sized sort of level of consequences, and somebody comes to me and says, like, \"No, I'm going to do it my way,\" I'm like, \"Okay, do it your way,\" you know? I believe in sort of agency like that. You have to be mindful because, a lot of times, things can be slow-growing systemic problems. Make a judgment call whether you can afford to let somebody go and try it their way. \n\nIn my estimation, the way I make those decisions is, is it a really big deal for you, and can you shoulder the consequences of it yourself? And so, if it's a manager, it's like, okay, the manager's team can shoulder it. If it's an individual developer, then the individual developer can shoulder the consequences thereof. I don't know. If I can say \"Yes,\" then I will, honestly, because that's how people learn. And if I can, I try to explain why. Or I'll come up with a sort of rubric to be like, \"Okay, try it your way, and these are the conditions under which I will say, you were right, and I was wrong. These are the conditions under which I will say, ah, you know, I mean, this is just tomato, tomahto. Both are, you know, more or less equivalent. And these are the conditions under which, like, can we all agree that I was right and just do it my way now, you know?\"\n\nEDDY: I agree. You're like, at what point does it start tasting bad? If you're saying add more sugar but without the added sugar it still tastes okay and you're okay with the taste, you're like, \"Yeah, yeah, it's fine. It still tastes all right.\" \n\nMIKE: [laughs] It goes back to --\n\nWILL: And I'll say there's a lot of stuff out there. The overwhelming majority of decisions fall into that, I would say, broadly, you know, that tomato, tomahto kind of a situation. It's very rare that you'll have a black-and-white this is wrong scenario. \n\nMIKE: I was going to say that goes back to the ownership discussion that we were having before. If you don't give the team...so this is opinion of me, but I think it's right [laughs]. If you don't give people ownership, then they won't have any reason to take responsibility, and you get ownership by making those choices. You're committed now. You've made the choice. You see how it works, and now you care how it turns out. And, yeah, maybe you've made the wrong choice, and you learn from it. Maybe you make the right choice, and now you've got something defensible, and you'll care about that the next time.\n\nGiving people that chance, you know, the tomato tomahto chance to do it their own way, it may sound superficially important, but I think that it's actually critical for giving your team the opportunity to actually make consistently good code. Because if you take away that control, well, then nobody cares. I don't want to say it's like slavery because you can leave the job [chuckles]. But if you don't have any agency in it, then you just don't care. \n\nEDDY: Well, and I think what's more important is if you have a new cook in the kitchen and you're constantly holding their hand, they're not really going to learn anything. However, if they end up burning the kitchen, they are going to remember. And they're going to be like, \"Dang, I had to clean all this up. And all this mess, I had to clean it up.\" But then, guess what? The odds of them burning the kitchen again for the same recipe probably isn't going to happen anymore. So, I think there is some benefit to putting trust in your cooks. \n\nMIKE: I was building on what you said before, where you have to have that watchdog that keeps going. And the way I say you develop that, I think you're right that you need to have somebody who cares enough to keep people in line. And I think you only get that, and this is why I've been talking about the ownership: if that watchdog actually feels like they own the code, feels like because they do. \n\nThey're only going to care enough to keep the code good if their actions matter, you know, if they actually get to make those choices, which means you got to let go of the hand and let them do it, which is going to be uncomfortable. But then they will own it, and they'll learn, and they'll become that fierce owner, you know, it's their thing, and care enough to keep the code solid. And I think that having a culture of giving people the chance to actually own the code is hand in hand with having quality code, that you can't take away control and expect the best practices to continue because it rubs against human nature. That was my high-level idea. \n\nWILL: Yeah, no, I totally get it. And so, the question that I have for you guys, this is kind of a broad thing, but, like, how do you cultivate that kind of [inaudible]? How do you value people who have been around long enough to take ownership? What are engineers like that worth to you? How do you build that stuff up? How do you keep...I would say, I love institutional knowledge. I love people with ownership. I love all that stuff. I am very fairly stridently against the idea of seniority as if, like, sort of years on the job is a suitable proxy for these desirable qualities. So, how do you make that happen? \n\nI won't bury the lead, but one of my great bugbears of the industry and one of the things that I...I really hate the fact that you've got to move around to move up, and I understand the countervailing forces there. But, like, if you didn't want to do that...because all these things that we're talking about, these watchdogs, this ownership of code, this isn't the kind of thing that you can have with people moving every two years. But if you're not moving every two years, there are consequences for your career, which can be fairly significant. How do you manage all that stuff? How do you create these cultures that we all agree we need but there are so many headwinds against? \n\nMIKE: Well, Netflix, if I remember right, so I'm going from memory here, but my understanding is that for years, they had a policy that if you got a job offer somewhere else, they would match it. No questions asked. They cared enough about that continuity. They put their money where their mouth was. And so, they had some of the best-paid engineers in the industry by some margin, sometimes, like, you know, 30%, 50%, 100% more than some of their peers. \n\nBut I tell you, you do that, and you get a committed team who cares enough to stay around. I think they did the things because the company cared enough to actually do what they said and value their team members. The result was they got a team that made them extremely successful. So, I think that there are examples in the industry of people doing right. But there's a lot of examples of being short-sighted because there's a lot of incentives to be short-sighted, to say, \"Well, we need to save money. We need to make the stock price go up., And we're going to get that by reducing costs,\" which is a reasonable thing to say. But then what happens next is dicey, right [laughs]? \n\nYou say, \"Well, what you do next shows what you value. And if what you do next is continue to value your team and pay them appropriately, well, that shows what you value.\" If what you do next is say, \"Well, let's get rid of all of our senior experts because they cost a lot, and let's hire a bunch of new folks without any context and, you know, it'll work, right?\" Well [chuckles], you've shown your values. And there's a hazard, I think, to leadership to make decisions that will probably turn out well in the short term but will lead to a steady decline over the long term. \n\nEDDY: It's like what do you do when the only two people in Coca-Cola suddenly die and they're the only ones that know how to make your recipe, right? You can get pretty close to the genuine taste, but you just know that it's going to be a different taste, and it's not going to be the same. \n\nWILL: Well, like, the great [inaudible] are full of indispensable [inaudible 27:49], right? And I think there's a counterargument to be made that your initial team is the people you could get. But as things go on, as the company gains legitimacy and financial power to compensate and hire and retain good developers, that original team maybe, like [laughs], uncomfortably accurate definition of a technical co-founder, is the best developer you can get to work for free. \n\nMIKE: [laughs]\n\nWILL: So, you could start bringing in more heavy hitters as time goes on. And a lot of the decisions, engineering decisions that were, I think, defensible, if not absolutely correct at the time, are no longer so. There's a flip side to that as well. Everything is a golden [inaudible] [laughs], right? You're always trying to find a balance. \n\nMIKE: Sure. What you probably don't want to do, though, is hire these great, new folks, keep them around for six months, and then send them out the back door. And maybe you're deluding some of the people there originally, or maybe you do ask them to leave. But you're still looking for continuity with people who know what they're doing. There's still the respect for expertise and, again, not seniority per se but expertise. \n\nWILL: Well, yeah, and then it becomes a sort of a leadership challenge in that you need to sort of walk people down where they were, at one point, a law unto themselves, and now, you know, maybe they have a manager. And I think, arguably, the current stock option regime mirrors that, I think, pretty well in that, you'll have your founding teams, and they'll get a big slug of equity. Like, your initial hires they'll get a big slug of equity, and that equity will appreciate and appreciate and appreciate. \n\nAnd people will come in. You'll get your series A round. And you'll start to bring in some real hitters, and they'll get more compensation. But the people who came there blocked the stock, and it's worth a lot more now. And so, they have, you could argue, golden handcuffs on one hand. But you could argue they're paying for institutional knowledge and continuity, even though they might not be continuous in the same role. Everybody sort of gets a...it's a fair shake there. \n\nMIKE: It's interesting that we started by saying, \"What scares us in the code?\" And we're talking about stock options [chuckles]. And I don't think that's off. It seems like a tangent, but I think it's inseparable in that we're talking about the practices that lead to ownership and people caring enough to make the code solid.\n\nWILL: Well, exactly. Well, we talked about the code for 5 or 10 minutes, and then we immediately jumped to the real problem, which is sort of maintaining the team, maintaining that culture of engineering excellence, maintaining a sense of ownership and responsibility as things scale, as things get bigger, as the problems get more complicated. I mean, that's it. That's the issue. There's no two issues around it. As long as everybody is coordinated, and focused, and disciplined, you can sleep pretty soundly. I mean, every once in a while, something's going to go bad. But, man, dude, nothing makes me happier than a problem that got successfully opened, closed, and resolved, and I didn't have to lift a finger. I'm just like, ooh, ooh.\n\nMIKE: [laughs]\n\nWILL: Oh yeah, oh yeah. What's up? Oh, that was Saturday. \n\nEDDY: For those who are fans of --\n\nWILL: You guys had a rough Saturday, boys. \n\nMIKE: [laughs]\n\nEDDY: For those who are fans of Emperor's New Groove, there's a meme where he goes like this, and it's like an okay because it's just so perfect. And that's what you made me think of when someone reports a problem, and it just goes fluid, and it just goes perfect. Awesome moments that you sleep like a baby. \n\nI do want to say that there's a couple of situations or circumstances that sort of keep me up at night, and one of those are having a tower, where the foundation of that tower on the right side is held by a twig. It's so freaking scary because that's legacy code. And touching something where you just don't know where it is, you can make the change that's super scary. And I feel like a lot of us sort of try to avoid that and find another alternative because it's like your whole app is rooted off of it [laughs]. So, that's one of the things that keeps me up at night. \n\nMIKE: That goes back to the continuity we've been talking about. Hopefully, you can keep the continuity so that you have somebody who knows how to work with that twig and can share it, sometimes, though, you don't. And in an older codebase, you probably don't have people, and if they do, they're probably spread thin and don't have much time to talk to you about it. And that's a difficult problem that –-\n\nWILL: I don't know, I'll say that just, for me, I don't spend a lot of time thinking about pieces of the codebase that have been running without complaint for many years. Those are not high on my [inaudible]. Nothing like battle-tested code. Although, gentlemen, if you can't hear, I am being paged. I think it's time. I think it's my time. I will talk to you guys. See you guys. \n\nMIKE: As Will was saying, if it's working, you don't have to worry about it. Sometimes, though, it stops working [laughs] or needs to be changed. And then, you got to have somebody who can go in there and fix it. I can bring up one example. She's not here, so I'm not going to name. But I worked with a really good engineer who was obsessive about detail, and she'd see something, and she just couldn't help figuring out why it worked and how it worked. \n\nAnd it meant that it took her a long time to get things done initially because she would understand what was going on before she pushed up the code. But it also meant that once she'd worked in the area, she understood it, and she could get that job done. And anybody else who needed to work in that code would go to her because [laughs] they knew that she could help them understand what was going on. \n\nHaving somebody who can have that level of focus where they will take the time to actually figure something out is so valuable because it solves your twig problem, Eddy [chuckles], because they'll take the time to figure out exactly how it's working. And there's a hazard there because you might think, well, their output is not as high. They're not cranking out a bunch of code because they're going to take longer to get things done generally because they're not going to push out their changes until they're sure they work. But they provide immense value to the team [chuckles] because having somebody who actually gets it is just so valuable. \n\nEDDY: I agree. I agree. Now, there is another thing that keeps me up at night. And this is when you have a long chain, and they're all connected to one another. And in this chain, it calls another chain, which calls another chain, which calls another chain, which calls another chain. And, suddenly, you have 17 chains that are hooked up, right?\n\nMIKE: Link after link [chuckles]. \n\nEDDY: Oh, that was so bad because then what you have to do is...and they tell you, \"Oh, modify this chain.\" And you're like, ah, see, I don't know. I don't want to modify the middle. That's too scary. I don't want everything to just split open. So, what I find some people do it's like, oh yeah, we'll modify the tip. We'll modify the end. We'll modify the other end. And that's why you get a long series of chains, and that really keeps me up at night any time I have to touch any of that code. \n\nMIKE: Well, and if you're doing that also without doing any refactoring, you probably end up with 20 parameters to the end of the chain, where the chain began to try to promote reusability. And then, oh yeah, well, there's this component that could be reused. But if you haven't figured out what's going on in that chain, the reason why you have it, then you're not going to reuse one of the components and kind of branch the tree where you need to. You're just going to tap in at the end and add another parameter to make it do what you wanted, rather than going deeper into the chain. The part that does do what you want, you could have [inaudible] in there. \n\nEDDY: Yep. Which is why I sort of adopted the ideology of singleton classes. I really do enjoy them a lot. They're much easier to work with. \n\nMIKE: Singleton can have a few different meanings. Could you clarify exactly what those parameters are that you're --? \n\nEDDY: Sure. So, for me, a singleton class is just a single hand of responsibility for that class, and that's all it does. [crosstalk 37:45], right? Like, don't branch off of that. It's possible that you can go beyond that if you want to, but don't violate that. It's part of...there was a book that we read on Ruby, which was...I don't recall the exact name of it off the top of my head. You might remember it, Mike. But the whole –-\n\nMIKE: On \"Design Patterns\"?\n\nEDDY: The \"Design Patterns,\" yeah. So, part of the idea of the design pattern from that book was don't go beyond of what the class is intended to do because you risk maintainability and reliability from that class. So, if you say, oh, this class' whole purpose is to structure a hash, and that's all it does, and you're like, oh man, but it would be really nice if it would also do this, and you're like, yeah, see, it works. And you can do that, but don't do it, right? \n\nMIKE: Single responsibility, single responsibility. So, I wasn't sure where exactly you were going because sometimes singleton can mean that you've got something that's self-contained, so it's both...there's only one instance of it in all of your running application because the class will only create one instance of itself. And so, you have that single shared instance across the application, so you avoid issues with duplicates of it. \n\nAnd so, if you're managing a connection pool, for example, you don't want to have two managers of the connection pool. You want to have one, so you don't...only one person in charge. But what you're saying is something a little different, which is single responsibility principle, your unit of code. And if you're functional programming, you don't have classes, but you should have your function. It should do one thing. It should do that thing well, and it should do nothing else. And if you've got something else to be done, well, some other unit of code should do that. \n\nEDDY: Agreed. Now, you run into issues where you implement modules or concerns that essentially do the same thing, but they deviate slightly. And that's also a problem that's really hard to address. \n\nMIKE: Are you talking about people writing code that's almost the same but not quite? \n\nEDDY: Yes.\n\nMIKE: [laughs] Yeah. And so, they end up diverging. \n\nEDDY: And, suddenly, instead of maintaining just one, you're maintaining two. You're maintaining three [laughs]. \n\nMIKE: Well, that gets to the don't repeat yourself. Don't repeat yourself is actually kind of subtle because there's times when you absolutely should repeat yourself. And here's where I take that. In cases where the repetition is trivial and makes things easier to understand, then you should repeat yourself such as in a display component. To take something to its logical extreme, let's say you said, \"Well, all markup uses tags, so I want to make sure that every single tag is written by shared code.\" And so, you have to go through this shared code to render a tag. \n\nAnd maybe you have some sophisticated component. Maybe you're writing a front-end component where that actually does make sense. But if you're just writing out some markup, then that's probably a really bad idea because you're going to have all kinds of complexity, or you could have just thrown some text out there, and it becomes far harder to manage. \n\nLikewise, unit tests. People sometimes think, man, I'm going to make sure that I have no duplication. So, they take anything that might possibly be shared and put it into a shared example that's in some other file that you have to go digging [laughs] to find. It makes it so hard to see what it is that you're testing, where if [inaudible] the details and repeated them, then it would be a lot more comprehensible. So, I'd say don't be so DRY that it chafes [laughs]. \n\nEDDY: I've received code where I've reviewed where they've obscured all the dependencies to top level in the specs, and they just call one subject, right? Boom. And then, like, that's the whole context for that test. And I'm like, no, what? What's going on here? And so, I have to go and I have to dig to figure out what's all the dependencies for that. And I'm like, sometimes I wish, man, can we make this a little bit more DRY? Just a little bit more so that we have...because tests, in general, should document themselves, right? \n\nMIKE: Yes.\n\nEDDY: And if you're obscuring that for your reader, then you lose context and it's really easy to keep all that in your head. So, I have tried to push a bunch of new tests that I've written, right? And I've applied a bit of dryness to it. \n\nMIKE: Well, less DRY [inaudible], like, in this case, less DRY. You are going to repeat yourself. It's important for legibility. But then, on the flip side, you say modules will do the same thing. That's where it actually matters a lot to not repeat yourself because you are going to have to maintain two things, or then three things, or then four things that are slightly different that basically do all the same thing. And now you've got to maintain all of them. And, in that case, for important business logic, yeah, put it in one place and one place only. For unimportant display issues, repeat yourself at will. \n\nEDDY: I have pretty much bent the knee, and I've said, all right, I'll settle with damp [laughter]. \n\nMIKE: You like your code moist. \n\nEDDY: Yeah, it's a little moist, you know, best of both worlds. It's fine. You know, not too extreme one way or the other. But you have ideas from both is really where...because you have to be able to differentiate between syntactical opinions, right? That doesn't really, like, it has the same functionality, you know, same everything. But the holdup really just becomes from that individual's opinion on how the code should read versus how it functions, right? So, at that point, you really just...you have to give in. And you're like, eh, it was just syntax, not a big deal. \n\nMIKE: Let people make their own decisions a little bit [laughs]. \n\nEDDY: Agreed. And it came back. \n\nMIKE: It did come back. That's maybe a good stopping point, actually. \n\nEDDY: Agreed.\n\nMIKE: So, we looked around a lot and didn't talk a lot about specifics in the code but a whole lot about practices that tend to drive good code. And so, we sleep well at night when we give people the agency or ownership to make their own decisions. It sounds like it might make you sleep worse at night [laughs]. What's my teenager out there doing [laughter]? And if you've given that teenager the chance to make good choices since they were three, then maybe you are sleeping at night because you trust them to make the choices you've already seen them making. \n\nEDDY: I'm not a father personally, but I do attribute my tests to do the parenting for me [laughter]. So, I sleep better at night knowing, you know, that my tests are holding me accountable. \n\nMIKE: That's great. Well, thank you, Eddy, and thank you [inaudible]. It's been great and until next time on the Acima Development Podcast.","content_html":"In this episode of the Acima Development Podcast, the panelists join forces and discuss the things that scare them in code and how to avoid these pitfalls. Mike begins by recounting his experience with a fast-growing startup that used a poorly managed customer management system. This system lacked version control, searchability, and a test environment, which forced developers to tweak code in production. Additionally, Mike shares another experience with a codebase riddled with security vulnerabilities, illustrating the dangers of inheriting poorly written third-party code.
\n\nWill adds to the discussion by highlighting the broader organizational issues that can lead to scary situations in coding. He emphasizes the importance of maintaining a strong chain of trust within a distributed workforce and ensuring diligent code reviews. Will warns that when organizational control breaks down, it becomes a significant concern, especially with large volumes of foreign code entering the system. He argues that fostering a sense of ownership and responsibility among team members is crucial for maintaining code quality and preventing issues.
\n\nThe conversation then shifts to strategies for cultivating ownership and responsibility in coding teams. Mike and Will discuss the importance of giving developers genuine control over their work to foster investment and care. They touch on the challenges of balancing team freedom with organizational needs, noting that allowing developers to make decisions, even if it means making mistakes, can lead to better long-term outcomes. Eddy also emphasizes the value of training and mentoring junior developers to ensure consistent code quality and adherence to best practices.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I am hosting again today. With me today, I have Eddy and Will. There's a chance we may have some additional folks coming and going. We're kind of in an influx today [laughs], but we're going to start here. I am excited about what we're talking about today because I think it'll be fun.
\n\nAnd I'll just lead with the topic. We're going to talk about things that scare us in code. And how do we avoid having some of those things happen? Because I'm hosting, I get to start with some stories [laughs], and I'm going to start with stories that are long enough ago that the victims are not obvious [laughs]. And the companies are likely, well, more than likely; the companies are out of business, so we don't have to [laughs] be too sensitive about it.
\n\nThere's one example I think illustrates kind of everything, maybe not everything, but many of the things that scared me about code. I worked at this place early in my career, a fast-growing startup, really fast-growing startup. They were growing like crazy, and they needed to have a customer management system to manage all of the new customers they had. And somebody knew a guy who [laughs] had built something, and they paid for it, and we got it.
\n\nAnd this system consisted of a Microsoft SQL Server having a whole bunch of custom extensions added to it and a whole bunch of queries so that the entire system ran inside of the Microsoft SQL Server. And some of the components they called out to were compiled code for which we didn't have the source code. And the areas for which we did have the source code, that source code was just stored procedures inside the database, and that's where most of the code was.
\n\nSome things about that. There was absolutely no version control [laughs], which means any code there is, the only chance you have to do anything about it is to tweak it in production because there was no test system. There's only the production system, and there's no code repository. There is only the production system. If you want to change something, you go change that stored procedure live and hope for the best. And [laughs] further, because it's just stored in the database, all you have is those stored procedures, and you want to find anything, there's no search system. You just have to try to figure it out. And they referenced each other all over the place. So [laughs], you had to go find them.
\n\nAnd sometimes you drilled all the way down, and you found a compiled component for which we didn't have a source code, and you just hoped it did the right thing [laughs]. Maybe it was sending out emails. Who knows what it was doing? You didn't have access to it anyway. And we used that thing for years. Oh, that was an interesting piece of software. I ended up making a number of changes in there that we needed. But I could go on. I'll mention some of those key characteristics again. No version control. No searchability. No test system. You can only test it in production. And it came from a third party. It came from a third party. The development team didn't have any choice over it.
\n\nAt that same company, we inherited a codebase. Our company decided to bring it on to try to bring in some customers. And I didn't know about this codebase ahead of time, and none of us did. But apparently, they had some security holes before we acquired it that were actively being exploited. At least there was something like version control in this system. However, this was their SQL injection. They were handcrafting all of their queries. In this case, they hadn't sanitized their SQL. And this was in processing financial data. And they'd already lost, I think, over a million dollars before we found the hole. You imagine that didn't go over very well [laughs], especially this small startup. And probably led to the demise of the company shortly thereafter.
\n\nSome things in common between those. Notice the third party. Developers having no access until afterwards, so inheriting a codebase. And a lot of times, you don't acquire code from a third party, but it's handed off, and you don't have the insight, and lack of adherence to anything like best practices and difficulty in searchability. There's a couple of worse stories [laughs], but they also illustrate a lot of the things that I think are worst in code, scariest in the code, which are stuff that I don't understand, and I have to go dig in because I'm inheriting it, and I have to go figure it out.
\n\nPoor adherence to good practices [laughs]. Lack of searchability. Lack of test environment. Man, all of those are horrible. And both of those projects kind of checked all of the boxes. And I could go on, but I'm going to give you all a chance. Will, you've been around in this industry for a while. You've probably got your own stories. What have you seen that scares you in the code, and what have you learned from it?
\n\nWILL: If I'm talking about things that scare me, it really honestly goes [inaudible 05:11] time. I can remember the time where I deleted the prod database or the various things I screwed up. But really, they all had this one centralized theme, I think, which is when sort of organizational control kind of breaks down. That's really the thing that concerns me the most with sort of bigger organizations, like if you're an organization where they're really pushing sort of a distributed outsourced workforce, right? Like, I might be experiencing some of that right now. And there is...a lot of people have, like [inaudible], is minding the store.
\n\nCode reviews are really, really difficult. And it is still very difficult to find people who are diligent in their code reviews and making sure that people are really looking after stuff. And that's when things start to go bad, especially when you get this sort of injections of a large volume of foreign code into your organization, your distributed system. So, that's really what keeps me up at night, where it's like, people are checking things into production. People are checking things into the app all the time. Who is minding the store?
\n\nAnd it becomes, you know, past a certain point, you're doing a trust fall by necessity. You physically cannot manage all of the code. You can't do it. It cannot be done by any single person. And so, you're just sort of...you trust the people and that sort of chain of trust is a very fragile thing and shockingly easy to break down.
\n\nMIKE: Yeah, I think my experience is totally --
\n\nWILL: It's just sort of like this organizational chain of trust.
\n\nMIKE: Yeah, I was just saying my experience is totally consistent with yours. And [laughs] the way you say that organization breaking down, and it doesn't have to be inheriting a bunch of that outside code, like you say. You can have just something as simple as a change in organizational structure so that you don't have the same team cohesion that you had previously. And say the people watching the store were out taking care of something else; stuff starts to fall apart.
\n\nWILL: Let's talk about this. Let's talk about maintaining that chain of trust and how do you do it. Because I'd say the best model maybe that I've seen that is scalable, not without faults but scalable and practical is, you know, each sort of section of the code, you know, major subsystems are owned by a team. And they have a watchdog who is responsible and proactive enough to keep this subsystem under their thumb. And I don't know if I have a better working model, really.
\n\nMIKE: Well, that watchdog you talk about, I feel like if somebody feels like they own it, that is [laughs] not told that they own it, but genuinely has some opportunity to get invested in something, it makes a huge difference. I know when I build something, I care about it, even if it's something, you know, that's not that important. If you make a pile of rocks, you can get a little fond of that pile of rocks because [laughs] I built that. That act of creation binds you to it.
\n\nI think that some of that applies in our jobs as well; if we feel we had say in what we're building, feel because we actually did. I'm trying to make the distinction here. Because you can have kind of faux control where somebody says, "Yeah, you own this. You're on call tonight." But you don't get to make any of the decisions. Well, you don't really have control. You have responsibility without control in that case.
\n\nAnd that's where I think is kind of an anti-pattern because if you have the responsibility without any control, it just burns you out because you're disempowered. On the flip side, if somebody gets to actually make decisions, creative decisions of what they're doing because, you know, they own it, they get to make those decisions, then they become much more invested. You know, it sounds like I'm talking about a trick like, here's how you get your team invested. Rather, I'm saying you've got to surrender some control.
\n\nYou've got to, as leadership, be willing to say, "I don't get to call all the shots here because I'm not close enough to be able to make the good decisions." And if you're making those decisions, you may make the wrong ones. And there's always cases like this where there's more art than science, where it could go either way. If you don't have enough trust in your team to make their own decision, then you're seizing that ownership for yourself for no gain. It's just hogging the ball, right [laughs], and not letting anybody else play. And that, I think, really poisons things. I think that in order to get the ownership that Will was talking about, to have somebody really claim the code and be willing to care enough about it, they have to actually have it genuinely be theirs.
\n\nEDDY: There's a few key things that both of you said that I kind of want to elaborate a little bit on. And losing control of the codebase is a little interesting because if the staff is trained right with the expected conventions and what we have planted for team rules and such, that can be mitigated. But also, there was a joke that was said [chuckles] a few weeks ago. I'm not going to name-drop the person just because he's not here.
\n\nBut it basically said, I'm paraphrasing, but it basically said, as a senior developer, if you take a junior developer under your wing and cultivate their decision making, you can then, at that point, have a proxy battle from them in your behalf in order to enforce some of those decisions that you want. It's kind of funny. But the more that I've adapted to that ideology, I've found myself also enforcing some of the ideologies from my peers, which is another benefit, I guess, to that fear.
\n\nMIKE: You know, a few hundred years ago, for any skilled trade, maybe not any, but a large number of skilled trades, people learned the trade by apprenticing with a master in the field. And, to your point, one of the best ways to learn something is to watch somebody else do it and you apprentice with somebody. Well, and you can see this in the works of, say, artists, where artists who apprenticed with the master end up having work that looks very similar. Of course, they diverge in their own way, but the apprentice does tend to follow the master. And I don't think that we should shy away from that.
\n\nCertainly, people are going to diverge and go their own direction. But there's real value in not having to make some of the hard decisions yourself when you're getting started. And you're going to rely on the expertise of the master while you're still learning. That's what kids do with parents. And, of course, parents sometimes get it wrong. And a lot of times, you know, the basics of adulting [laughs], you're going to pick up by watching. And they're probably going to have at least somewhat right, and you're going to pick up on that and learn the things to do. That's how we learn as humans. We learn from more experienced members of the tribe and don't have to make the decisions: hey, should I eat this berry? Is this going to kill me? And look [laughs] to somebody else who might know that answer already.
\n\nAnd so, you know, I think that it's worth leaning in, leaning in there. And if you are a leader, it's okay to tell people, "Hey, that berry, I saw that make somebody really sick the other day," or maybe "20 years ago. I've been doing it for a while. And I don't want that to happen to you all, so don't eat those berries. There's a reason we don't eat those berries." Maybe there's a reason we don't test in production. And follow the best practices of setting up a test environment, setting up a staging environment that you can test in so that you can test things. And put a lot of investment into that so that you can do solid testing before you get to production. You're not going to get poisoned that way, in the way that you would if you go straight out...
\n\nEDDY: I want to say that it's kind of funny because you say if you've lived that pain, you're saying, "Don't eat it. It's bad for you." But sometimes, your body acclimates to that substance that you're eating, right? And then, you just don't notice that it just tastes awful. And that's kind of just what happens in code. It's like, you might be doing a bad practice, but you're just so used to doing it. Your body just got so used to doing that that you just don't realize, you know, that it's bad [laughs] until you have someone else who's trying it for the first time, and they're like, "Oh, dude, this is pretty gross, dude."
\n\nMIKE: [laughs] Yeah, it's true.
\n\nWILL: There's a lot of things that were, you know, they were good until they were bad, or even worse, more commonly, they were relatively benign diseases. They weren't going to kill you until you got to a particular stage. I've done all kinds of things in a small team, small, high velocity, tightly integrated team, but we're fine. They were all fine. But on a more, call it, enterprise scale, you know, organization, they would kill you dead as fried chicken. So, it's not a cut-and-dry thing. The argument would be that for those small, high-velocity teams, if you're not moving fast, if you're not cutting corners, you're not going to make it to enterprise scale where you can go so slow.
\n\nMIKE: That's a really interesting point. You can get away with a lot of stuff when it's just yourself. You can get away with a lot of stuff.
\n\nWILL: And you have to. Let's talk about the things that are going to kill you when it's just you out there on a wing and a prayer. Like, you need to ship, and you need to ship today. And like, oh, you don't know how to do that? Well then, you're just going to do the best you can. Overwhelmingly, the thing that is going to kill you is running out of time or money, right? Like, 10 [inaudible], if not higher. And so, it's like, oh, security is not so tight here, and I'm like, no, it's not [laughs], you know? It's not.
\n\nEDDY: There's an estimation of good time for half a day. So, you need prep time to get there. But sometimes the party is in the next hour, right?
\n\nMIKE: [laughs].
\n\nEDDY: So, you're like, well, dang [laughs]. Well, I guess I'll just put in an extra cook to turn on the heat a little bit, you know, get it done in an hour, and hope that it tastes the same.
\n\nWILL: Exactly. I mean, being worth robbing, you know, by cybercriminals, being considered worthy of being a ransomware target is, you know, that's first world problems, baby. You made it [laughs]. It's like getting sued by a patent control. Like, hey, there you go, like a disturbing truism that, like, a rite of passage to be like, oh, I've got an actual business now. I'm actually a businessman now, is getting sued for the first time. Your first legal letter where somebody tries to shake you down. It's like, oh, you made it, baby. There you go. Look at us now.
\n\nMIKE: [laughs]
\n\nWILL: I'm worth robbing.
\n\nMIKE: So, we're digging into this idea that the consistency that is absolutely critical for managing a larger organization can be less so when you're working with a smaller organization because your circle of trust with a smaller organization is so easy to maintain. You all know where things are bad when you've got the small team. I'll say, "Oh yeah, there's that bad thing. We all know it's terrible. Don't step there."
\n\nBut as you grow, that shared knowledge becomes harder and harder to maintain, and it becomes more and more important to have standardized practices, standardized ways of sharing information, ways to replace people when they move on or, you know, otherwise removed from the organization. And that's a challenge as you grow, and it's going to chafe a little bit. And you're going to be like, "Hey, I miss my freedom to do whatever I wanted." And to have the maturity [chuckles] to say, "You know what? I need to change. I need to change what I'm doing, or else I'm going to cause harm because being a cowboy is not going to work anymore."
\n\nEDDY: There was an off comment, you know, that was kind of relevant to what you're saying but I kind of want to expand on a little bit. It was, you can tell someone the direction and tell them, "Hey, don't step there, right? There's a trap door. You're going to fall." But what do you do in the instance when you tell someone, "Don't step there." And they respond with, "Oh, it's okay. I can fly," right? Like, what do you do [chuckles] in that circumstance? You're like, "No, dude, you can't fly. I've been there." And they're like, "Oh, no, no, it's fine. I'll be fine." Like, what do you do? How do you keep quality when the individual believes that they're not affected?
\n\nWILL: It depends on the blast radius of the problem. I am a believer in sort of you break it, you bought it. If somebody is willing to say like, "I want to do this thing. This is my thing. I will take ownership of it," and the blast radii is small enough so that if it goes bad, then...you know what I mean? Like, it is a human-sized error with a human-sized sort of level of consequences, and somebody comes to me and says, like, "No, I'm going to do it my way," I'm like, "Okay, do it your way," you know? I believe in sort of agency like that. You have to be mindful because, a lot of times, things can be slow-growing systemic problems. Make a judgment call whether you can afford to let somebody go and try it their way.
\n\nIn my estimation, the way I make those decisions is, is it a really big deal for you, and can you shoulder the consequences of it yourself? And so, if it's a manager, it's like, okay, the manager's team can shoulder it. If it's an individual developer, then the individual developer can shoulder the consequences thereof. I don't know. If I can say "Yes," then I will, honestly, because that's how people learn. And if I can, I try to explain why. Or I'll come up with a sort of rubric to be like, "Okay, try it your way, and these are the conditions under which I will say, you were right, and I was wrong. These are the conditions under which I will say, ah, you know, I mean, this is just tomato, tomahto. Both are, you know, more or less equivalent. And these are the conditions under which, like, can we all agree that I was right and just do it my way now, you know?"
\n\nEDDY: I agree. You're like, at what point does it start tasting bad? If you're saying add more sugar but without the added sugar it still tastes okay and you're okay with the taste, you're like, "Yeah, yeah, it's fine. It still tastes all right."
\n\nMIKE: [laughs] It goes back to --
\n\nWILL: And I'll say there's a lot of stuff out there. The overwhelming majority of decisions fall into that, I would say, broadly, you know, that tomato, tomahto kind of a situation. It's very rare that you'll have a black-and-white this is wrong scenario.
\n\nMIKE: I was going to say that goes back to the ownership discussion that we were having before. If you don't give the team...so this is opinion of me, but I think it's right [laughs]. If you don't give people ownership, then they won't have any reason to take responsibility, and you get ownership by making those choices. You're committed now. You've made the choice. You see how it works, and now you care how it turns out. And, yeah, maybe you've made the wrong choice, and you learn from it. Maybe you make the right choice, and now you've got something defensible, and you'll care about that the next time.
\n\nGiving people that chance, you know, the tomato tomahto chance to do it their own way, it may sound superficially important, but I think that it's actually critical for giving your team the opportunity to actually make consistently good code. Because if you take away that control, well, then nobody cares. I don't want to say it's like slavery because you can leave the job [chuckles]. But if you don't have any agency in it, then you just don't care.
\n\nEDDY: Well, and I think what's more important is if you have a new cook in the kitchen and you're constantly holding their hand, they're not really going to learn anything. However, if they end up burning the kitchen, they are going to remember. And they're going to be like, "Dang, I had to clean all this up. And all this mess, I had to clean it up." But then, guess what? The odds of them burning the kitchen again for the same recipe probably isn't going to happen anymore. So, I think there is some benefit to putting trust in your cooks.
\n\nMIKE: I was building on what you said before, where you have to have that watchdog that keeps going. And the way I say you develop that, I think you're right that you need to have somebody who cares enough to keep people in line. And I think you only get that, and this is why I've been talking about the ownership: if that watchdog actually feels like they own the code, feels like because they do.
\n\nThey're only going to care enough to keep the code good if their actions matter, you know, if they actually get to make those choices, which means you got to let go of the hand and let them do it, which is going to be uncomfortable. But then they will own it, and they'll learn, and they'll become that fierce owner, you know, it's their thing, and care enough to keep the code solid. And I think that having a culture of giving people the chance to actually own the code is hand in hand with having quality code, that you can't take away control and expect the best practices to continue because it rubs against human nature. That was my high-level idea.
\n\nWILL: Yeah, no, I totally get it. And so, the question that I have for you guys, this is kind of a broad thing, but, like, how do you cultivate that kind of [inaudible]? How do you value people who have been around long enough to take ownership? What are engineers like that worth to you? How do you build that stuff up? How do you keep...I would say, I love institutional knowledge. I love people with ownership. I love all that stuff. I am very fairly stridently against the idea of seniority as if, like, sort of years on the job is a suitable proxy for these desirable qualities. So, how do you make that happen?
\n\nI won't bury the lead, but one of my great bugbears of the industry and one of the things that I...I really hate the fact that you've got to move around to move up, and I understand the countervailing forces there. But, like, if you didn't want to do that...because all these things that we're talking about, these watchdogs, this ownership of code, this isn't the kind of thing that you can have with people moving every two years. But if you're not moving every two years, there are consequences for your career, which can be fairly significant. How do you manage all that stuff? How do you create these cultures that we all agree we need but there are so many headwinds against?
\n\nMIKE: Well, Netflix, if I remember right, so I'm going from memory here, but my understanding is that for years, they had a policy that if you got a job offer somewhere else, they would match it. No questions asked. They cared enough about that continuity. They put their money where their mouth was. And so, they had some of the best-paid engineers in the industry by some margin, sometimes, like, you know, 30%, 50%, 100% more than some of their peers.
\n\nBut I tell you, you do that, and you get a committed team who cares enough to stay around. I think they did the things because the company cared enough to actually do what they said and value their team members. The result was they got a team that made them extremely successful. So, I think that there are examples in the industry of people doing right. But there's a lot of examples of being short-sighted because there's a lot of incentives to be short-sighted, to say, "Well, we need to save money. We need to make the stock price go up., And we're going to get that by reducing costs," which is a reasonable thing to say. But then what happens next is dicey, right [laughs]?
\n\nYou say, "Well, what you do next shows what you value. And if what you do next is continue to value your team and pay them appropriately, well, that shows what you value." If what you do next is say, "Well, let's get rid of all of our senior experts because they cost a lot, and let's hire a bunch of new folks without any context and, you know, it'll work, right?" Well [chuckles], you've shown your values. And there's a hazard, I think, to leadership to make decisions that will probably turn out well in the short term but will lead to a steady decline over the long term.
\n\nEDDY: It's like what do you do when the only two people in Coca-Cola suddenly die and they're the only ones that know how to make your recipe, right? You can get pretty close to the genuine taste, but you just know that it's going to be a different taste, and it's not going to be the same.
\n\nWILL: Well, like, the great [inaudible] are full of indispensable [inaudible 27:49], right? And I think there's a counterargument to be made that your initial team is the people you could get. But as things go on, as the company gains legitimacy and financial power to compensate and hire and retain good developers, that original team maybe, like [laughs], uncomfortably accurate definition of a technical co-founder, is the best developer you can get to work for free.
\n\nMIKE: [laughs]
\n\nWILL: So, you could start bringing in more heavy hitters as time goes on. And a lot of the decisions, engineering decisions that were, I think, defensible, if not absolutely correct at the time, are no longer so. There's a flip side to that as well. Everything is a golden [inaudible] [laughs], right? You're always trying to find a balance.
\n\nMIKE: Sure. What you probably don't want to do, though, is hire these great, new folks, keep them around for six months, and then send them out the back door. And maybe you're deluding some of the people there originally, or maybe you do ask them to leave. But you're still looking for continuity with people who know what they're doing. There's still the respect for expertise and, again, not seniority per se but expertise.
\n\nWILL: Well, yeah, and then it becomes a sort of a leadership challenge in that you need to sort of walk people down where they were, at one point, a law unto themselves, and now, you know, maybe they have a manager. And I think, arguably, the current stock option regime mirrors that, I think, pretty well in that, you'll have your founding teams, and they'll get a big slug of equity. Like, your initial hires they'll get a big slug of equity, and that equity will appreciate and appreciate and appreciate.
\n\nAnd people will come in. You'll get your series A round. And you'll start to bring in some real hitters, and they'll get more compensation. But the people who came there blocked the stock, and it's worth a lot more now. And so, they have, you could argue, golden handcuffs on one hand. But you could argue they're paying for institutional knowledge and continuity, even though they might not be continuous in the same role. Everybody sort of gets a...it's a fair shake there.
\n\nMIKE: It's interesting that we started by saying, "What scares us in the code?" And we're talking about stock options [chuckles]. And I don't think that's off. It seems like a tangent, but I think it's inseparable in that we're talking about the practices that lead to ownership and people caring enough to make the code solid.
\n\nWILL: Well, exactly. Well, we talked about the code for 5 or 10 minutes, and then we immediately jumped to the real problem, which is sort of maintaining the team, maintaining that culture of engineering excellence, maintaining a sense of ownership and responsibility as things scale, as things get bigger, as the problems get more complicated. I mean, that's it. That's the issue. There's no two issues around it. As long as everybody is coordinated, and focused, and disciplined, you can sleep pretty soundly. I mean, every once in a while, something's going to go bad. But, man, dude, nothing makes me happier than a problem that got successfully opened, closed, and resolved, and I didn't have to lift a finger. I'm just like, ooh, ooh.
\n\nMIKE: [laughs]
\n\nWILL: Oh yeah, oh yeah. What's up? Oh, that was Saturday.
\n\nEDDY: For those who are fans of --
\n\nWILL: You guys had a rough Saturday, boys.
\n\nMIKE: [laughs]
\n\nEDDY: For those who are fans of Emperor's New Groove, there's a meme where he goes like this, and it's like an okay because it's just so perfect. And that's what you made me think of when someone reports a problem, and it just goes fluid, and it just goes perfect. Awesome moments that you sleep like a baby.
\n\nI do want to say that there's a couple of situations or circumstances that sort of keep me up at night, and one of those are having a tower, where the foundation of that tower on the right side is held by a twig. It's so freaking scary because that's legacy code. And touching something where you just don't know where it is, you can make the change that's super scary. And I feel like a lot of us sort of try to avoid that and find another alternative because it's like your whole app is rooted off of it [laughs]. So, that's one of the things that keeps me up at night.
\n\nMIKE: That goes back to the continuity we've been talking about. Hopefully, you can keep the continuity so that you have somebody who knows how to work with that twig and can share it, sometimes, though, you don't. And in an older codebase, you probably don't have people, and if they do, they're probably spread thin and don't have much time to talk to you about it. And that's a difficult problem that –-
\n\nWILL: I don't know, I'll say that just, for me, I don't spend a lot of time thinking about pieces of the codebase that have been running without complaint for many years. Those are not high on my [inaudible]. Nothing like battle-tested code. Although, gentlemen, if you can't hear, I am being paged. I think it's time. I think it's my time. I will talk to you guys. See you guys.
\n\nMIKE: As Will was saying, if it's working, you don't have to worry about it. Sometimes, though, it stops working [laughs] or needs to be changed. And then, you got to have somebody who can go in there and fix it. I can bring up one example. She's not here, so I'm not going to name. But I worked with a really good engineer who was obsessive about detail, and she'd see something, and she just couldn't help figuring out why it worked and how it worked.
\n\nAnd it meant that it took her a long time to get things done initially because she would understand what was going on before she pushed up the code. But it also meant that once she'd worked in the area, she understood it, and she could get that job done. And anybody else who needed to work in that code would go to her because [laughs] they knew that she could help them understand what was going on.
\n\nHaving somebody who can have that level of focus where they will take the time to actually figure something out is so valuable because it solves your twig problem, Eddy [chuckles], because they'll take the time to figure out exactly how it's working. And there's a hazard there because you might think, well, their output is not as high. They're not cranking out a bunch of code because they're going to take longer to get things done generally because they're not going to push out their changes until they're sure they work. But they provide immense value to the team [chuckles] because having somebody who actually gets it is just so valuable.
\n\nEDDY: I agree. I agree. Now, there is another thing that keeps me up at night. And this is when you have a long chain, and they're all connected to one another. And in this chain, it calls another chain, which calls another chain, which calls another chain, which calls another chain. And, suddenly, you have 17 chains that are hooked up, right?
\n\nMIKE: Link after link [chuckles].
\n\nEDDY: Oh, that was so bad because then what you have to do is...and they tell you, "Oh, modify this chain." And you're like, ah, see, I don't know. I don't want to modify the middle. That's too scary. I don't want everything to just split open. So, what I find some people do it's like, oh yeah, we'll modify the tip. We'll modify the end. We'll modify the other end. And that's why you get a long series of chains, and that really keeps me up at night any time I have to touch any of that code.
\n\nMIKE: Well, and if you're doing that also without doing any refactoring, you probably end up with 20 parameters to the end of the chain, where the chain began to try to promote reusability. And then, oh yeah, well, there's this component that could be reused. But if you haven't figured out what's going on in that chain, the reason why you have it, then you're not going to reuse one of the components and kind of branch the tree where you need to. You're just going to tap in at the end and add another parameter to make it do what you wanted, rather than going deeper into the chain. The part that does do what you want, you could have [inaudible] in there.
\n\nEDDY: Yep. Which is why I sort of adopted the ideology of singleton classes. I really do enjoy them a lot. They're much easier to work with.
\n\nMIKE: Singleton can have a few different meanings. Could you clarify exactly what those parameters are that you're --?
\n\nEDDY: Sure. So, for me, a singleton class is just a single hand of responsibility for that class, and that's all it does. [crosstalk 37:45], right? Like, don't branch off of that. It's possible that you can go beyond that if you want to, but don't violate that. It's part of...there was a book that we read on Ruby, which was...I don't recall the exact name of it off the top of my head. You might remember it, Mike. But the whole –-
\n\nMIKE: On "Design Patterns"?
\n\nEDDY: The "Design Patterns," yeah. So, part of the idea of the design pattern from that book was don't go beyond of what the class is intended to do because you risk maintainability and reliability from that class. So, if you say, oh, this class' whole purpose is to structure a hash, and that's all it does, and you're like, oh man, but it would be really nice if it would also do this, and you're like, yeah, see, it works. And you can do that, but don't do it, right?
\n\nMIKE: Single responsibility, single responsibility. So, I wasn't sure where exactly you were going because sometimes singleton can mean that you've got something that's self-contained, so it's both...there's only one instance of it in all of your running application because the class will only create one instance of itself. And so, you have that single shared instance across the application, so you avoid issues with duplicates of it.
\n\nAnd so, if you're managing a connection pool, for example, you don't want to have two managers of the connection pool. You want to have one, so you don't...only one person in charge. But what you're saying is something a little different, which is single responsibility principle, your unit of code. And if you're functional programming, you don't have classes, but you should have your function. It should do one thing. It should do that thing well, and it should do nothing else. And if you've got something else to be done, well, some other unit of code should do that.
\n\nEDDY: Agreed. Now, you run into issues where you implement modules or concerns that essentially do the same thing, but they deviate slightly. And that's also a problem that's really hard to address.
\n\nMIKE: Are you talking about people writing code that's almost the same but not quite?
\n\nEDDY: Yes.
\n\nMIKE: [laughs] Yeah. And so, they end up diverging.
\n\nEDDY: And, suddenly, instead of maintaining just one, you're maintaining two. You're maintaining three [laughs].
\n\nMIKE: Well, that gets to the don't repeat yourself. Don't repeat yourself is actually kind of subtle because there's times when you absolutely should repeat yourself. And here's where I take that. In cases where the repetition is trivial and makes things easier to understand, then you should repeat yourself such as in a display component. To take something to its logical extreme, let's say you said, "Well, all markup uses tags, so I want to make sure that every single tag is written by shared code." And so, you have to go through this shared code to render a tag.
\n\nAnd maybe you have some sophisticated component. Maybe you're writing a front-end component where that actually does make sense. But if you're just writing out some markup, then that's probably a really bad idea because you're going to have all kinds of complexity, or you could have just thrown some text out there, and it becomes far harder to manage.
\n\nLikewise, unit tests. People sometimes think, man, I'm going to make sure that I have no duplication. So, they take anything that might possibly be shared and put it into a shared example that's in some other file that you have to go digging [laughs] to find. It makes it so hard to see what it is that you're testing, where if [inaudible] the details and repeated them, then it would be a lot more comprehensible. So, I'd say don't be so DRY that it chafes [laughs].
\n\nEDDY: I've received code where I've reviewed where they've obscured all the dependencies to top level in the specs, and they just call one subject, right? Boom. And then, like, that's the whole context for that test. And I'm like, no, what? What's going on here? And so, I have to go and I have to dig to figure out what's all the dependencies for that. And I'm like, sometimes I wish, man, can we make this a little bit more DRY? Just a little bit more so that we have...because tests, in general, should document themselves, right?
\n\nMIKE: Yes.
\n\nEDDY: And if you're obscuring that for your reader, then you lose context and it's really easy to keep all that in your head. So, I have tried to push a bunch of new tests that I've written, right? And I've applied a bit of dryness to it.
\n\nMIKE: Well, less DRY [inaudible], like, in this case, less DRY. You are going to repeat yourself. It's important for legibility. But then, on the flip side, you say modules will do the same thing. That's where it actually matters a lot to not repeat yourself because you are going to have to maintain two things, or then three things, or then four things that are slightly different that basically do all the same thing. And now you've got to maintain all of them. And, in that case, for important business logic, yeah, put it in one place and one place only. For unimportant display issues, repeat yourself at will.
\n\nEDDY: I have pretty much bent the knee, and I've said, all right, I'll settle with damp [laughter].
\n\nMIKE: You like your code moist.
\n\nEDDY: Yeah, it's a little moist, you know, best of both worlds. It's fine. You know, not too extreme one way or the other. But you have ideas from both is really where...because you have to be able to differentiate between syntactical opinions, right? That doesn't really, like, it has the same functionality, you know, same everything. But the holdup really just becomes from that individual's opinion on how the code should read versus how it functions, right? So, at that point, you really just...you have to give in. And you're like, eh, it was just syntax, not a big deal.
\n\nMIKE: Let people make their own decisions a little bit [laughs].
\n\nEDDY: Agreed. And it came back.
\n\nMIKE: It did come back. That's maybe a good stopping point, actually.
\n\nEDDY: Agreed.
\n\nMIKE: So, we looked around a lot and didn't talk a lot about specifics in the code but a whole lot about practices that tend to drive good code. And so, we sleep well at night when we give people the agency or ownership to make their own decisions. It sounds like it might make you sleep worse at night [laughs]. What's my teenager out there doing [laughter]? And if you've given that teenager the chance to make good choices since they were three, then maybe you are sleeping at night because you trust them to make the choices you've already seen them making.
\n\nEDDY: I'm not a father personally, but I do attribute my tests to do the parenting for me [laughter]. So, I sleep better at night knowing, you know, that my tests are holding me accountable.
\n\nMIKE: That's great. Well, thank you, Eddy, and thank you [inaudible]. It's been great and until next time on the Acima Development Podcast.
","summary":"","date_published":"2024-08-07T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/cd80c813-86b0-4c92-bbb6-41972cc98925.mp3","mime_type":"audio/mpeg","size_in_bytes":27356490,"duration_in_seconds":2739}]},{"id":"88f5e20f-63ed-4cbf-a84a-0a8fd8dfcd81","title":"Episode 51: Changing Languages","url":"https://acima-development.fireside.fm/51","content_text":"In this episode of the Acima Development Podcast, the panel delves into the topic of changing programming languages in applications. They reflect on their experiences transitioning between languages like COBOL, Perl, PHP, and Ruby, highlighting the complexities and costs associated with such endeavors. They stress the difficulty of converting large, established applications to new languages due to the potential for high costs and disruptions, as exemplified by legacy applications still running on COBOL.\n\nA significant part of the discussion revolves around the value and challenges of rewriting applications in new languages. Will presents a strong argument against rewriting code, citing examples where organizations have suffered due to poorly executed language transitions. The group agrees that the decision to switch should be driven by practical needs, such as performance improvements, scalability, or security, rather than the whims of new leadership or a desire for modernization. They also emphasize the importance of mentoring junior developers and avoiding language specialization that can lead to organizational inflexibility.\n\nThe podcast concludes with reflections on the current trends and the future of programming languages, referencing the Stack Overflow Developer Survey. They note the rise of languages like Python and the enduring niche of Ruby. The hosts acknowledge that while modernizing or changing languages can sometimes be necessary, it should be approached with caution and clear rationale to avoid disrupting productive teams and established workflows. They suggest using opportunities like refactoring to evaluate and implement new languages gradually without jeopardizing existing systems.\n\nTranscript:\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm hosting today. I have with me Matt, Justin, and Will. We're happy to have Justin with us. So, Justin and Will are not Acima employees. They have been in the past. And it's great to have both of them with us to provide their insight in their current endeavors. Great having you back here, Justin. \n\nJUSTIN: No problem. And I do have to say that I went from one Utah startup that is an A startup with five letters to another Utah startup that was an A startup with five letters.\n\nMIKE: [laughs]\n\nJUSTIN: Both of which were acquired by big corporations and both of which have interesting relationships with the parent corporation. \n\n[laughter]\n\nMIKE: Does it --\n\nWILL: I know, like, one guy at a startup number two. I'm very curious. I'm very curious. Like, you know what I mean, I'm always curious about like, you know, the hot goss which we won't get into. \n\nMIKE: Exactly.\n\nWILL: I went from a Utah retailer to a big box electronics retailer, that one [laughter]. And, you know, it's a different environment. \n\nMIKE: Well, and this is perfect. But today we're going to...I'm just going to jump straight to the topic today. We're going to talk about changing languages in your apps. Now, this applies in, you know, languages that you're doing, but we all have applications that have been around for a while on some languages, and, eventually, that doesn't work very well anymore.\n\nNow, there are still applications out there in COBOL. I don't think that anybody says, you know, \"I want to create an application in COBOL,\" [laughter] because it's a language that hasn't been actually [laughs] developed for, like, what, 50 years or something [laughs]? I don't know. I have to go look at exactly how long it's been since COBOL was, you know, like, a popular language. \n\nBut you know what? There's still COBOL developers out there [laughs], and there's still COBOL applications out there. Because it is so hard to take a big working application and so expensive to convert that into a new language, which will itself eventually fall into disuse, and then you have to do it again. And, you know, the bigger the application, the more that costs. \n\nMATT: ...Started my career. \n\nMIKE: Did you? COBOL?\n\nJUSTIN: COBOL? \n\nMATT: Converting COBOL and FORTRAN applications to Perl and PHP web applications. \n\nMIKE: Wow.\n\nJUSTIN: Wow.\n\nMIKE: To Perl. So, I wonder if that's happening. So, I was thinking about leading out...I thought, you know, I'm going to lead out with COBOL. But I thought about talking about my [laughs] first year as a professional developer, where I wrote in Perl, [laughs] right, you know, as well as other languages and, you know, comparing that. I'll say, I worked in Perl and then went away from it. I came back to Perl, and it was, like, starting from scratch [laughter]. It was a challenge.\n\nMATT: I do still have some love for Perl, though. \n\nMIKE: It's a cool language. \n\nJUSTIN: [inaudible 03:24] as well on my first programming job, also. \n\nMIKE: Oh.\n\nJUSTIN: It was great. \n\nMATT: PHP, not so much love, but... \n\nJUSTIN: No, [inaudible 03:32] PHP.\n\nWILL: I don't know, I like...like, Perl's, like, the Vi of, like, programming languages. I mean, like, in that, like, I could do it, but I never really got right with it. But I saw people who were, like, old, grizzled, wizard beards, sys admins just cooking on some, like, Perl scripts. And I was just like, okay, okay, like, this is, like...like, I'm seeing what's happening here, and I could recognize that, like, this is a power tool for, like, serious people to do serious work. This has utility. \n\nMATT: You can accomplish a whole lot in Perl with very little code. It's the king of obfuscated code. \n\n[laughter]\n\nWILL: Ah, it is, yeah, yeah. \n\nMIKE: Perl was the inspiration for the name of the Ruby programming language because they have a lot...\n\nJUSTIN: Ooh. \n\nMIKE: Yeah. Ruby would not be called Ruby if there had not been a Perl beforehand. But I got to say, when I started Ruby, it made sense, and that never went away [laughs]. Like, Ruby is like Perl, and it has still some weird Perlisms in it, if you go looking for them. It's like Perl intended to be easier to read. \n\nWILL: Yeah, with an emphasis on sort of, like, readability, and, like, actually object orientation and stuff like that, yeah, completely. I got a hot take for this one, but I don't know whether anybody wants to get in here. \n\nJUSTIN: So, I've got a hot take. I mean, I'm sure we all have hot takes for this one [laughs]. Why don't you go first? I have a good, lukewarm, and a bad experience, so three different experiences. \n\nWILL: My hot take on, like, when should you rewrite your program in a new programming language is don't. Don't. I have seen...I don't even want to say 10 bad examples to 1 good example, you know what I mean? But I think it's actually even higher than that. And I have seen entire organizations, entire companies ruined with just this sort of thing. It's almost like an organizational anti-pattern, where you'll get some new hotshot CTO. He comes in. He has a tech stack that he favors. I say he; it could be a she, but it never is. It's always a dude with an ego and a tech stack, an area of expertise, a team of, like, people that he trusts.\n\nJUSTIN: Yeah, and he brings --\n\nWILL: And then, they come in like a bull in a China shop. They rewrite everything in their tech stack, bungle the job, screw up the product roadmap, and, like, take the entire organization down, you know what I mean? And then, he sails off in his golden parachute to do the exact same thing again. I recognize that, like, there are no such things as absolutes in engineering, but I am an overwhelming no. Absolutely no. Like, there's almost always ego, programmer laziness, and sloth. \n\nI can't think of a language, a modern production language, that can't be reformed instead of replaced with 10 times less cost and a better outcome. Even PHP, which is a dog, gutter terrible language, has been remediated. It's fine. You can do PHP well now. You can do it, so do it. And, like, if you're a programmer that just doesn't want to learn another language, [inaudible 07:12]. Sorry. Like, I mean, it's laziness, sloth, and arrogance. Like, there's no...you know what I mean? Yeah, that's it. That's my hot take. Don't. If you want to do this, you're wrong. Don't do it. \n\nMATT: So, you said a couple of things there. One, you used the word modern. \n\nWILL: Yes. Important [inaudible 07:34]. \n\nMATT: I am wholeheartedly against the idea of modernization for the sake of modernization. If it's not broke, don't fix it. You know, we all face this. Everywhere we go, we face this, right? Some hot, new language comes into town these days. It's Node.\n\nJUSTIN: Java.\n\nMATT: And JavaScript backend. \n\nMIKE: It's some new language that'll be transpiled into JavaScript. That's what it'll be [laughter]. \n\nMATT: Yes. Yes. And --\n\nWILL: And has transpilers all the way down [laughs].\n\nMATT: And everyone wants to jump on that bandwagon when they have a stable, expandable, scalable system. \n\nJUSTIN: Okay, I've got one example where it worked, and that was in mobile, in the Android world. It was originally written in Java, and it still is in Java. About 2017, 2018, Kotlin came on the scene, and Google and JetBrains, no, IntelliJ, whatever, IntelliJ.\n\nMIKE: JetBrains. \n\nJUSTIN: They did it right. They were able to convert Java programmers over to Kotlin programmers. And they were able to convert codebases from Java to Kotlin with minimal issues. And it helped. I mean, there was a lot of things there about why it worked, but a couple of the main things that I could think of were that Kotlin, at the time, was just plain better than Java. \n\nAnd then, two, Kotlin was compiled down into the JVM. And then, three, to convert a Java file to Kotlin, IntelliJ had a button that said, \"Convert this Java file to Kotlin,\" and it converted it into working Kotlin. It may have been a little wordy, but it worked. And you can do that class by class. And it would work alongside the Java files and the Kotlin files. They would just work alongside. They were in the same codebase. And when you hit compile, it all worked. \n\nMIKE: I've also seen a success story that's even different than that. It was a Java application. And this kind of goes back to Will's [laughs] saying before...the incoming people...it was an acquisition. The new people said, \"You know what, we're not going to use Java anymore. We need to use a scripting language.\" And their preference was PHP. And this was a long time ago, but still [laughs]. \n\nWILL: Oh, man. Oh, oh.\n\nMIKE: And I had been to a Java users' group where they had talked about Ruby on Rails and showed how, hey, you know, this is a, you know, a structured framework that is responsible and uses scripting language. You got to think about it. And so, I thought, you know what? This is old PHP, right? This is before all of those problems that you talked [laughs] about, Will, had been fixed. They were all still very much there. But I was like, you know, I like my life. I don't want it to go [laughter] in all sorts of bad directions.\n\nSo, I went, like, in a weekend, I learned Ruby, wrote a prototype for the new version of this, and said, \"How about we try this? It's already starting to work,\" and got them on board with trying this other, you know, language: Ruby. And we converted over. We ended up with one-tenth of the lines of code and more features. \n\nMATT: I've had similar success. And when I said that, I didn't mean you should never do this, right? Because there is a time and a place. And one of our successes was a big PHP monolith into Ruby, so much better, so much cleaner. But there was reasoning behind why it happened, you know, new lines of business. It was in healthcare. So, we now needed to support claims and imports from health plans, EDI imports, and, you know, all sorts of things that the old system didn't do. And it justified, hey, it's time to version this and roll out a new system. \n\nWILL: But I want to...hang on, I want to get in here because I do take your point, Justin, and I agree. And I have experienced the same thing with sort of, like, legacy JavaScript stuff moving over to TypeScript. However, I don't think those are rewrites. Those aren't rewrites. And I don't actually think they're new languages. I think Kotlin is just JavaScript 2.0, you know what I mean? \n\nJUSTIN: Java 2.0. \n\nWILL: Yeah, Java 2.0. Similarly, like, TypeScript is JavaScript, like, 1.1, right? Where, like, you have...no, well, you have strong interop. You had the same project. You had the same codebase. And you're just sort of like, I know that they're different languages for, I think, mostly legal reasons, you know what I mean? Like, there's two big organizations butting heads, and like, so, like, the Kotlin people just forked it, you know? TypeScript is the de facto standard. Like, TypeScript took over JavaScript. Like, I don't even think they should call it TypeScript anymore because if you're writing JavaScript-JavaScript, like, you should stop [laughs]. \n\nBut that's it. That's my point. Like, I agree, but I actually think it's more of a...that's more of an upgrade, you know what I mean? Like a major version upgrade of your programming language rather than, like, redoing it, you know what I mean? Subtle point, but yeah. \n\nMATT: Now, there's ways also to approach this, right? You have a monolith. You decide you want to start extracting microservices. Perfect time. You know, maybe there's technologies that will support the job you're trying to accomplish better than what that monolith was written in for this particular task. And I think those things are super important, as well as how hard is it to find engineers for the languages you're supporting. That's a big one, right? \n\nWILL: I think that's a mistake mostly in hiring, if I'm being direct. Being that, like...how do I put it? Like, I think if you're hiring engineers with language expertise, you're probably doing it wrong because I find, like, language expertise to be...for a good engineer, it's not that big of a deal. You're going to spend...it's a 10 to 1 ratio around learning the codebase, and the company, and the systems, and all that stuff, versus it's this much figuring out how things are done in Acima, and, like, this much learning Ruby. And Ruby is probably one of the hardest languages just because there's so much magic, you know what I mean, associated [crosstalk 14:30]\n\nMATT: Yeah, I agree, when we're talking about senior engineers, right? I've always considered myself language agnostic because I don't care. I mean, I do care a little bit, right? I'm not going back to PHP. I'm just not. But when we're trying to mentor junior engineers, you're moving people over from other departments, that becomes a little more difficult, right? Because the learning curve is already pretty steep. When they start to get used to one language, to throw them into a new one, I think, provides more challenges. \n\nWILL: Yeah, but they get more support.\n\nMATT: Once you have some experience, absolutely, I agree, right? \n\nWILL: I think it's more impactful on a junior engineer because it's like learning a different, like, human language, in that, like, you learn a different language, and you think in a different way, you know? You learn Ruby, and you think in a Ruby way. You learn JavaScript; you think in a JavaScript way. You learn nasty, old C, and you think, in, like, a different way, and you have a different perspective. I think for junior engineers, actually moving around in ecosystems is actually even more important because they'll learn better habits and they'll have more informed opinions. \n\nI think when you have a junior engineer, God help them, right, that makes it through all the way through to senior without ever having sampled, you know, from a combo platter, that's when you get this sort of, like, senior people that are not language agnostic. And those are the people that come in because they don't know any better, and they're like, \"This is all I'm good at. All I'm good at is .NET.\" So, you're a .NET shop now. And those people are dangerous. \n\nMATT: Yeah, well, I agree with that. Point being, it becomes more difficult at that point, right? Because, as a company, we still have to focus on delivery, and it makes it harder to deliver. I agree. And we're all ADD, right? Every single engineer is ADD. We love to learn new things. \n\nWILL: That's because engineering is boring [laughs]. \n\nMATT: We love to make things easier on us because we're lazy, and we're very inquisitive. So, we like to solve problems. I love learning new languages. It's one of my favorite things to do, just, you know, that exploration and experience of something new is awesome. But there are some challenges behind it. \n\nJUSTIN: So, Will, you mentioned earlier about the refactoring. And, you know, Martin Fowler wrote the book on \"Refactoring.\" One of the things I vaguely recall him talking about, when you are going in to refactor something, and that's basically what you're doing, is, when you're rewriting something in another language, you are deciding that you are going to refactor it, even if it is two totally different languages or as you say, Matt, like, you're changing...you got a monolith or something, and you have to break it apart. You have to identify the parts that you're going to move over to the new language and do that in an organized manner. And you have to be very cognizant and purposeful about what you are doing.\n\nAnd those types of things mean that, I mean, help you, if you have to do this anyway, help you on your road to success. So, I don't know, big hot shot coming in and mandating stuff, sometimes you just have to go in and do what they say. And so, if you're going to do it, you might as well do it right. And that involves, you know, being an expert at refactoring and being very purposeful about it, so... \n\nMIKE: You suggested something really interesting because if you extract out portions of an application by one, eventually, you know, you may end up with nothing of the original application because all the pieces have been extracted. So, you've refactored by breaking up into different services. And there was replacement, rather than rework, by extracting services. That's a way you can do this without actually rewriting the application, per se, so much as, hey, you know, this needs to be refactored enough. I'm going to rebuild this component. Once you've built enough components, eventually, the old codebase is gone. There's a kind of a strangulation technique, like a strangler fig. Eventually, the old --\n\nJUSTIN: Yeah, yeah, exactly. And that's the example, the classic example, right? So... \n\nWILL: Well, I mean, and I would also say, like, as I was thinking about it, like, I'm in JavaScript land now, right? And, like, one real serious problem with JavaScript land is framework fever. Man, like, that tribe of developers, they love a framework, God help them. And one thing that I encourage people who are, like, sort of, like, thinking about picking up a new framework to do is, if you want to grab a new framework, grab it as a refactor. Don't grab it for, like, the greenfield stuff. Grab it from, like, this old way, right, where, like, oh, I have this old thing. I'm going to refactor it using this new framework, this new idea, right? \n\nBecause what people will so frequently try and do is they'll so frequently try and do, like, okay, well, we're going to do a new thing. And I want to play with my new toys. And we'll do both of them together, which I think is an exponential increase in complexity. And it makes it very difficult to discern whether it was a good idea in the first place, right?\n\nMATT: Yep. You understand what the problem is if you're doing an extraction, right? \n\nWILL: Yeah. \n\nMIKE: And you can A/B comparison. \n\nWILL: Yeah. Like, is this better, or is it worse? And you can also, like, how do I put it? Like, a lot of times, especially with new frameworks, like, you'll have, like, you won't have a lot of the grime that real-world long-term requirements sets entail. You know, like, you'll do it, and you'll do the simple version, right? Versus, like, the actual reality of like, okay, this is a complex line of business app, and a lot of stakeholders have a lot of asks for it. \n\nAnd you'll sort of, like, you'll skip over all that stuff, you know, and you'll do the tutorial, like, the demo version of something, where it's just like, it's not going to be that simple, and especially for, you know, new, fancy frameworks that haven't been, you know, road tested for a long period of time. Like, a lot of that stuff, like, start getting into the details of like, oh no, I need this. I need this. The security team needs this thing. \n\nAnd like, well, no, I mean, like, the security team, like, often, they will have asks, like, specific asks about like, \"Oh no, I need...anytime you read this thing, I need a log. I need a log of who, you know, even read this document,\" crazy stuff like that, which, like, well, no, for financial stuff, like, that's for real. Like, I need that. I need, you know, I need to encrypt all this stuff on the server, you know, for whatever thing. You know, all kinds of requirements where it's just like, oh, this is the new, hot JavaScript library. But, like, grimy old Java, or, you know, crusty Ruby on Rails, like, they had to fight these battles already. \n\nMATT: Yeah, I don't like change for the sake of change. I always want to know why. Why do you want to switch everything to Node and TypeScript, right? Is it for performance? Is it for concurrency? I don't think so. But you know what I'm saying? I would like to know the reason for these changes because, oftentimes, people are misled by hype. And you're making change simply for the sake of change. And I don't think that's healthy for anyone, especially not a company whose financials are at risk, you know? \n\nWILL: Okay, so let me ask the counter, right? When is it a good idea to change? Let's say I had, you know, like, kind of a core piece of the company that was written in a programming language that was, you know, like, modern. It was current, but it was, like, say it was something like Haskell, right, where it's difficult to write. It's difficult to hire for. It doesn't offer, like, meaningful performance enhancements, and, like, the team is sort of, like, notably unproductive, right? You know what I mean? Like, when is it worth investing in, like, moving away from the thing, right? It's like, oh, I have COBOL written in the 1950s. Okay, that's an easy layout. That's fine. \n\nMATT: Sure. \n\nWILL: But, like, when does it start to make sense? When is it okay? \n\nMATT: I think you just gave the wise with your question, right? Engineers are really hard to find. Team is unproductive in that language. It's hard to support. You can't move engineers from other teams to go support it, those types of things, right? \n\nJUSTIN: Also, it's like, if it's an older language, all of a sudden, the community is not updating it. You know, I'm putting my security hat on here. They're not updating it for security fixes that are on there and, you know, especially, I've seen that with older libraries that are included in whatever language, right? You're depended upon this library, and, all of a sudden, there's a security hole there, and the community has gone on from that library or that language. \n\nMATT: Absolutely. We run into that all the time with gem support, right? \n\nJUSTIN: Yeah. \n\nMATT: You start using these gems, and, all of a sudden, there's no longer support. Nobody's doing security patches. They're not being updated. And now you're stuck. Either you have to take over support of that gem, write your own, build it into your codebase, or find something different. \n\nMIKE: What if you have, like, a super performant Haskell team that's knocking it out of the park? They've got a good connection to the university. You've got, like, a pipeline of people coming in where you don't have a problem. That would change the parameters of the equation, right? \n\nJUSTIN: Yeah, totally. \n\nMATT: Absolutely. Absolutely. \n\nWILL: If I walked into a high-performing team in, I mean, nearly any language, if they were writing COBOL but it was working, everything was clicking, you know what I mean, like, it wasn't just maintenance mode, it's like we are writing modern COBOL and everything is kicking butt, like, I wouldn't change a thing. [crosstalk 24:57] I mean, I don't have a problem with Haskell, you know what I mean? I actually like Haskell. I've never seen it productive in practice, you know? \n\nMATT: Well, you could throw any language, right?\n\nWILL: Like, one of my favorite languages, one of my favorite languages in the world is, I programmed in, like, five years, is OCaml, right? It's object-oriented ML. It's a very...It was like Haskell or like ML if they were, you know, it was designed by people who were trying to get things done. It's [inaudible 25:29] native. It's really fast. It's like, you know what I mean? And it's practical. Like, you can just sort of like...you can downshift and just do some imperative programming and just get it done if you need to. There's one and only one company in the world that uses OCaml. \n\nMIKE: Jane Street Capital [laughs]?\n\nWILL: Jane Street Capital. [inaudible 25:48]. OCaml wouldn't even exist outside of academia if it wasn't for Jane Street. But, like, it works. It works. Should anybody else use OCaml? Probably no. Like, I love it, but I would not advocate anybody to pick it up for anything, ever, you know. \n\nMATT: You said something that I think is really important and that is, you wouldn't disrupt any team that is productive, just meshes, clicks, and gets things done, and meets business needs. However, we see it far too often. Back to your first example, some new hotshot comes in says, \"Hey, we're going to start using this language. We're going to change everything. Turn your world upside down.\"\n\nWILL: I'm a consultant. I will come in, and I will write this platform for you, but I'll only do it if you let me do it in Haskell. \n\n[laughter]\n\nJUSTIN: Well, going back to the situation I'm in right now –-\n\nWILL: I might get emails for this. I know I am. \n\n[laughter]\n\nJUSTIN: So, the company I'm working for right now was acquired by a big bank, which is a Java shop, and they were acquired in 2023. They came in and dictated the Ruby application, which made the company, the startup company, the money, and made it all attractive; they dictated that, hey, this needs to be rewritten in Java. \n\nMIKE: Oh wow.\n\nJUSTIN: And they spent six months trying to do that. You know, there were zero Java engineers. And the big company did not want to give the resources or, you know, provide the expertise and the guidance and everything. Six months later, they said, \"We're not doing it. You guys –- \"\n\nWILL: Who said it?\n\nJUSTIN: The company, the smaller company that got acquired they, said, \"If you want us to keep on making new features and everything and, you know, improving this product, we can't convert this to Java like you want us to. We got to stick on our platform that we want, I mean, that we're on, that we have the expertise on, that we have the, you know, the domain knowledge and everything.\" And, you know, so, basically, six months of development time went down the drain. Luckily, all that happened before I got there. \n\nMIKE: [laughs].\n\nWILL: That, like, I mean, so I guess the big question is, like, you know, what is the big bank going to do? I mean, because, like, you know what I mean? And so, the dangerous part about it is like, that's such a transparently bad idea, right?\n\nJUSTIN: Yeah. \n\nWILL: You've got technical requirements that, like, a Ruby on Rails application cannot achieve, right? Then, okay. But if you're just sort of, like, saying it just to say it, like, you are already making bad engineering decisions, right? And, like, are these guys going to be able to turn the corner and say, like, \"Oh, I'm sorry. We were wrong\"? You know what I mean? Like I said, risky thing to do. And if the big bank had the flexibility to say, like, \"Okay, okay, okay, just do your thing then,\" I mean, [inaudible 28:56]. We all make mistakes. It takes a lot to learn from them. I'd say that's bleeding edge, big bank agility, and flexibility.\n\nJUSTIN: It was, and they accepted it. And they said, \"Okay, you guys can come in as you are.\" They have to come into the environment, right? And then, they were like, \"Okay, if you come in, though, you do have to use our compliance framework and everything like that.\" And we have to add support for Ruby, which wasn't there before. And so, all of that is a pain, but it's all doable. And it's all fitting within the, you know, within the existing architecture, so... \n\nWILL: And I'd say, well, I'd say, like, it's interesting to me, right? So, okay. So, let's get you in trouble at work, right? So, here's the question that I've got, right? So, all right. You've got Ruby on Rails app, you know what I mean? It is functioning. However, right, it's the odd man out. It's through an acquisition, and you're doing stuff differently from the rest of the bank, you know what I mean? Like, you know, it's an acquisition. It wasn't a merger. Like, Daddy is using Java, and you're using Ruby. And that means you are wrong, not them, right? Because you're swimming against the current, against this entire big bank, and it puts you on an island, right? \n\nJUSTIN: It does.\n\nWILL: And you're in Salt Lake City. You're not in New York. You're in Ruby. You're not in Java, right? Like, I think it is incumbent on sort of like, you know what I mean, like...and, like, there are advantages to it as well, you know what I mean? Because you want to be able to have this interoperability, this interactivity with the rest of the organization. Like, how do you, as the smaller party, how do you integrate into the larger thing? \n\nJUSTIN: So, I'm glad you mentioned that because there is an initiative, and they have hired a few Java engineers to do microarchitecture, the microservice architecture. And so, they are moving over...I'm a little unclear if it's, like, net new or existing functionality, but they are going to be moving piece by piece things over to Java. But it is down low on the priority queue.\n\nOur number one thing on the priority queue is, you know, continued growth, which is one of the reasons why the bank bought us. And the continued growth, and the new features, and everything there, all that, where we can serve our customers, is all still in Ruby. And so, it's a separate small team that are doing very clearly defined success story, you know, microarchitecture success goalposts that they could focus on. And then, they'll move piece by piece over to that. And, all of a sudden, our timeline actually went from, \"Hey, you have to do this in the next six months,\" to, \"Hey, you've got a couple of years.\" \n\nWILL: Well, I mean, not for nothing. I actually, like, sort of, like, I don't know whether you guys are doing this at all, but, like, there is JRuby. There's JVM-compatible Ruby. Like, you can run in the JVM. The JVM can sort of, like, swallow you whole, like, with sort of, like, Java interop. And you can start, like, shading off routines, shading off business logic, you know what I mean? Like, I have moved away from JRuby because, like, it was kind of a lot of work to make it go.\n\nI had an application that ran on JRuby in olden times because, like, the JVM had, like, kind of...I don't want to say the bad, old days of Ruby but, like, bad-er days of Ruby when, like, there were kind of memory stuff and scalability issues. Ruby's been working on it for a while, but, like, it was a hobbyist thing that kind of blew up. And there were funkiness. There was, you know what I mean, like, memory management, especially Ruby had some real issues, you know what I mean. And so, I was restarting a lot of servers a lot of the time. \n\nMATT: It's funny [laughs] --\n\nWILL: And so, JRuby is in there, you know, and you can have that call an in interop. You're not going to be able to just push a button and [laughs] convert the file. But, like, you can call...if you can get over to it, you can call Java, you know, from Ruby, you know, pretty sleek.\n\nJUSTIN: I'll have to take a look at that. \n\nMATT: It's funny --\n\nWILL: Anyway [inaudible 33:19], sorry.\n\nMATT: It's funny you say memory issues while talking about Ruby and Java is in the same sentence [laughs]. \n\nWILL: Well, I'm sorry, but, like, Java's [crosstalk 33:29] in ways that Ruby wasn't for a long time. \n\nJUSTIN: Java has gotten a lot better over the last couple of years. And Java has almost, I mean, the last three years, Java looked at Kotlin and stole the best parts of Kotlin. And so, all of a sudden, Java's, you know, picked up a lot of the nice things that Kotlin had, especially, like, the functional programming idiom. A lot of the null pointer exceptions have gone away, things like that.\n\nWILL: Did it get the coroutines? Did they pull the coroutines in? \n\nJUSTIN: I'd have to take a look, so...But, in any case, it'll be interesting to see how it goes forward, but, you know, they are recognizing, like, even if they were to stay in Ruby, I mean, we're currently on a monolith, and so going in that direction anyway we're breaking apart the microservices because we're growing the teams. We're growing the engineering teams. It just makes a lot more sense. And so, it's a natural breaking point anyway that we can move forward to the parent org desired architecture, desired language. \n\nMATT: Yeah, bottom line is we have to roll with the times, right? Unless we're the ones -- \n\nJUSTIN: That's very true. I'm glad you brought that up. It's like –- \n\nMATT: And unless we're the ones making these decisions, then we have to adapt, and that's just the bottom line. \n\nMIKE: If anybody is making the decision, though, don't go and destroy your teams and your precious goose that lays the golden egg. Don't do that [laughs].\n\nWILL: Well, I mean, like, you know, it's the classic, like, you know, the classic, like, joke, right? I mean, the difference between a heart surgeon and a car mechanic is the heart surgeon works on a car while it's running, you know. And similarly, like, you know, if you want to be an engineer working on this enterprise stuff, making them enterprise bucks, you don't get to do it the easy way. You have to do it the hard way, where you can maintain the uptime and you maintain, like, continuity. And you're working on the engine as it's turning. I mean, sorry, you know, like you wanted the big check; go and earn it, you know? Like [laughs], stuff's hard. \n\nAnd also, I'll say like, you know, I'll throw another bomb because, you know, I like stirring the pot. One of the more disastrous clinging to languages that I have seen has been in the Ruby community, where, like, people are trying to force Ruby onto, like, mobile apps, right? It's just not going to go. And some of that is not a technical thing, right? Like, it isn't that I don't think Ruby could make a perfectly, pleasant mobile application. It just won't be tolerated by the powers that be. \n\nAnd sort of people are just like, well, we're a Ruby shop. We might be the developers and maintainers of Rails. And we're committed to Ruby in a way that, like, is maybe slightly personal. And so, we're going to try and force our way onto the iPhone. And it ain't going to go like that, you know? Write some Swift; write some Kotlin; write some JavaScript, you know. It's going to be all right, guys. Sorry [laughs], you know. \n\nMIKE: Well, and [inaudible 36:46] example, you can back yourself into a corner. The recurring theme here is that, yeah, you got something new, build it in the language you want to do, the one that fits. Just don't destroy what you already have. But if you don't already have it, well, it's a really good time to reevaluate because those choices change over time [chuckles]. And, well, we're talking Ruby, so, you know, Ruby on Rails was really huge 20 years ago. Almost, not quite, but almost. \n\nWILL: God, yeah, almost. No, no, you're right. No, that math is correct. You really bum me out, Mike. [laughter] \n\nMATT: That really hurts.\n\nMIKE: And it's still got a solid community. Like, I'm not saying that Rails is going away anytime soon, but Python has taken over a lot of that space as a very similar language. And -- \n\nWILL: You really don't need both, you know? \n\nMIKE: Exactly. And so, you know, you've got to do some serious soul-searching. Maybe you've got some brilliant developers who are really good at what they're doing and, you know, stick with the language that works. But you better ask that question and think about how that question is going to be answered 5 years from now and ten years from now because you don't get that opportunity very often. Because once it's built, that's when you don't get to change it. \n\nWILL: Yep. Yeah, absolutely. \n\nJUSTIN: So, Stack Overflow, of course, does the Developer Survey every year. And so, there you can see the directionality of language usage. So, not necessarily that should make your decision for you, but it should be a consideration. And I'm looking here at Ruby. Let's see here. I'm trying to figure out. \n\nWILL: Share your screen I want to see. \n\nMIKE: Sorry, listeners, you don't get to see the screen. \n\nWILL: I can Google this. I have the Google. Like, I got the whole internet. Stack Overflow. What was the search? Like, language survey, is that right? \n\nJUSTIN: Developer Survey, yep. \n\nWILL: Yeah, Developer Survey. All right, 2023, let's see it. Oh man, here I go. Oof, yep, I see it. \n\nMATT: Python's, like, 30% right now. \n\nWILL: Yeah, Python's, wow. Oof, goes bigger. \n\nJUSTIN: So, here you have desired and admired. And I'm trying to think of...Rust is the most admired language, with more than 80% of developers want to use it and they want to use it again next year. Compare this to the least admired language, MATLAB [laughs]. I don't even know if MATLAB counts as a language. \n\nWILL: It sadly does. \n\nMIKE: It totally does. I've used...there's an open-source equivalent called Octave. I've used it before. It's actually very similar to the R language. Have you ever used R? \n\nJUSTIN: Yeah, I have. But the thing is, I've only ever used that in college, so... \n\nWILL: There's a lot of work that gets done, like, in MATLAB, like, big E engineering, like, type stuff, where you, like, do sort of, like, you know, anyway, yeah, it's a thing. It's a thing that does real work. It's for real. \n\nJUSTIN: Yeah. So, the way I read this is admired versus desired. So, a good example here is Rust. 85% admire Rust, and they want to continue to use it, versus 30% of people who aren't using Rust want to use it. So, it's like, once you start using Rust, you love it. But if you aren't a Rust person, you don't even know what's going on here, 30%. This one here, JavaScript, this one's a really short bar, you know, 40% desire it, but of those who are using it, only 60% want to continue to use it, so... \n\nWILL: I like the TypeScript one. That's the one I like. I'm looking at the same thing, right, where, like, people are just like, no, we really want to...Wait. So, desired versus admired, I'm curious. So, explain the difference between desire and admiration to me one more time because I think I missed something. I think I misinterpreted. \n\nJUSTIN: Okay, so the question itself was, \"Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year?\" So, you can answer twice, I guess. \n\nWILL: Okay. So...\n\nJUSTIN: So, which one are you using right now, and which one do you want to use next year? And then, they could be the same answer. \n\nWILL: Okay, so what do you want...something that you want to try and people who want to keep using it. Is that admirable? Like, I tried it, and I liked it is admired. And I want to try it is desired. Is that right? \n\nJUSTIN: So, desired is the second one. And admired means that you answered the same for both languages, I believe. \n\nWILL: Wait, no, because, like, have used it and want to continue. Admired is have used it and want to continue. And then, desired is, want to use. So, like, I want to try it versus I've tried it, and I want to keep going. So, that makes sense to me for Rust because, like, I came up programming nasty, old C. And, like –-\n\nJUSTIN: [laughs]\n\nWILL: Yeah, you could do better. You could do better, and later they did. And, like, a lot of C developers, you know, really want to keep the good parts of it. \n\nMATT: Look at that gap with Erlang.\n\nWILL: Erlang. I'm looking --\n\nJUSTIN: Erlang. Is it even on here? \n\nMATT: Just scroll down, yeah. [crosstalk 42:14]\n\nWILL: I see Elixir. \n\nJUSTIN: So, the people who use it generally admire it, but the people who have never used it don't list it as something that they want to use. \n\nMATT: And Elixir matches. \n\nWILL: I'm looking at C++ and C, and I just don't understand...those don't make sense to me [laughs]. What? Like, I don't get it. Is it people who are like, I'd like to learn how to program in C, and, like, people who want to keep going? I'm unclear what this is because --\n\nMATT: Those are your game programmers. \n\nWILL: Okay. \n\nJUSTIN: Is Unity in C, C#?\n\nMATT: Unity is C#. C#. That is where I learned to write code in C# is because of Unity because I wanted to start building some games. \n\nWILL: Interesting. \n\nJUSTIN: Nice\n\nWILL: I have never done any game programming. I feel like I'm the...well, not since I was in, like, high school, you know? \n\nMATT: It's a lot of fun. \n\nJUSTIN: So, unfortunately, I need to drop. But I suggest people take a look at this. I love this survey because it does help understand, like, here for web frameworks is, you know, the number one thing is React and then Node.js, Next.js, Vue.js. So, you mentioned earlier the JavaScript frameworks. \n\nMATT: Think about those top three as you use them all three together. \n\nJUSTIN: Yeah, you do use them all three together. And then, there's the folks who use Angular [laughs]. \n\nMATT: I felt really burned when I built out a huge application in Angular 1, and then [inaudible 43:56]\n\nJUSTIN: Oh yeah, and then Angular 2 is like a whole new language [laughs].\n\nMATT: Yep. Didn't even work.\n\nJUSTIN: Didn't even work.\n\nMIKE: Well, I think that we've reached a good kind of set of conclusions here, which is don't break it if you don't have to. But every time you refactor, which you should be doing, and you should be extracting things, it's a great opportunity to rethink what you're using today. And that's your opportunity. Use it while you have it. You know, it's don't miss the opportunity of a lifetime because you've missed the lifetime of the opportunity [laughs].\n\nMATT: Yep. [inaudible 44:33] \n\nJUSTIN: That's the first time I've heard that. I really like that. \n\nWILL: I still feel like Ruby has enough of a critical mass to make it viable. I think the people who love Ruby really, really love Ruby. They're really good programmers. Like, almost all really good programmers I know that have tried Ruby are like, \"Oh, I love Ruby. And, like, in the end, you know, I mean, like, and this is, like, purely personal bias, so I'm contradicting myself, like, rather severely, I know how to turn products around in Ruby really quickly, and if you can do it real fast, real well, you should not screw with it. \n\nBut, at the same time, like, I mean, like, everybody can see the direction the wind is blowing, and I wonder whether there's, like, an analogous, like, you know what I mean? I mean, like, what's the analogous, like, legacy language, you know what I mean, where it's like, it was good, and it had a hardcore community, but, like, we shouldn't have...like, what was it? Flash, you know what I mean? Like, can you compare it to Flash? \n\nMIKE: I think Ruby is more like Perl, where it's really good at its niche, and, you know, 20 years from now, people will still be using it, but it's just going to get smaller and smaller and smaller, and you're just going to have...well, I actually saw, like, a comparison once for cars, comparing programming languages to cars. And they said Perl was like an old Volkswagen bus. And I think it was Ruby or Python, it doesn't matter, is like a minivan [laughs], you know? It's the same basic thing, right? It solves the same purpose, and it fits in the same niche. It's going to be the same thing. I think that there's a lot of equivalence there. \n\nWILL: Yeah, I don't know, maybe I should learn Python, you know. Let's just switch over. I mean, it doesn't really matter. I mean, I don't know, I could [inaudible 46:34] really. I'm like, what's the difference between Python? Like, you've got, like, the significant white space, and, like, it's got...it's a little more typier. Is that right or wrong? \n\nMIKE: It's not really even all that typier, no. It's just...so; Ruby leans heavy into, you know, its block. So, anonymous functions are, like, central to the way the language works. So, you don't have loops in Ruby, you know, people don't do loops. It's all built in the language. So, it's very functional in that respect. But Python has much less of a language. It's just much less language. Python just tries to be pseudocode written down as code. So, it doesn't have all of these cool features that you get in Ruby, but it gets the job done. \n\nWILL: I don't know, maybe I should just do Kotlin, you know, just stinky, old Kotlin. Kotlin is fine. I've never done a web app in Kotlin. I just do, like, mobile apps. Anyway, sorry, a little bit of a tangent. We should wrap it up. You were trying to play us out, and I ruined it.\n\nMIKE: I was, but there we are. And I'm with you. I love Ruby. And if it's working for you, keep using it by all means. I'm not pushing back against that. Think about your environment that you're in. Make your choice when you can. \n\nWILL: But I've already abandoned them for, like, front-end stuff. Like, the way Rails is going with the frontend, I don't agree with it, and I don't have to use it, and I don't [laughs]. \n\nMATT: No, I'm not a fan of Rails frontend, personally, either. I love Ruby and Rails for APIs. You can work so quickly. It's nice. But is it the future? I guess we'll see. \n\nWILL: No, it's, I mean --\n\nMATT: I mean, that's not the future, is it? \n\nWILL: But that's the reason I'm so frustrated with it because, like, they're just sort of like, they're sort of like, they're digging in their heels. And they're just saying like, the thing that we were doing in 2005 when we came out...anyway, sorry, tangent. We can fight about this next week, maaaybe. \n\nMIKE: [laughs]\n\nWILL: But nothing needs to be said. Like, everybody knows the score with Rails, you know? \n\nMIKE: [inaudible 48:44] Thank you all, until next time on the Acima Development –\n\nWILL: See you guys. \n\nMATT: Thanks, guys. ","content_html":"In this episode of the Acima Development Podcast, the panel delves into the topic of changing programming languages in applications. They reflect on their experiences transitioning between languages like COBOL, Perl, PHP, and Ruby, highlighting the complexities and costs associated with such endeavors. They stress the difficulty of converting large, established applications to new languages due to the potential for high costs and disruptions, as exemplified by legacy applications still running on COBOL.
\n\nA significant part of the discussion revolves around the value and challenges of rewriting applications in new languages. Will presents a strong argument against rewriting code, citing examples where organizations have suffered due to poorly executed language transitions. The group agrees that the decision to switch should be driven by practical needs, such as performance improvements, scalability, or security, rather than the whims of new leadership or a desire for modernization. They also emphasize the importance of mentoring junior developers and avoiding language specialization that can lead to organizational inflexibility.
\n\nThe podcast concludes with reflections on the current trends and the future of programming languages, referencing the Stack Overflow Developer Survey. They note the rise of languages like Python and the enduring niche of Ruby. The hosts acknowledge that while modernizing or changing languages can sometimes be necessary, it should be approached with caution and clear rationale to avoid disrupting productive teams and established workflows. They suggest using opportunities like refactoring to evaluate and implement new languages gradually without jeopardizing existing systems.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm hosting today. I have with me Matt, Justin, and Will. We're happy to have Justin with us. So, Justin and Will are not Acima employees. They have been in the past. And it's great to have both of them with us to provide their insight in their current endeavors. Great having you back here, Justin.
\n\nJUSTIN: No problem. And I do have to say that I went from one Utah startup that is an A startup with five letters to another Utah startup that was an A startup with five letters.
\n\nMIKE: [laughs]
\n\nJUSTIN: Both of which were acquired by big corporations and both of which have interesting relationships with the parent corporation.
\n\n[laughter]
\n\nMIKE: Does it --
\n\nWILL: I know, like, one guy at a startup number two. I'm very curious. I'm very curious. Like, you know what I mean, I'm always curious about like, you know, the hot goss which we won't get into.
\n\nMIKE: Exactly.
\n\nWILL: I went from a Utah retailer to a big box electronics retailer, that one [laughter]. And, you know, it's a different environment.
\n\nMIKE: Well, and this is perfect. But today we're going to...I'm just going to jump straight to the topic today. We're going to talk about changing languages in your apps. Now, this applies in, you know, languages that you're doing, but we all have applications that have been around for a while on some languages, and, eventually, that doesn't work very well anymore.
\n\nNow, there are still applications out there in COBOL. I don't think that anybody says, you know, "I want to create an application in COBOL," [laughter] because it's a language that hasn't been actually [laughs] developed for, like, what, 50 years or something [laughs]? I don't know. I have to go look at exactly how long it's been since COBOL was, you know, like, a popular language.
\n\nBut you know what? There's still COBOL developers out there [laughs], and there's still COBOL applications out there. Because it is so hard to take a big working application and so expensive to convert that into a new language, which will itself eventually fall into disuse, and then you have to do it again. And, you know, the bigger the application, the more that costs.
\n\nMATT: ...Started my career.
\n\nMIKE: Did you? COBOL?
\n\nJUSTIN: COBOL?
\n\nMATT: Converting COBOL and FORTRAN applications to Perl and PHP web applications.
\n\nMIKE: Wow.
\n\nJUSTIN: Wow.
\n\nMIKE: To Perl. So, I wonder if that's happening. So, I was thinking about leading out...I thought, you know, I'm going to lead out with COBOL. But I thought about talking about my [laughs] first year as a professional developer, where I wrote in Perl, [laughs] right, you know, as well as other languages and, you know, comparing that. I'll say, I worked in Perl and then went away from it. I came back to Perl, and it was, like, starting from scratch [laughter]. It was a challenge.
\n\nMATT: I do still have some love for Perl, though.
\n\nMIKE: It's a cool language.
\n\nJUSTIN: [inaudible 03:24] as well on my first programming job, also.
\n\nMIKE: Oh.
\n\nJUSTIN: It was great.
\n\nMATT: PHP, not so much love, but...
\n\nJUSTIN: No, [inaudible 03:32] PHP.
\n\nWILL: I don't know, I like...like, Perl's, like, the Vi of, like, programming languages. I mean, like, in that, like, I could do it, but I never really got right with it. But I saw people who were, like, old, grizzled, wizard beards, sys admins just cooking on some, like, Perl scripts. And I was just like, okay, okay, like, this is, like...like, I'm seeing what's happening here, and I could recognize that, like, this is a power tool for, like, serious people to do serious work. This has utility.
\n\nMATT: You can accomplish a whole lot in Perl with very little code. It's the king of obfuscated code.
\n\n[laughter]
\n\nWILL: Ah, it is, yeah, yeah.
\n\nMIKE: Perl was the inspiration for the name of the Ruby programming language because they have a lot...
\n\nJUSTIN: Ooh.
\n\nMIKE: Yeah. Ruby would not be called Ruby if there had not been a Perl beforehand. But I got to say, when I started Ruby, it made sense, and that never went away [laughs]. Like, Ruby is like Perl, and it has still some weird Perlisms in it, if you go looking for them. It's like Perl intended to be easier to read.
\n\nWILL: Yeah, with an emphasis on sort of, like, readability, and, like, actually object orientation and stuff like that, yeah, completely. I got a hot take for this one, but I don't know whether anybody wants to get in here.
\n\nJUSTIN: So, I've got a hot take. I mean, I'm sure we all have hot takes for this one [laughs]. Why don't you go first? I have a good, lukewarm, and a bad experience, so three different experiences.
\n\nWILL: My hot take on, like, when should you rewrite your program in a new programming language is don't. Don't. I have seen...I don't even want to say 10 bad examples to 1 good example, you know what I mean? But I think it's actually even higher than that. And I have seen entire organizations, entire companies ruined with just this sort of thing. It's almost like an organizational anti-pattern, where you'll get some new hotshot CTO. He comes in. He has a tech stack that he favors. I say he; it could be a she, but it never is. It's always a dude with an ego and a tech stack, an area of expertise, a team of, like, people that he trusts.
\n\nJUSTIN: Yeah, and he brings --
\n\nWILL: And then, they come in like a bull in a China shop. They rewrite everything in their tech stack, bungle the job, screw up the product roadmap, and, like, take the entire organization down, you know what I mean? And then, he sails off in his golden parachute to do the exact same thing again. I recognize that, like, there are no such things as absolutes in engineering, but I am an overwhelming no. Absolutely no. Like, there's almost always ego, programmer laziness, and sloth.
\n\nI can't think of a language, a modern production language, that can't be reformed instead of replaced with 10 times less cost and a better outcome. Even PHP, which is a dog, gutter terrible language, has been remediated. It's fine. You can do PHP well now. You can do it, so do it. And, like, if you're a programmer that just doesn't want to learn another language, [inaudible 07:12]. Sorry. Like, I mean, it's laziness, sloth, and arrogance. Like, there's no...you know what I mean? Yeah, that's it. That's my hot take. Don't. If you want to do this, you're wrong. Don't do it.
\n\nMATT: So, you said a couple of things there. One, you used the word modern.
\n\nWILL: Yes. Important [inaudible 07:34].
\n\nMATT: I am wholeheartedly against the idea of modernization for the sake of modernization. If it's not broke, don't fix it. You know, we all face this. Everywhere we go, we face this, right? Some hot, new language comes into town these days. It's Node.
\n\nJUSTIN: Java.
\n\nMATT: And JavaScript backend.
\n\nMIKE: It's some new language that'll be transpiled into JavaScript. That's what it'll be [laughter].
\n\nMATT: Yes. Yes. And --
\n\nWILL: And has transpilers all the way down [laughs].
\n\nMATT: And everyone wants to jump on that bandwagon when they have a stable, expandable, scalable system.
\n\nJUSTIN: Okay, I've got one example where it worked, and that was in mobile, in the Android world. It was originally written in Java, and it still is in Java. About 2017, 2018, Kotlin came on the scene, and Google and JetBrains, no, IntelliJ, whatever, IntelliJ.
\n\nMIKE: JetBrains.
\n\nJUSTIN: They did it right. They were able to convert Java programmers over to Kotlin programmers. And they were able to convert codebases from Java to Kotlin with minimal issues. And it helped. I mean, there was a lot of things there about why it worked, but a couple of the main things that I could think of were that Kotlin, at the time, was just plain better than Java.
\n\nAnd then, two, Kotlin was compiled down into the JVM. And then, three, to convert a Java file to Kotlin, IntelliJ had a button that said, "Convert this Java file to Kotlin," and it converted it into working Kotlin. It may have been a little wordy, but it worked. And you can do that class by class. And it would work alongside the Java files and the Kotlin files. They would just work alongside. They were in the same codebase. And when you hit compile, it all worked.
\n\nMIKE: I've also seen a success story that's even different than that. It was a Java application. And this kind of goes back to Will's [laughs] saying before...the incoming people...it was an acquisition. The new people said, "You know what, we're not going to use Java anymore. We need to use a scripting language." And their preference was PHP. And this was a long time ago, but still [laughs].
\n\nWILL: Oh, man. Oh, oh.
\n\nMIKE: And I had been to a Java users' group where they had talked about Ruby on Rails and showed how, hey, you know, this is a, you know, a structured framework that is responsible and uses scripting language. You got to think about it. And so, I thought, you know what? This is old PHP, right? This is before all of those problems that you talked [laughs] about, Will, had been fixed. They were all still very much there. But I was like, you know, I like my life. I don't want it to go [laughter] in all sorts of bad directions.
\n\nSo, I went, like, in a weekend, I learned Ruby, wrote a prototype for the new version of this, and said, "How about we try this? It's already starting to work," and got them on board with trying this other, you know, language: Ruby. And we converted over. We ended up with one-tenth of the lines of code and more features.
\n\nMATT: I've had similar success. And when I said that, I didn't mean you should never do this, right? Because there is a time and a place. And one of our successes was a big PHP monolith into Ruby, so much better, so much cleaner. But there was reasoning behind why it happened, you know, new lines of business. It was in healthcare. So, we now needed to support claims and imports from health plans, EDI imports, and, you know, all sorts of things that the old system didn't do. And it justified, hey, it's time to version this and roll out a new system.
\n\nWILL: But I want to...hang on, I want to get in here because I do take your point, Justin, and I agree. And I have experienced the same thing with sort of, like, legacy JavaScript stuff moving over to TypeScript. However, I don't think those are rewrites. Those aren't rewrites. And I don't actually think they're new languages. I think Kotlin is just JavaScript 2.0, you know what I mean?
\n\nJUSTIN: Java 2.0.
\n\nWILL: Yeah, Java 2.0. Similarly, like, TypeScript is JavaScript, like, 1.1, right? Where, like, you have...no, well, you have strong interop. You had the same project. You had the same codebase. And you're just sort of like, I know that they're different languages for, I think, mostly legal reasons, you know what I mean? Like, there's two big organizations butting heads, and like, so, like, the Kotlin people just forked it, you know? TypeScript is the de facto standard. Like, TypeScript took over JavaScript. Like, I don't even think they should call it TypeScript anymore because if you're writing JavaScript-JavaScript, like, you should stop [laughs].
\n\nBut that's it. That's my point. Like, I agree, but I actually think it's more of a...that's more of an upgrade, you know what I mean? Like a major version upgrade of your programming language rather than, like, redoing it, you know what I mean? Subtle point, but yeah.
\n\nMATT: Now, there's ways also to approach this, right? You have a monolith. You decide you want to start extracting microservices. Perfect time. You know, maybe there's technologies that will support the job you're trying to accomplish better than what that monolith was written in for this particular task. And I think those things are super important, as well as how hard is it to find engineers for the languages you're supporting. That's a big one, right?
\n\nWILL: I think that's a mistake mostly in hiring, if I'm being direct. Being that, like...how do I put it? Like, I think if you're hiring engineers with language expertise, you're probably doing it wrong because I find, like, language expertise to be...for a good engineer, it's not that big of a deal. You're going to spend...it's a 10 to 1 ratio around learning the codebase, and the company, and the systems, and all that stuff, versus it's this much figuring out how things are done in Acima, and, like, this much learning Ruby. And Ruby is probably one of the hardest languages just because there's so much magic, you know what I mean, associated [crosstalk 14:30]
\n\nMATT: Yeah, I agree, when we're talking about senior engineers, right? I've always considered myself language agnostic because I don't care. I mean, I do care a little bit, right? I'm not going back to PHP. I'm just not. But when we're trying to mentor junior engineers, you're moving people over from other departments, that becomes a little more difficult, right? Because the learning curve is already pretty steep. When they start to get used to one language, to throw them into a new one, I think, provides more challenges.
\n\nWILL: Yeah, but they get more support.
\n\nMATT: Once you have some experience, absolutely, I agree, right?
\n\nWILL: I think it's more impactful on a junior engineer because it's like learning a different, like, human language, in that, like, you learn a different language, and you think in a different way, you know? You learn Ruby, and you think in a Ruby way. You learn JavaScript; you think in a JavaScript way. You learn nasty, old C, and you think, in, like, a different way, and you have a different perspective. I think for junior engineers, actually moving around in ecosystems is actually even more important because they'll learn better habits and they'll have more informed opinions.
\n\nI think when you have a junior engineer, God help them, right, that makes it through all the way through to senior without ever having sampled, you know, from a combo platter, that's when you get this sort of, like, senior people that are not language agnostic. And those are the people that come in because they don't know any better, and they're like, "This is all I'm good at. All I'm good at is .NET." So, you're a .NET shop now. And those people are dangerous.
\n\nMATT: Yeah, well, I agree with that. Point being, it becomes more difficult at that point, right? Because, as a company, we still have to focus on delivery, and it makes it harder to deliver. I agree. And we're all ADD, right? Every single engineer is ADD. We love to learn new things.
\n\nWILL: That's because engineering is boring [laughs].
\n\nMATT: We love to make things easier on us because we're lazy, and we're very inquisitive. So, we like to solve problems. I love learning new languages. It's one of my favorite things to do, just, you know, that exploration and experience of something new is awesome. But there are some challenges behind it.
\n\nJUSTIN: So, Will, you mentioned earlier about the refactoring. And, you know, Martin Fowler wrote the book on "Refactoring." One of the things I vaguely recall him talking about, when you are going in to refactor something, and that's basically what you're doing, is, when you're rewriting something in another language, you are deciding that you are going to refactor it, even if it is two totally different languages or as you say, Matt, like, you're changing...you got a monolith or something, and you have to break it apart. You have to identify the parts that you're going to move over to the new language and do that in an organized manner. And you have to be very cognizant and purposeful about what you are doing.
\n\nAnd those types of things mean that, I mean, help you, if you have to do this anyway, help you on your road to success. So, I don't know, big hot shot coming in and mandating stuff, sometimes you just have to go in and do what they say. And so, if you're going to do it, you might as well do it right. And that involves, you know, being an expert at refactoring and being very purposeful about it, so...
\n\nMIKE: You suggested something really interesting because if you extract out portions of an application by one, eventually, you know, you may end up with nothing of the original application because all the pieces have been extracted. So, you've refactored by breaking up into different services. And there was replacement, rather than rework, by extracting services. That's a way you can do this without actually rewriting the application, per se, so much as, hey, you know, this needs to be refactored enough. I'm going to rebuild this component. Once you've built enough components, eventually, the old codebase is gone. There's a kind of a strangulation technique, like a strangler fig. Eventually, the old --
\n\nJUSTIN: Yeah, yeah, exactly. And that's the example, the classic example, right? So...
\n\nWILL: Well, I mean, and I would also say, like, as I was thinking about it, like, I'm in JavaScript land now, right? And, like, one real serious problem with JavaScript land is framework fever. Man, like, that tribe of developers, they love a framework, God help them. And one thing that I encourage people who are, like, sort of, like, thinking about picking up a new framework to do is, if you want to grab a new framework, grab it as a refactor. Don't grab it for, like, the greenfield stuff. Grab it from, like, this old way, right, where, like, oh, I have this old thing. I'm going to refactor it using this new framework, this new idea, right?
\n\nBecause what people will so frequently try and do is they'll so frequently try and do, like, okay, well, we're going to do a new thing. And I want to play with my new toys. And we'll do both of them together, which I think is an exponential increase in complexity. And it makes it very difficult to discern whether it was a good idea in the first place, right?
\n\nMATT: Yep. You understand what the problem is if you're doing an extraction, right?
\n\nWILL: Yeah.
\n\nMIKE: And you can A/B comparison.
\n\nWILL: Yeah. Like, is this better, or is it worse? And you can also, like, how do I put it? Like, a lot of times, especially with new frameworks, like, you'll have, like, you won't have a lot of the grime that real-world long-term requirements sets entail. You know, like, you'll do it, and you'll do the simple version, right? Versus, like, the actual reality of like, okay, this is a complex line of business app, and a lot of stakeholders have a lot of asks for it.
\n\nAnd you'll sort of, like, you'll skip over all that stuff, you know, and you'll do the tutorial, like, the demo version of something, where it's just like, it's not going to be that simple, and especially for, you know, new, fancy frameworks that haven't been, you know, road tested for a long period of time. Like, a lot of that stuff, like, start getting into the details of like, oh no, I need this. I need this. The security team needs this thing.
\n\nAnd like, well, no, I mean, like, the security team, like, often, they will have asks, like, specific asks about like, "Oh no, I need...anytime you read this thing, I need a log. I need a log of who, you know, even read this document," crazy stuff like that, which, like, well, no, for financial stuff, like, that's for real. Like, I need that. I need, you know, I need to encrypt all this stuff on the server, you know, for whatever thing. You know, all kinds of requirements where it's just like, oh, this is the new, hot JavaScript library. But, like, grimy old Java, or, you know, crusty Ruby on Rails, like, they had to fight these battles already.
\n\nMATT: Yeah, I don't like change for the sake of change. I always want to know why. Why do you want to switch everything to Node and TypeScript, right? Is it for performance? Is it for concurrency? I don't think so. But you know what I'm saying? I would like to know the reason for these changes because, oftentimes, people are misled by hype. And you're making change simply for the sake of change. And I don't think that's healthy for anyone, especially not a company whose financials are at risk, you know?
\n\nWILL: Okay, so let me ask the counter, right? When is it a good idea to change? Let's say I had, you know, like, kind of a core piece of the company that was written in a programming language that was, you know, like, modern. It was current, but it was, like, say it was something like Haskell, right, where it's difficult to write. It's difficult to hire for. It doesn't offer, like, meaningful performance enhancements, and, like, the team is sort of, like, notably unproductive, right? You know what I mean? Like, when is it worth investing in, like, moving away from the thing, right? It's like, oh, I have COBOL written in the 1950s. Okay, that's an easy layout. That's fine.
\n\nMATT: Sure.
\n\nWILL: But, like, when does it start to make sense? When is it okay?
\n\nMATT: I think you just gave the wise with your question, right? Engineers are really hard to find. Team is unproductive in that language. It's hard to support. You can't move engineers from other teams to go support it, those types of things, right?
\n\nJUSTIN: Also, it's like, if it's an older language, all of a sudden, the community is not updating it. You know, I'm putting my security hat on here. They're not updating it for security fixes that are on there and, you know, especially, I've seen that with older libraries that are included in whatever language, right? You're depended upon this library, and, all of a sudden, there's a security hole there, and the community has gone on from that library or that language.
\n\nMATT: Absolutely. We run into that all the time with gem support, right?
\n\nJUSTIN: Yeah.
\n\nMATT: You start using these gems, and, all of a sudden, there's no longer support. Nobody's doing security patches. They're not being updated. And now you're stuck. Either you have to take over support of that gem, write your own, build it into your codebase, or find something different.
\n\nMIKE: What if you have, like, a super performant Haskell team that's knocking it out of the park? They've got a good connection to the university. You've got, like, a pipeline of people coming in where you don't have a problem. That would change the parameters of the equation, right?
\n\nJUSTIN: Yeah, totally.
\n\nMATT: Absolutely. Absolutely.
\n\nWILL: If I walked into a high-performing team in, I mean, nearly any language, if they were writing COBOL but it was working, everything was clicking, you know what I mean, like, it wasn't just maintenance mode, it's like we are writing modern COBOL and everything is kicking butt, like, I wouldn't change a thing. [crosstalk 24:57] I mean, I don't have a problem with Haskell, you know what I mean? I actually like Haskell. I've never seen it productive in practice, you know?
\n\nMATT: Well, you could throw any language, right?
\n\nWILL: Like, one of my favorite languages, one of my favorite languages in the world is, I programmed in, like, five years, is OCaml, right? It's object-oriented ML. It's a very...It was like Haskell or like ML if they were, you know, it was designed by people who were trying to get things done. It's [inaudible 25:29] native. It's really fast. It's like, you know what I mean? And it's practical. Like, you can just sort of like...you can downshift and just do some imperative programming and just get it done if you need to. There's one and only one company in the world that uses OCaml.
\n\nMIKE: Jane Street Capital [laughs]?
\n\nWILL: Jane Street Capital. [inaudible 25:48]. OCaml wouldn't even exist outside of academia if it wasn't for Jane Street. But, like, it works. It works. Should anybody else use OCaml? Probably no. Like, I love it, but I would not advocate anybody to pick it up for anything, ever, you know.
\n\nMATT: You said something that I think is really important and that is, you wouldn't disrupt any team that is productive, just meshes, clicks, and gets things done, and meets business needs. However, we see it far too often. Back to your first example, some new hotshot comes in says, "Hey, we're going to start using this language. We're going to change everything. Turn your world upside down."
\n\nWILL: I'm a consultant. I will come in, and I will write this platform for you, but I'll only do it if you let me do it in Haskell.
\n\n[laughter]
\n\nJUSTIN: Well, going back to the situation I'm in right now –-
\n\nWILL: I might get emails for this. I know I am.
\n\n[laughter]
\n\nJUSTIN: So, the company I'm working for right now was acquired by a big bank, which is a Java shop, and they were acquired in 2023. They came in and dictated the Ruby application, which made the company, the startup company, the money, and made it all attractive; they dictated that, hey, this needs to be rewritten in Java.
\n\nMIKE: Oh wow.
\n\nJUSTIN: And they spent six months trying to do that. You know, there were zero Java engineers. And the big company did not want to give the resources or, you know, provide the expertise and the guidance and everything. Six months later, they said, "We're not doing it. You guys –- "
\n\nWILL: Who said it?
\n\nJUSTIN: The company, the smaller company that got acquired they, said, "If you want us to keep on making new features and everything and, you know, improving this product, we can't convert this to Java like you want us to. We got to stick on our platform that we want, I mean, that we're on, that we have the expertise on, that we have the, you know, the domain knowledge and everything." And, you know, so, basically, six months of development time went down the drain. Luckily, all that happened before I got there.
\n\nMIKE: [laughs].
\n\nWILL: That, like, I mean, so I guess the big question is, like, you know, what is the big bank going to do? I mean, because, like, you know what I mean? And so, the dangerous part about it is like, that's such a transparently bad idea, right?
\n\nJUSTIN: Yeah.
\n\nWILL: You've got technical requirements that, like, a Ruby on Rails application cannot achieve, right? Then, okay. But if you're just sort of, like, saying it just to say it, like, you are already making bad engineering decisions, right? And, like, are these guys going to be able to turn the corner and say, like, "Oh, I'm sorry. We were wrong"? You know what I mean? Like I said, risky thing to do. And if the big bank had the flexibility to say, like, "Okay, okay, okay, just do your thing then," I mean, [inaudible 28:56]. We all make mistakes. It takes a lot to learn from them. I'd say that's bleeding edge, big bank agility, and flexibility.
\n\nJUSTIN: It was, and they accepted it. And they said, "Okay, you guys can come in as you are." They have to come into the environment, right? And then, they were like, "Okay, if you come in, though, you do have to use our compliance framework and everything like that." And we have to add support for Ruby, which wasn't there before. And so, all of that is a pain, but it's all doable. And it's all fitting within the, you know, within the existing architecture, so...
\n\nWILL: And I'd say, well, I'd say, like, it's interesting to me, right? So, okay. So, let's get you in trouble at work, right? So, here's the question that I've got, right? So, all right. You've got Ruby on Rails app, you know what I mean? It is functioning. However, right, it's the odd man out. It's through an acquisition, and you're doing stuff differently from the rest of the bank, you know what I mean? Like, you know, it's an acquisition. It wasn't a merger. Like, Daddy is using Java, and you're using Ruby. And that means you are wrong, not them, right? Because you're swimming against the current, against this entire big bank, and it puts you on an island, right?
\n\nJUSTIN: It does.
\n\nWILL: And you're in Salt Lake City. You're not in New York. You're in Ruby. You're not in Java, right? Like, I think it is incumbent on sort of like, you know what I mean, like...and, like, there are advantages to it as well, you know what I mean? Because you want to be able to have this interoperability, this interactivity with the rest of the organization. Like, how do you, as the smaller party, how do you integrate into the larger thing?
\n\nJUSTIN: So, I'm glad you mentioned that because there is an initiative, and they have hired a few Java engineers to do microarchitecture, the microservice architecture. And so, they are moving over...I'm a little unclear if it's, like, net new or existing functionality, but they are going to be moving piece by piece things over to Java. But it is down low on the priority queue.
\n\nOur number one thing on the priority queue is, you know, continued growth, which is one of the reasons why the bank bought us. And the continued growth, and the new features, and everything there, all that, where we can serve our customers, is all still in Ruby. And so, it's a separate small team that are doing very clearly defined success story, you know, microarchitecture success goalposts that they could focus on. And then, they'll move piece by piece over to that. And, all of a sudden, our timeline actually went from, "Hey, you have to do this in the next six months," to, "Hey, you've got a couple of years."
\n\nWILL: Well, I mean, not for nothing. I actually, like, sort of, like, I don't know whether you guys are doing this at all, but, like, there is JRuby. There's JVM-compatible Ruby. Like, you can run in the JVM. The JVM can sort of, like, swallow you whole, like, with sort of, like, Java interop. And you can start, like, shading off routines, shading off business logic, you know what I mean? Like, I have moved away from JRuby because, like, it was kind of a lot of work to make it go.
\n\nI had an application that ran on JRuby in olden times because, like, the JVM had, like, kind of...I don't want to say the bad, old days of Ruby but, like, bad-er days of Ruby when, like, there were kind of memory stuff and scalability issues. Ruby's been working on it for a while, but, like, it was a hobbyist thing that kind of blew up. And there were funkiness. There was, you know what I mean, like, memory management, especially Ruby had some real issues, you know what I mean. And so, I was restarting a lot of servers a lot of the time.
\n\nMATT: It's funny [laughs] --
\n\nWILL: And so, JRuby is in there, you know, and you can have that call an in interop. You're not going to be able to just push a button and [laughs] convert the file. But, like, you can call...if you can get over to it, you can call Java, you know, from Ruby, you know, pretty sleek.
\n\nJUSTIN: I'll have to take a look at that.
\n\nMATT: It's funny --
\n\nWILL: Anyway [inaudible 33:19], sorry.
\n\nMATT: It's funny you say memory issues while talking about Ruby and Java is in the same sentence [laughs].
\n\nWILL: Well, I'm sorry, but, like, Java's [crosstalk 33:29] in ways that Ruby wasn't for a long time.
\n\nJUSTIN: Java has gotten a lot better over the last couple of years. And Java has almost, I mean, the last three years, Java looked at Kotlin and stole the best parts of Kotlin. And so, all of a sudden, Java's, you know, picked up a lot of the nice things that Kotlin had, especially, like, the functional programming idiom. A lot of the null pointer exceptions have gone away, things like that.
\n\nWILL: Did it get the coroutines? Did they pull the coroutines in?
\n\nJUSTIN: I'd have to take a look, so...But, in any case, it'll be interesting to see how it goes forward, but, you know, they are recognizing, like, even if they were to stay in Ruby, I mean, we're currently on a monolith, and so going in that direction anyway we're breaking apart the microservices because we're growing the teams. We're growing the engineering teams. It just makes a lot more sense. And so, it's a natural breaking point anyway that we can move forward to the parent org desired architecture, desired language.
\n\nMATT: Yeah, bottom line is we have to roll with the times, right? Unless we're the ones --
\n\nJUSTIN: That's very true. I'm glad you brought that up. It's like –-
\n\nMATT: And unless we're the ones making these decisions, then we have to adapt, and that's just the bottom line.
\n\nMIKE: If anybody is making the decision, though, don't go and destroy your teams and your precious goose that lays the golden egg. Don't do that [laughs].
\n\nWILL: Well, I mean, like, you know, it's the classic, like, you know, the classic, like, joke, right? I mean, the difference between a heart surgeon and a car mechanic is the heart surgeon works on a car while it's running, you know. And similarly, like, you know, if you want to be an engineer working on this enterprise stuff, making them enterprise bucks, you don't get to do it the easy way. You have to do it the hard way, where you can maintain the uptime and you maintain, like, continuity. And you're working on the engine as it's turning. I mean, sorry, you know, like you wanted the big check; go and earn it, you know? Like [laughs], stuff's hard.
\n\nAnd also, I'll say like, you know, I'll throw another bomb because, you know, I like stirring the pot. One of the more disastrous clinging to languages that I have seen has been in the Ruby community, where, like, people are trying to force Ruby onto, like, mobile apps, right? It's just not going to go. And some of that is not a technical thing, right? Like, it isn't that I don't think Ruby could make a perfectly, pleasant mobile application. It just won't be tolerated by the powers that be.
\n\nAnd sort of people are just like, well, we're a Ruby shop. We might be the developers and maintainers of Rails. And we're committed to Ruby in a way that, like, is maybe slightly personal. And so, we're going to try and force our way onto the iPhone. And it ain't going to go like that, you know? Write some Swift; write some Kotlin; write some JavaScript, you know. It's going to be all right, guys. Sorry [laughs], you know.
\n\nMIKE: Well, and [inaudible 36:46] example, you can back yourself into a corner. The recurring theme here is that, yeah, you got something new, build it in the language you want to do, the one that fits. Just don't destroy what you already have. But if you don't already have it, well, it's a really good time to reevaluate because those choices change over time [chuckles]. And, well, we're talking Ruby, so, you know, Ruby on Rails was really huge 20 years ago. Almost, not quite, but almost.
\n\nWILL: God, yeah, almost. No, no, you're right. No, that math is correct. You really bum me out, Mike. [laughter]
\n\nMATT: That really hurts.
\n\nMIKE: And it's still got a solid community. Like, I'm not saying that Rails is going away anytime soon, but Python has taken over a lot of that space as a very similar language. And --
\n\nWILL: You really don't need both, you know?
\n\nMIKE: Exactly. And so, you know, you've got to do some serious soul-searching. Maybe you've got some brilliant developers who are really good at what they're doing and, you know, stick with the language that works. But you better ask that question and think about how that question is going to be answered 5 years from now and ten years from now because you don't get that opportunity very often. Because once it's built, that's when you don't get to change it.
\n\nWILL: Yep. Yeah, absolutely.
\n\nJUSTIN: So, Stack Overflow, of course, does the Developer Survey every year. And so, there you can see the directionality of language usage. So, not necessarily that should make your decision for you, but it should be a consideration. And I'm looking here at Ruby. Let's see here. I'm trying to figure out.
\n\nWILL: Share your screen I want to see.
\n\nMIKE: Sorry, listeners, you don't get to see the screen.
\n\nWILL: I can Google this. I have the Google. Like, I got the whole internet. Stack Overflow. What was the search? Like, language survey, is that right?
\n\nJUSTIN: Developer Survey, yep.
\n\nWILL: Yeah, Developer Survey. All right, 2023, let's see it. Oh man, here I go. Oof, yep, I see it.
\n\nMATT: Python's, like, 30% right now.
\n\nWILL: Yeah, Python's, wow. Oof, goes bigger.
\n\nJUSTIN: So, here you have desired and admired. And I'm trying to think of...Rust is the most admired language, with more than 80% of developers want to use it and they want to use it again next year. Compare this to the least admired language, MATLAB [laughs]. I don't even know if MATLAB counts as a language.
\n\nWILL: It sadly does.
\n\nMIKE: It totally does. I've used...there's an open-source equivalent called Octave. I've used it before. It's actually very similar to the R language. Have you ever used R?
\n\nJUSTIN: Yeah, I have. But the thing is, I've only ever used that in college, so...
\n\nWILL: There's a lot of work that gets done, like, in MATLAB, like, big E engineering, like, type stuff, where you, like, do sort of, like, you know, anyway, yeah, it's a thing. It's a thing that does real work. It's for real.
\n\nJUSTIN: Yeah. So, the way I read this is admired versus desired. So, a good example here is Rust. 85% admire Rust, and they want to continue to use it, versus 30% of people who aren't using Rust want to use it. So, it's like, once you start using Rust, you love it. But if you aren't a Rust person, you don't even know what's going on here, 30%. This one here, JavaScript, this one's a really short bar, you know, 40% desire it, but of those who are using it, only 60% want to continue to use it, so...
\n\nWILL: I like the TypeScript one. That's the one I like. I'm looking at the same thing, right, where, like, people are just like, no, we really want to...Wait. So, desired versus admired, I'm curious. So, explain the difference between desire and admiration to me one more time because I think I missed something. I think I misinterpreted.
\n\nJUSTIN: Okay, so the question itself was, "Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year?" So, you can answer twice, I guess.
\n\nWILL: Okay. So...
\n\nJUSTIN: So, which one are you using right now, and which one do you want to use next year? And then, they could be the same answer.
\n\nWILL: Okay, so what do you want...something that you want to try and people who want to keep using it. Is that admirable? Like, I tried it, and I liked it is admired. And I want to try it is desired. Is that right?
\n\nJUSTIN: So, desired is the second one. And admired means that you answered the same for both languages, I believe.
\n\nWILL: Wait, no, because, like, have used it and want to continue. Admired is have used it and want to continue. And then, desired is, want to use. So, like, I want to try it versus I've tried it, and I want to keep going. So, that makes sense to me for Rust because, like, I came up programming nasty, old C. And, like –-
\n\nJUSTIN: [laughs]
\n\nWILL: Yeah, you could do better. You could do better, and later they did. And, like, a lot of C developers, you know, really want to keep the good parts of it.
\n\nMATT: Look at that gap with Erlang.
\n\nWILL: Erlang. I'm looking --
\n\nJUSTIN: Erlang. Is it even on here?
\n\nMATT: Just scroll down, yeah. [crosstalk 42:14]
\n\nWILL: I see Elixir.
\n\nJUSTIN: So, the people who use it generally admire it, but the people who have never used it don't list it as something that they want to use.
\n\nMATT: And Elixir matches.
\n\nWILL: I'm looking at C++ and C, and I just don't understand...those don't make sense to me [laughs]. What? Like, I don't get it. Is it people who are like, I'd like to learn how to program in C, and, like, people who want to keep going? I'm unclear what this is because --
\n\nMATT: Those are your game programmers.
\n\nWILL: Okay.
\n\nJUSTIN: Is Unity in C, C#?
\n\nMATT: Unity is C#. C#. That is where I learned to write code in C# is because of Unity because I wanted to start building some games.
\n\nWILL: Interesting.
\n\nJUSTIN: Nice
\n\nWILL: I have never done any game programming. I feel like I'm the...well, not since I was in, like, high school, you know?
\n\nMATT: It's a lot of fun.
\n\nJUSTIN: So, unfortunately, I need to drop. But I suggest people take a look at this. I love this survey because it does help understand, like, here for web frameworks is, you know, the number one thing is React and then Node.js, Next.js, Vue.js. So, you mentioned earlier the JavaScript frameworks.
\n\nMATT: Think about those top three as you use them all three together.
\n\nJUSTIN: Yeah, you do use them all three together. And then, there's the folks who use Angular [laughs].
\n\nMATT: I felt really burned when I built out a huge application in Angular 1, and then [inaudible 43:56]
\n\nJUSTIN: Oh yeah, and then Angular 2 is like a whole new language [laughs].
\n\nMATT: Yep. Didn't even work.
\n\nJUSTIN: Didn't even work.
\n\nMIKE: Well, I think that we've reached a good kind of set of conclusions here, which is don't break it if you don't have to. But every time you refactor, which you should be doing, and you should be extracting things, it's a great opportunity to rethink what you're using today. And that's your opportunity. Use it while you have it. You know, it's don't miss the opportunity of a lifetime because you've missed the lifetime of the opportunity [laughs].
\n\nMATT: Yep. [inaudible 44:33]
\n\nJUSTIN: That's the first time I've heard that. I really like that.
\n\nWILL: I still feel like Ruby has enough of a critical mass to make it viable. I think the people who love Ruby really, really love Ruby. They're really good programmers. Like, almost all really good programmers I know that have tried Ruby are like, "Oh, I love Ruby. And, like, in the end, you know, I mean, like, and this is, like, purely personal bias, so I'm contradicting myself, like, rather severely, I know how to turn products around in Ruby really quickly, and if you can do it real fast, real well, you should not screw with it.
\n\nBut, at the same time, like, I mean, like, everybody can see the direction the wind is blowing, and I wonder whether there's, like, an analogous, like, you know what I mean? I mean, like, what's the analogous, like, legacy language, you know what I mean, where it's like, it was good, and it had a hardcore community, but, like, we shouldn't have...like, what was it? Flash, you know what I mean? Like, can you compare it to Flash?
\n\nMIKE: I think Ruby is more like Perl, where it's really good at its niche, and, you know, 20 years from now, people will still be using it, but it's just going to get smaller and smaller and smaller, and you're just going to have...well, I actually saw, like, a comparison once for cars, comparing programming languages to cars. And they said Perl was like an old Volkswagen bus. And I think it was Ruby or Python, it doesn't matter, is like a minivan [laughs], you know? It's the same basic thing, right? It solves the same purpose, and it fits in the same niche. It's going to be the same thing. I think that there's a lot of equivalence there.
\n\nWILL: Yeah, I don't know, maybe I should learn Python, you know. Let's just switch over. I mean, it doesn't really matter. I mean, I don't know, I could [inaudible 46:34] really. I'm like, what's the difference between Python? Like, you've got, like, the significant white space, and, like, it's got...it's a little more typier. Is that right or wrong?
\n\nMIKE: It's not really even all that typier, no. It's just...so; Ruby leans heavy into, you know, its block. So, anonymous functions are, like, central to the way the language works. So, you don't have loops in Ruby, you know, people don't do loops. It's all built in the language. So, it's very functional in that respect. But Python has much less of a language. It's just much less language. Python just tries to be pseudocode written down as code. So, it doesn't have all of these cool features that you get in Ruby, but it gets the job done.
\n\nWILL: I don't know, maybe I should just do Kotlin, you know, just stinky, old Kotlin. Kotlin is fine. I've never done a web app in Kotlin. I just do, like, mobile apps. Anyway, sorry, a little bit of a tangent. We should wrap it up. You were trying to play us out, and I ruined it.
\n\nMIKE: I was, but there we are. And I'm with you. I love Ruby. And if it's working for you, keep using it by all means. I'm not pushing back against that. Think about your environment that you're in. Make your choice when you can.
\n\nWILL: But I've already abandoned them for, like, front-end stuff. Like, the way Rails is going with the frontend, I don't agree with it, and I don't have to use it, and I don't [laughs].
\n\nMATT: No, I'm not a fan of Rails frontend, personally, either. I love Ruby and Rails for APIs. You can work so quickly. It's nice. But is it the future? I guess we'll see.
\n\nWILL: No, it's, I mean --
\n\nMATT: I mean, that's not the future, is it?
\n\nWILL: But that's the reason I'm so frustrated with it because, like, they're just sort of like, they're sort of like, they're digging in their heels. And they're just saying like, the thing that we were doing in 2005 when we came out...anyway, sorry, tangent. We can fight about this next week, maaaybe.
\n\nMIKE: [laughs]
\n\nWILL: But nothing needs to be said. Like, everybody knows the score with Rails, you know?
\n\nMIKE: [inaudible 48:44] Thank you all, until next time on the Acima Development –
\n\nWILL: See you guys.
\n\nMATT: Thanks, guys.
","summary":"","date_published":"2024-07-24T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/88f5e20f-63ed-4cbf-a84a-0a8fd8dfcd81.mp3","mime_type":"audio/mpeg","size_in_bytes":28727162,"duration_in_seconds":2943}]},{"id":"caa15d67-67dc-4a20-8c07-1347f6487c2c","title":"Episode 50: Onboarding","url":"https://acima-development.fireside.fm/50","content_text":"In this episode of the Acima Development Podcast, host Mike starts by sharing an anecdote about his three-year-old son, emphasizing the importance of guidance and support in learning. This sets the stage for a discussion on onboarding new employees, highlighting the similarities between guiding a child and mentoring new hires. Mike notes that new employees, like his son, have potential but require proper guidance to become productive members of the team.\n\nThe discussion then delves into various strategies for successful onboarding. Matt praises Mike's analogy and underscores the importance of mentorship and guidance for new employees. Eddy adds that providing the right tools and environment allows new hires to realize their potential. The group agrees on the significance of assigning buddies to new employees and promoting a supportive culture where asking questions is encouraged. This not only helps new hires learn faster but also fosters a collaborative environment. They also stress the importance of documentation and how it can be a valuable resource for new employees when mentors are not available.\n\nTowards the end, the conversation shifts to the role of tools and technology in onboarding. The hosts discuss the benefits of standardizing tools to streamline workflows and make the onboarding process more efficient. They also touch on the challenges of remote work and how it can impact the onboarding experience. The episode concludes with a reminder that onboarding is not just about processes and tools but also about building trust and relationships. By treating new hires with humanity and fostering a culture of openness and support, companies can ensure a successful and smooth onboarding experience!\n\nTranscript:\n\n MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm hosting today. And with me, we've got Eddy, Ramses, and Matt. \n\nAnd I'm actually going to start today by talking about my family. I have a three-year-old, and [chuckles] he is very much three years old [laughs]. He is figuring things out, and sometimes, he does the wrong thing, like chasing you around and hitting you with a stick. Like, no, that's the wrong thing to do [laughs]. And you tell him that, and he'll be upset and think that you're trying to hurt his feelings. Like, no, I love you. I just don't want to get hit by a stick [laughs]. \n\nAnd, you know, three years ago, he just laid there and cried if he was hungry, right [laughs]? He had a lot of abilities, but none of them were developed at all. And I honestly don't expect him to be a contributing member of society for another 15 years [laughs]. And that's pretty normal because that's true for all of us. We all get this start, you know, we've got this potential, but not really any knowledge about the situation and got to figure out as we go. And it takes a long time before we're productive. \n\nI mention this because today, we're going to talk about onboarding new employees. And, hopefully, you're not putting your three-year-olds or your infants to work [laughs]. But we all start, to some degree, you know, in ignorance. You know, we come into a new job and there's a lot of stuff we don't know. We have a ton of potential, but there's so much that we don't know and things we don't even know we don't know that make it very hard to get up to speed. \n\nAnd, you know, depending on how well that onboarding process goes, depending on how much support is given to those new employees, it may take them a fairly short period of time to get up to speed or...hopefully, not 18 years [laughs], but it can take a while. I mentioned the support they get, and that's something we can influence. To some degree, there's also the intrinsic complexity of the systems that we're working with that we don't control. There are some things we can do, you know, we can do refactoring, try to improve our systems, but, you know, some problems are hard, and it's going to take people a while to get up to speed. These are real problems, and they're worth talking about. \n\nAnd that's our topic for discussion today is, how do we onboard? It's also timely because we've got some interns starting on Monday, and we'd really like to give them the support that they need to quickly get up to speed. Now, I have some thoughts about the things that are most important for helping somebody in their onboarding, but I'd like to open the floor. What do you all think about what's important for helping people do that onboarding? \n\nMATT: I'd first like to say you are always so great with your segues and analogies because this one makes perfect sense, right? You have a three-year-old who is learning as he goes. And would he probably figure out life on his own? Yeah, eventually. But without your guidance and without some leadership, it would take much, much longer than it would instead of you providing it for him, right? And I think that's kind of what we have to look at when onboarding new employees, whether it be new to the company, new to a role, or switching departments, you know, any of those things. I think everyone requires a little bit of instruction and guidance until they get up to speed. \n\nMIKE: Absolutely. \n\nEDDY: You mentioned individuals having potential but not the right guidance, kind of paraphrasing a little bit. And any individual that you hire, you interview, and you say, \"Yeah, this person's got the right attitude. They got potential,\" but if you expect this person to hit the ground running, they're going to fall over, or they're going to drown. If you're patient and you provide the right reinforcements, and the right help, and tools, utility, et cetera, the person will grow into their own, and they will show you what you perceived during the interview.\n\nI'd like to believe that some of the individuals who are engineering now are showing that on a day-by-day basis, right? Individuals, you know, who were ambitious, you know, who had the courage, you know, to push forward and be given the opportunity to do that shift in career have now been able to provide all that throughput, you know, that was initially observed during the interview. So, I think that so long as you do provide the patience and the right atmosphere, people will grow into their own, and they will surprise you. \n\nMIKE: I can say that's true of you, Eddy [laughs]. You've done amazing work. And, honestly, I would say that's true of each of you. I know many of you listening are like, oh, I don't care about that. I do. I'm going to call it out publicly. I'm working with three people that I'm very happy to be working with. \n\nMATT: And I second that. One of the things that I think is really important and maybe sometimes we overlook when we're onboarding people is that in this process, we can also empower them to be mentors and help them be able to onboard the next people that come on. And I've found, at least throughout my career, that one of the important things as the mentee or new person being onboarded is to ask questions and not be afraid to ask those questions. And as mentors, we can help guide that with our new people and encourage that. That can go a long way. \n\nMIKE: I think that culture does make a huge difference. If you shut down any question quickly, there's not going to be very many more questions, and you do a lot of harm. Back to the three-year-old, you know what three-year-olds do? They ask questions. \"What's this? What's this? What's that? What's this? What's this [laughs]?\" And you can shut that down and not respond. And the result is that curiosity will be lost, and that's an awful outcome. You wouldn't want it to happen to your three-year-old. I don't think you want it to happen to your new employee, either. That curiosity is probably a lot of why you want them there—is that hunger to grow. \n\nMATT: Yeah, and it creates isolation if you do shut it down. As annoying as those \"What's this?\" questions might be, that's how they're learning, and that's how they're gathering all this new information. And will they retain all of it at once? Probably not. But that's why they need to continue asking these questions. \n\nYou know, I've been in the industry forever now, but here with the company, I'm in a new role, and Mike is present in most of the meetings I am. And I am one of those people who's always asking questions. And it may feel a little disruptive at times, but I try to ask the question once and remember those things so I don't have to again, and that way, if someone asks me about those same things, I have the answers for them. \n\nEDDY: Can I say how much talent it takes to understand something that's been directed to you the very first time [laughs]? I will have the individual reiterate three different ways for me to really understand that before they say, \"Do you get that?\" \"Yeah, yeah, I get that [laughs].\" \n\nMIKE: Okay, so let's talk about that. So, going, you know, with the analogy we've got here, this morning, my toddler asked me, \"What's this?\" And he was pointing at a cell phone tower. And I said, \"It's a cell phone tower [laughs].\" And he now has, like, some label for it that he's probably going to forget [laughs], and that's probably about all he has. He has no concept of what's going on there. He's three. I'm not going to explain to him electromagnetic radiation and, you know, low-frequency waves that can travel through a lot of distance and through even solid materials sometimes, and how those resonate with your antennas. \n\nI can just say, \"That's a tower,\" right? If you don't have something to hold that information onto, to kind of pin it to, it's like trying to remember 20 numbers in a row. You're not going to remember it. Your brain won't do that. You can only hold about seven. But if you have that narrative, if you actually have the story, you have something to pin it to. So, you're going to need somebody to repeat and repeat and repeat with greater depth each time. Because the first time, you might, if you remember it, learn the name. The second time, maybe you have a little more story around it, and so on. And with each iteration, you're going to internalize more information. \n\nMATT: Yeah, and let's face it, when you're starting somewhere, you're drinking from a fire hose, and you definitely can't retain everything that you're being told. You know, you just have to try and pick the things that you think are important and hold on to those, and maybe they aren't the right thing sometimes. But you're right; things do take more than once to really ingrain. \n\nEDDY: In order for me to reassure myself that I've been able to internalize something new, I try to explain it to someone else who has no context, right? I read this article a few weeks ago that basically says if you're having a hard time explaining it or dumbing it down, you probably don't understand it. And so, I've gotten into the habit I'm like, oh yeah, cool, I think I get it. But let me try to explain it to someone else and see if they can at least get the concept of what it is. It has done wonders because if I'm able to be like, oh, huh, wait, I don't know if I'm sure about this analogy; let me just make sure, it really harps that ideology down. \n\nMATT: Yeah, if you want a better understanding of something, teach it. And you're probably going to pick up something along the way while you are. \n\nMIKE: Absolutely, and that connects back to the onboarding. One thing I found, so kind of the first tactic I'm going to throw out here that I have found to be extremely helpful for onboarding, is to pair people together who are starting at the same time or starting near the same time. If somebody started three months ago, they have everything fresh in their head. And they're going to be able to probably more easily help the person who just started than actually somebody who's been there a long time. And it has the added benefit is now they're explaining it. Now, they're finding where the gaps are and deepening their understanding. \n\nAnd if people are starting at the same time, it's kind of a back-and-forth, right? It's this pairing that allows them to do that, you know, in a very tight loop with each other, and it works out really well. There's another tactic I'm going to get to in a minute. But I think that that's one of the most helpful things I've seen is to pair people together who have started at around the same time. Have you all seen that to be similarly effective? \n\nMATT: Yeah, absolutely. And each of them are going to retain different things. So, if you have them together...in fact, we are just going through this on one of my teams. I have two new hires, and it worked out that I could start them both the same day; much, much easier that way because then they can work off each other, as well as it frees up some of our engineering time, right, to be able to do that with two people at once. But it's a much broader conversation when you have three people involved versus two. \n\nMIKE: So, in short, it works, right [laughs]? Put people together. You know, to bring up another tactic that I've found is extremely valuable, is give somebody a buddy. Give whoever is coming in an assigned buddy. Like, \"You, this is your friend [laughs], and you're going to work with them.\" In the absence of that, people don't know who to ask, right? You're like, well, I should ask somebody, and they'll go and try to ask whoever they saw first because [inaudible 12:22] familiar face. You don't know who to talk to. And you can go talk to the person next to you, like, oh, I don't know, right [laughs]? And then, you drop right into that isolation. You need to have a line of contact, somebody that you can ask.\n\nNow, they may not be the right person to answer your question, but they can point you to the person who can answer that. They can point to the documentation. They can bring you down to IT to get you a new laptop. You know, having somebody have a person is just one of the most important things I've seen.\n\nI think I mentioned in a podcast, a recent podcast that we were on, I remember a job I had over 20 years ago, comfortably over 20 years ago now, well over 20 years ago, where I was doing some construction work. And my first day, they set me up with somebody else, and there were some language challenges. We didn't understand each other very well at first, well, mostly me not understanding [laughs] him very well. This was in Louisiana, and he had a French background, but we still communicated. And, man, having that buddy made such a difference. It made such a difference. And pretty soon, I was able to understand. And we worked well together. I learned the ropes, and we actually got to be really close friends. \n\nRAMSES: Do you speak French now, too, Mike? \n\nMIKE: Not a word [laughs]. Well, probably a word but not meaningfully [laughs]. \n\nEDDY: How's your Spanish? \n\nMIKE: Not a paid promotion, but I use Duolingo, and it has been helping. I've been studying Duolingo for almost four years daily. \n\nRAMSES: Oh, nice. \n\nMIKE: It has been very beneficial. I can read Spanish pretty well now. \n\nMATT: I do love that we can practice those languages here at this company. I've been trying because I went so long without speaking any Spanish, and Eddy and a number of the other team members have really helped out with that. \n\nEDDY: To be fair, this is a side [inaudible 14:11], but I've always associated programming terminology in English. And I've never once thought, huh, how do I say array in Spanish, right [laughter]? So, like, I can say everything else except array, and I'm like, oh, man, how do you say that, right? But, like, it's kind of funny, right? You're like, yeah, I understand, but not all the lingo. \n\nMATT: Have you looked? Is there a direct translation? \n\nEDDY: There is, and if you're interested, I can tell you. \n\nMATT: I am.\n\nEDDY: Yeah, array in Spanish is regla like a ruler.\n\nMATT: Great. Interesting. \n\nEDDY: It is, yeah.\n\nMATT: So, one of the other things I think is really important for onboarding is to have a plan instead of just flying by the cuff every time we bring someone on, and I know I'm guilty of that. But having a plan, having a schedule, assigning these buddies, assigning a pair, those things, if you have them lined up up front, will really help improve the process. \n\nMIKE: About seven years ago-ish, more or less, Acima was running their first apprenticeship program. And the one who had been running it actually took a position in a different company after they were about two weeks in. And I was brought in to lead that program and a team two weeks in [laughs]. That was a challenge [laughs], I've got to say, because that continuity was lost, you know, and the preparation was [inaudible 15:45]. And I put a lot of time into getting on top of that. And I really wish that I'd had the preparation ahead of time. \n\nIn subsequent years, I learned my lesson [laughs] and tried to get well out ahead of that. You know, for an internship or apprenticeship, you know, we've got a schedule. We've got a project. We've got the person they know to cling to and talk to. We've got the buddies lined up. And having those things lined up means that you can come in and have it go much more smoothly. \n\nMATT: I think another new challenge we're facing this year, in particular, is as we're operating under the corporate umbrella, some of these interns are in an entirely different state now, and we're used to having them in office historically. So, that, I think, presents some new challenges that we need to overcome. \n\nMIKE: One thing we're doing with the interns is dividing. So, in general, the Draper office, we should have local folks primarily. But, you know, the pandemic made things really interesting because we were all remote, no face-to-face contact, and that brings with its own set of challenges. Now, we're getting farther away from that. Most companies have at least a hybrid connection where some people are seeing each other sometimes. But, you know, it was all on camera or voice, and you do lose something. You do lose something, some connection. And you have to...I'm not saying that you shouldn't do it. But it takes additional work to be connected when you're not physically in the same space. \n\nMATT: Absolutely. Even working with some of these people that we've worked with that are in our Plano offices for a few years, you don't really feel like you know them until you actually meet them in person and get a little face time. I mean, it improves those relationships so much. I think it's super valuable. \n\nMIKE: Well, even things like...actually, Eddy and I were talking about this before we started the call. Turning on the camera [laughs] when you're working with remote people (It is a little off-topic from our main subject.), but it makes a difference. It gives you more connection. I've done a lot of remote work, decades, actually, of remote work [chuckle], so I'm very familiar with it. But one thing that I used to years ago, partly out of necessity, not have a camera on, you know, it was all just voice or text chatting. But over the years, I've become much more...well, I'll say I've developed a habit of turning my camera on, even when I don't feel like it [laughs] because it can be exhausting to have people staring at you all day. But I try to do it anyway just to establish that greater human connection. \n\nEDDY: We were pretty lucky, Ramses, myself, and Tad, just to put names out there, sorry, guys. We were given new laptops, and we got to upgrade from Intel to Mac, right? And that was awesome. But I was also a little skeptical at first because I'm like, dang, I haven't onboarded in a while. Like, do I still remember how to do this? And we got out pretty quickly, but it's only because I had a bunch of the context already that I didn't know I had, you know, until I had to reapply that again.\n\nAnd I'm like, oh crap, it is not working. What was that again? Oh yeah, cool, cool, cool. And I was able to fill stuff in. I cannot imagine doing that with this being the very first thing. Like, if I'm an intern coming in and like, hey, set up Kubes. Set up AWS. Set up your bundles. Like, it could go over your head. And I realized that maybe documentation could be a lot better. But in order to help facilitate new onboarding, I think documentation is critical to how fast an individual gets up to speed. \n\nMATT: Absolutely. And, yes, it's really hard without some assistance and guidance setting up, especially our services. We have a pretty complex ecosystem. And I experienced that when I started with the company. It was right when the pandemic hit, and we all got sent home, and I didn't have all of my services set up yet. So, I just kind of had to fumble my way through it, reaching out via Slack where I could. It was tough. So, you're absolutely right. And I think something probably everyone, at least through my experience, can improve on is documentation, especially with onboarding new employees. \n\nMIKE: Well, let's dig into that. We've talked about having a human connection, but that person can't be there all the time. That's just not possible unless you're some privileged person who can pay for a personal mentor [laughs], but, you know, generally, you're not going to get 100% of somebody's dedicated attention. And you're going to need to figure stuff out on your own sometime. How much do you think we should invest into documentation? Because documentation can be very expensive because it's an artifact, just like code is. \n\nOne idea that has really stuck with me is the idea that code is debt. Usually, we think, no, we're building this great thing. Well, yes, you built something, but now you've got to maintain it. It may provide value. But what's providing value is that you solve the problems, not necessarily the code itself. And if you have that code, that artifact requires maintenance. Likewise, documentation is the same way, and it doesn't even provide value. It doesn't pay for itself by, you know, having users use it. It indirectly pays for itself by making things go faster. It doesn't mean it's not valuable. But it's expensive. It's expensive and hard to maintain. So, to what degree should we invest in documentation to make onboarding easier? \n\nMATT: Well, I know that you've said this before. I think that it's worth the upfront investment just for the cost savings you're going to get by, you know, increasing the rate at which people can get onboarded and up to speed. But something you've said a number of times, and it's stuck with me, is while we're onboarding, we have those new employees help maintain that documentation and make sure it gets up to date. That way, you're kind of killing two birds with one stone. You're getting people onboarded. They're getting more familiar because they have to go through and help maintain this documentation. So, it will bring up questions that maybe they haven't thought of before. It'll identify gaps in that documentation that they can help fill. So, I personally think it's invaluable. \n\nMIKE: So, you just said something, I think, important here. A way you can keep your documentation fresh is everybody who uses it, particularly this onboarding documentation, updates it and make that formally part of the, you know, the responsibility. It builds on something we've already talked about of, you know, teaching and explaining [inaudible 22:38] the documentation. \n\nEDDY: Actually, I've experienced that firsthand over the past couple of weeks. Part of the project that I'm working on and part of the team is integrating with a third party, right? And a bunch of that has been through the course of APIs and, like, what kind of response, what the shape looks like, what they take, you know, what attributes are required, which ones are optional. And having a robust documentation on that goes leaps and bounds, right, to answering your own questions, and so instead of waiting for individuals to respond and give you the understanding, not just there; it's just in general, right? I just want to harp on, like, how crucial it is to have a robust onboarding, right, that just grows. \n\nMATT: Yeah, and on that, I know the project you speak of. On that project, you guys have also been creating documentation on the flows, things like that. And I'd be willing to bet that you understand it much, much better because you've had to go in and update and create that workflow and help maintain the documentation on our side.\n\nEDDY: Agreed. \n\nMIKE: So, we've talked about pairing people together, putting the new folks together so they can help each other out. We've talked about assigning an experienced buddy. We've talked about documentation. Are there any other key tactics that are helpful in onboarding? And we're speaking kind of generally, but this kind of applies maybe even across industries.\n\nMATT: Yeah. I think something I try to do is help with also building soft skills. And when you're onboarding people, one of the key things is building trust. It's much easier to work with people that you have trust in. And if you can establish that upfront and help build that trust, not only will it help them trust you, but you're going to help build some trust in them as well because you're opening up those communication channels and really establishing that interpersonal relationship that I think is important to work well with people. \n\nMIKE: That's interesting. And I had a thought about building trust. I mean, what is it you do to develop trust? You know, in dogs, you see a dog that wants to show that it's trustworthy, you know, it will, like, roll over on its back, show its belly. It shows vulnerability. It makes itself vulnerable. And one of the most important things, I think, that's maybe a key thing that we do to establish trust is show that we're willing to be vulnerable, show that we make mistakes, show that we're willing to, you know, listen to feedback. Establishing trust, I think, begins largely with yourself being willing to listen. What are your thoughts about establishing trust? \n\nEDDY: Gosh, just having someone you can reach out to when you're in doubt that does wonders, right, to helping you feel better about your job. \n\nMATT: Yeah, I think also, too, let them know they're doing a good job in picking up on things, you know, reinforce that. Help them build some confidence as well. \n\nRAMSES: Related to the documentation point, I think having a system that promotes searchability. Whenever I'm learning a new thing or a new process or working on a new feature, if I don't have a point person immediately available, I like to be able to have a good tool where I can search and find out how the feature works myself. So, it's related to documentation. And I think if our system is documented well, you know, and if they don't necessarily have that point person immediately available, they can at least be able to search and try to find an answer. \n\nMIKE: I actually got a story about that from my first dev job. That searchability is a big deal. I remember that I was writing some code. It was some Windows code accessing libraries. Was it the MDC? Whatever it was back then, a long time ago. And I was just looking through the documentation. And, you know, I looked in the index, you know, looked through the relevant sections of documentation. It was posted, but I couldn't find in the documentation an API that did what I needed to do. And I was kind of giving up. And the guy I was working for Googled it and found the answer.\n\nAnd this was a big deal because Google was brand new at the time, and I didn't think to use it because I hadn't used Google before. And he pointed this out to say, \"You know, I'm not trying to make you feel bad. Google is this amazing tool.\" Now, there are other search engines now, but that was the one, at the time, that became available and fundamentally changed the way that the documentation was searchable, fundamentally changed the way software development was done. \n\nBecause instead of poring through documentation, you could search and actually get an answer. That discoverability was just...I don't know how I would have done, you know, had a career in software without that searchability. And the productivity gains that you get from adding that searchability are amazing. And documentation tends to be pretty opaque. It is hard to get through there and find what you're looking for. That's a really great point, I think, you're making, Ramses, that doing what you can to try to make it searchable is a big deal. \n\nEDDY: I think it's cool. Google is this new thing in our arsenal, in our utility belt that we can use in order to be more productive. Now we have AI [laughs], and that takes it even a bit further. You're like, cool, now I have a catered, like, bot that I can interact with and get even faster results.\n\nMATT: I'm on board the AI train for sure. But you said something there, Mike, that I think I would at least like to ask everyone's view on, and that is tools, right? Google, this new tool, can get you everything you need. What are you guys' thoughts on tooling, such as standardizing IDEs? You know, we use Vi. We use Visual Studio Code. We use the JetBrains tools in our company. And they all are different, very similar, but different. Do you think there's a benefit in standardizing some tools so workflows can become much more similar? Because then you can help with shortcuts, macros, things like that, code generation. Would that benefit in the onboarding process? \n\nEDDY: If we can have everyone just use Visual Studio Code, the whole department will be really happy [laughs]. \n\nMATT: Except for a JetBrains user like myself, and I think Mike's a Vi user. \n\nMIKE: I am [laughs]. And, you know, a lot of that's because I had a mentor who taught me Vi, who was doing a lot of server administration. And it got in my tool belt and became [laughs] really useful because I took the time with it. And that's a tricky question, right, because if you've already got people on different technologies, there's going to be a cost to making that uniform. \n\nMATT: And I asked because the same thing, like you, you know, I started in Vi and Vim, moved over to some other tools. I think, at the time, I was using Sublime. And then, we had a project that we did a lot of paired programming on, and everyone I was working with used RubyMine. And I saw their workflows and all the cool shortcuts they were using that was really speeding things up. So, I thought, hey, I'm going to get on board, and I'm going to switch to this because this is what everyone I'm working with is using. And I've kind of just stuck with it since. But I think that was a big part of the onboarding process for that particular project that really helped me out. \n\nMIKE: It's almost inevitable that you'll probably end up using the tooling of your mentor. And even if you don't choose to standardize, and maybe that's a discussion for another day, getting somebody set up in the tooling that you're using so that you can do something in common is probably going to help them move a lot faster. \n\nMATT: We're all going to go back to Macromedia. \n\n[laughter] \n\nMIKE: Oh boy [laughter]. The olden days of yore. \n\nMATT: Yes. It's interesting things to think about. \n\nMIKE: Well, so, we started scratching on tooling. I mentioned, you know, search engines have changed things. I don't know how much AI is going to change things in the future, but I'm sure that it will. And the next generation of AI that goes beyond, you know, text generation, you know, maybe they add reinforcement learning; maybe they add a new algorithm we haven't thought of yet may fundamentally change the game again. \n\nAnd our industry is like that. It's quickly moving, and there's new tools. And it's easy to miss that and end up getting behind. I think we need to be careful about that. And going back to the idea of trust, maybe your new hires have some good ideas. And we shouldn't get so ingrained in our flows that we're not open to improving our process, and probably should actively, you know, seek for that, look for ideas from new hires. What do they have that they can offer that might change the way we do things? \n\nWe recently hired somebody who has a lot of experience with PostgreSQL and using some of the maybe less-used features like search for doing full-text searching. And he's got some great ideas as to how we might employ those. It might change the way we're doing things. But if we don't consider that, then we might end up stuck and never end up doing it better. \n\nA few months ago, we had a new hire who improved our unit test suite, made it go significantly faster by going and making a variety of changes from experience that he had, tooling that we hadn't used before. It made a big difference because rather than just relying on what we knew, we let the new guy show some of his experience. You know, you give a new person, let her, let him do their thing, you may end up learning a lot more yourself than you expected, as well as just teaching. \n\nMATT: Yeah, well, I mean, we hired all of these people for a reason, right? And everyone has something to offer. We just need to be open to listening and seeing those things that they do have to offer us. Yeah, I mean, could you imagine being able to have a conversational chat and just look for something and have it go through all of our Slack history, all of our Confluence docs, all of our Wikis, all in one go, and just be able to ask it a question? \"Hey, how do I patch this particular thing because my system isn't running?\" And someone's asked that question before in Slack at some point. And it just responds and says, \"Oh, well, here's the solution.\" Powerful. \n\nMIKE: So, we've talked, you know, having a group to work with, having a buddy, documentation, discoverability in that documentation, and flexibility of the tools, taking time to think about tools and work together on tools. Again, these things aren't even necessarily industry-specific, not even work-specific, because a lot of these things could apply to a three-year-old. You know, without thinking about it, we can easily overlook it and not take the time, not invest the time, to make that onboarding process work well. Are there any other key things that we're missing that you all want to bring up? \n\nMATT: As you are summarizing things, I am also taking notes to make sure that not only are we talking about it, we're putting some things into action and helping to improve our process here. \n\nEDDY: Would you think that the individuals who are local can get some benefit with being desk buddies with the individual who's mentoring them? \n\nMIKE: I do. I remember starting at a job a lot of years ago. It was a startup, and they were in a tiny, little office, and [laughs] me and three other people basically just crammed in a corner of this [laughs] space, kind of almost on top of each other. It was hard to even get out of the little corner we were in. And later, we moved to a bigger, nicer office space where we were separated from each other. And then, we ended up just...we ended up very much more isolated. Because we all just ended up messaging each other, doing some sort of text messaging, rather than talking to each other because, you know, you don't want to talk across the aisle and interrupt everybody else around you. \n\nSo, we ended up not talking nearly so much as we did when we were kind of forced to be in a closed space. And I'll tell you, when we were in a closed space, I learned so much. I learned so much, and part of it is that I was new. But my understanding of what I needed to do just leaped forward because I was just so closely exposed all the time as to what I needed to learn. Have you had that experience? \n\nMATT: Yeah. You know, what is the likelihood, even though it's right at our fingertips, of someone who's sitting at home working remotely, spinning on something versus sitting next to one of their peers in conversational range just turning their head and asking the question? I personally think that the likelihood of the question in person is going to happen much, much more quickly than if you're isolated at your home, even though we have Slack right here and everyone available. I'm going to ask that verbal question much sooner than I am going to reach out via some form of messenger and ask the question. \n\nMIKE: It requires work. You have to develop a habit of becoming...it feels annoying when you're not used to it. You have to make a real effort to be much more assertive than you would otherwise be when you're in a remote position. And that takes time, and so that's a gap. That's a barrier that absolutely is there that takes time and effort to overcome. Now, maybe you're a remote-first company. That absolutely happens in a lot of cases. If you're in that situation, you have to make that effort. You have to encourage that culture strongly to encourage that inquisitiveness. \n\nMATT: Yeah, and I think by just general human nature, we don't want to be invasive, and we don't want to bug other people. But I think in order to be successful, we have to ask those questions. And the likelihood that the person on the receiving end is perfectly fine with it is pretty high, you know, I mean, people ask me questions, and they think they're annoying me. I am not annoyed whatsoever. If I am available, I'd love to have those conversations. I'd love to answer questions and help people. And I think most people really feel that way. \n\nMIKE: Absolutely. I'm usually buried in questions [chuckles], to tell you the truth. If I'm not in a meeting, I'm answering questions somewhere else. So, I'm answering questions in a meeting, or I'm answering questions in some sort of messaging tool. I don't find that annoying. That's, like, my job, right [chuckles]? To go and help people. It's what I expect people to do. \n\nAnd if people are not asking the questions, that's worse because then I feel bad. You know, then I'm thinking, well, now you're unable to be effective, and I'm unable to help you because you didn't ask. So, I love the fact that people be proactive. But, again, you have to establish that culture. That's a critical thing for this onboarding is that...and this is brought up a couple of times now, that you have to establish that culture and encourage the safety. \n\nMATT: Yeah. If you're not asking me questions, then I'm asking questions, you know [chuckle], entirely different types of questions than I would be asking. So, I encourage it. And I think we all want everyone to grow and be successful. \n\nMIKE: You know, and that's probably a good place to finish this conversation is that it comes down to that relationship. You know, we're talking about solving business problems, but, in the end, we're people working together, and we should treat people with that humanity. If you want somebody to be successful, treat them like a person [chuckles] and develop that kind of human relationship. Think about what the human needs are and be responsive to them. And I think you would be far more successful and happier as a result, too. \n\nAny final words from anyone? \n\nMATT: As always, I always enjoy being a part of this. So, thank you all for letting me participate. \n\nMIKE: Of course. \n\nEDDY: It's always a treat when we can get Matt [laughs]. \n\nMATT: Thanks, Eddy.\n\nMIKE: Well, thank you, Eddy, Ramses, Matt. Until next time on the Acima Development Podcast. ","content_html":"In this episode of the Acima Development Podcast, host Mike starts by sharing an anecdote about his three-year-old son, emphasizing the importance of guidance and support in learning. This sets the stage for a discussion on onboarding new employees, highlighting the similarities between guiding a child and mentoring new hires. Mike notes that new employees, like his son, have potential but require proper guidance to become productive members of the team.
\n\nThe discussion then delves into various strategies for successful onboarding. Matt praises Mike's analogy and underscores the importance of mentorship and guidance for new employees. Eddy adds that providing the right tools and environment allows new hires to realize their potential. The group agrees on the significance of assigning buddies to new employees and promoting a supportive culture where asking questions is encouraged. This not only helps new hires learn faster but also fosters a collaborative environment. They also stress the importance of documentation and how it can be a valuable resource for new employees when mentors are not available.
\n\nTowards the end, the conversation shifts to the role of tools and technology in onboarding. The hosts discuss the benefits of standardizing tools to streamline workflows and make the onboarding process more efficient. They also touch on the challenges of remote work and how it can impact the onboarding experience. The episode concludes with a reminder that onboarding is not just about processes and tools but also about building trust and relationships. By treating new hires with humanity and fostering a culture of openness and support, companies can ensure a successful and smooth onboarding experience!
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm hosting today. And with me, we've got Eddy, Ramses, and Matt.
\n\nAnd I'm actually going to start today by talking about my family. I have a three-year-old, and [chuckles] he is very much three years old [laughs]. He is figuring things out, and sometimes, he does the wrong thing, like chasing you around and hitting you with a stick. Like, no, that's the wrong thing to do [laughs]. And you tell him that, and he'll be upset and think that you're trying to hurt his feelings. Like, no, I love you. I just don't want to get hit by a stick [laughs].
\n\nAnd, you know, three years ago, he just laid there and cried if he was hungry, right [laughs]? He had a lot of abilities, but none of them were developed at all. And I honestly don't expect him to be a contributing member of society for another 15 years [laughs]. And that's pretty normal because that's true for all of us. We all get this start, you know, we've got this potential, but not really any knowledge about the situation and got to figure out as we go. And it takes a long time before we're productive.
\n\nI mention this because today, we're going to talk about onboarding new employees. And, hopefully, you're not putting your three-year-olds or your infants to work [laughs]. But we all start, to some degree, you know, in ignorance. You know, we come into a new job and there's a lot of stuff we don't know. We have a ton of potential, but there's so much that we don't know and things we don't even know we don't know that make it very hard to get up to speed.
\n\nAnd, you know, depending on how well that onboarding process goes, depending on how much support is given to those new employees, it may take them a fairly short period of time to get up to speed or...hopefully, not 18 years [laughs], but it can take a while. I mentioned the support they get, and that's something we can influence. To some degree, there's also the intrinsic complexity of the systems that we're working with that we don't control. There are some things we can do, you know, we can do refactoring, try to improve our systems, but, you know, some problems are hard, and it's going to take people a while to get up to speed. These are real problems, and they're worth talking about.
\n\nAnd that's our topic for discussion today is, how do we onboard? It's also timely because we've got some interns starting on Monday, and we'd really like to give them the support that they need to quickly get up to speed. Now, I have some thoughts about the things that are most important for helping somebody in their onboarding, but I'd like to open the floor. What do you all think about what's important for helping people do that onboarding?
\n\nMATT: I'd first like to say you are always so great with your segues and analogies because this one makes perfect sense, right? You have a three-year-old who is learning as he goes. And would he probably figure out life on his own? Yeah, eventually. But without your guidance and without some leadership, it would take much, much longer than it would instead of you providing it for him, right? And I think that's kind of what we have to look at when onboarding new employees, whether it be new to the company, new to a role, or switching departments, you know, any of those things. I think everyone requires a little bit of instruction and guidance until they get up to speed.
\n\nMIKE: Absolutely.
\n\nEDDY: You mentioned individuals having potential but not the right guidance, kind of paraphrasing a little bit. And any individual that you hire, you interview, and you say, "Yeah, this person's got the right attitude. They got potential," but if you expect this person to hit the ground running, they're going to fall over, or they're going to drown. If you're patient and you provide the right reinforcements, and the right help, and tools, utility, et cetera, the person will grow into their own, and they will show you what you perceived during the interview.
\n\nI'd like to believe that some of the individuals who are engineering now are showing that on a day-by-day basis, right? Individuals, you know, who were ambitious, you know, who had the courage, you know, to push forward and be given the opportunity to do that shift in career have now been able to provide all that throughput, you know, that was initially observed during the interview. So, I think that so long as you do provide the patience and the right atmosphere, people will grow into their own, and they will surprise you.
\n\nMIKE: I can say that's true of you, Eddy [laughs]. You've done amazing work. And, honestly, I would say that's true of each of you. I know many of you listening are like, oh, I don't care about that. I do. I'm going to call it out publicly. I'm working with three people that I'm very happy to be working with.
\n\nMATT: And I second that. One of the things that I think is really important and maybe sometimes we overlook when we're onboarding people is that in this process, we can also empower them to be mentors and help them be able to onboard the next people that come on. And I've found, at least throughout my career, that one of the important things as the mentee or new person being onboarded is to ask questions and not be afraid to ask those questions. And as mentors, we can help guide that with our new people and encourage that. That can go a long way.
\n\nMIKE: I think that culture does make a huge difference. If you shut down any question quickly, there's not going to be very many more questions, and you do a lot of harm. Back to the three-year-old, you know what three-year-olds do? They ask questions. "What's this? What's this? What's that? What's this? What's this [laughs]?" And you can shut that down and not respond. And the result is that curiosity will be lost, and that's an awful outcome. You wouldn't want it to happen to your three-year-old. I don't think you want it to happen to your new employee, either. That curiosity is probably a lot of why you want them there—is that hunger to grow.
\n\nMATT: Yeah, and it creates isolation if you do shut it down. As annoying as those "What's this?" questions might be, that's how they're learning, and that's how they're gathering all this new information. And will they retain all of it at once? Probably not. But that's why they need to continue asking these questions.
\n\nYou know, I've been in the industry forever now, but here with the company, I'm in a new role, and Mike is present in most of the meetings I am. And I am one of those people who's always asking questions. And it may feel a little disruptive at times, but I try to ask the question once and remember those things so I don't have to again, and that way, if someone asks me about those same things, I have the answers for them.
\n\nEDDY: Can I say how much talent it takes to understand something that's been directed to you the very first time [laughs]? I will have the individual reiterate three different ways for me to really understand that before they say, "Do you get that?" "Yeah, yeah, I get that [laughs]."
\n\nMIKE: Okay, so let's talk about that. So, going, you know, with the analogy we've got here, this morning, my toddler asked me, "What's this?" And he was pointing at a cell phone tower. And I said, "It's a cell phone tower [laughs]." And he now has, like, some label for it that he's probably going to forget [laughs], and that's probably about all he has. He has no concept of what's going on there. He's three. I'm not going to explain to him electromagnetic radiation and, you know, low-frequency waves that can travel through a lot of distance and through even solid materials sometimes, and how those resonate with your antennas.
\n\nI can just say, "That's a tower," right? If you don't have something to hold that information onto, to kind of pin it to, it's like trying to remember 20 numbers in a row. You're not going to remember it. Your brain won't do that. You can only hold about seven. But if you have that narrative, if you actually have the story, you have something to pin it to. So, you're going to need somebody to repeat and repeat and repeat with greater depth each time. Because the first time, you might, if you remember it, learn the name. The second time, maybe you have a little more story around it, and so on. And with each iteration, you're going to internalize more information.
\n\nMATT: Yeah, and let's face it, when you're starting somewhere, you're drinking from a fire hose, and you definitely can't retain everything that you're being told. You know, you just have to try and pick the things that you think are important and hold on to those, and maybe they aren't the right thing sometimes. But you're right; things do take more than once to really ingrain.
\n\nEDDY: In order for me to reassure myself that I've been able to internalize something new, I try to explain it to someone else who has no context, right? I read this article a few weeks ago that basically says if you're having a hard time explaining it or dumbing it down, you probably don't understand it. And so, I've gotten into the habit I'm like, oh yeah, cool, I think I get it. But let me try to explain it to someone else and see if they can at least get the concept of what it is. It has done wonders because if I'm able to be like, oh, huh, wait, I don't know if I'm sure about this analogy; let me just make sure, it really harps that ideology down.
\n\nMATT: Yeah, if you want a better understanding of something, teach it. And you're probably going to pick up something along the way while you are.
\n\nMIKE: Absolutely, and that connects back to the onboarding. One thing I found, so kind of the first tactic I'm going to throw out here that I have found to be extremely helpful for onboarding, is to pair people together who are starting at the same time or starting near the same time. If somebody started three months ago, they have everything fresh in their head. And they're going to be able to probably more easily help the person who just started than actually somebody who's been there a long time. And it has the added benefit is now they're explaining it. Now, they're finding where the gaps are and deepening their understanding.
\n\nAnd if people are starting at the same time, it's kind of a back-and-forth, right? It's this pairing that allows them to do that, you know, in a very tight loop with each other, and it works out really well. There's another tactic I'm going to get to in a minute. But I think that that's one of the most helpful things I've seen is to pair people together who have started at around the same time. Have you all seen that to be similarly effective?
\n\nMATT: Yeah, absolutely. And each of them are going to retain different things. So, if you have them together...in fact, we are just going through this on one of my teams. I have two new hires, and it worked out that I could start them both the same day; much, much easier that way because then they can work off each other, as well as it frees up some of our engineering time, right, to be able to do that with two people at once. But it's a much broader conversation when you have three people involved versus two.
\n\nMIKE: So, in short, it works, right [laughs]? Put people together. You know, to bring up another tactic that I've found is extremely valuable, is give somebody a buddy. Give whoever is coming in an assigned buddy. Like, "You, this is your friend [laughs], and you're going to work with them." In the absence of that, people don't know who to ask, right? You're like, well, I should ask somebody, and they'll go and try to ask whoever they saw first because [inaudible 12:22] familiar face. You don't know who to talk to. And you can go talk to the person next to you, like, oh, I don't know, right [laughs]? And then, you drop right into that isolation. You need to have a line of contact, somebody that you can ask.
\n\nNow, they may not be the right person to answer your question, but they can point you to the person who can answer that. They can point to the documentation. They can bring you down to IT to get you a new laptop. You know, having somebody have a person is just one of the most important things I've seen.
\n\nI think I mentioned in a podcast, a recent podcast that we were on, I remember a job I had over 20 years ago, comfortably over 20 years ago now, well over 20 years ago, where I was doing some construction work. And my first day, they set me up with somebody else, and there were some language challenges. We didn't understand each other very well at first, well, mostly me not understanding [laughs] him very well. This was in Louisiana, and he had a French background, but we still communicated. And, man, having that buddy made such a difference. It made such a difference. And pretty soon, I was able to understand. And we worked well together. I learned the ropes, and we actually got to be really close friends.
\n\nRAMSES: Do you speak French now, too, Mike?
\n\nMIKE: Not a word [laughs]. Well, probably a word but not meaningfully [laughs].
\n\nEDDY: How's your Spanish?
\n\nMIKE: Not a paid promotion, but I use Duolingo, and it has been helping. I've been studying Duolingo for almost four years daily.
\n\nRAMSES: Oh, nice.
\n\nMIKE: It has been very beneficial. I can read Spanish pretty well now.
\n\nMATT: I do love that we can practice those languages here at this company. I've been trying because I went so long without speaking any Spanish, and Eddy and a number of the other team members have really helped out with that.
\n\nEDDY: To be fair, this is a side [inaudible 14:11], but I've always associated programming terminology in English. And I've never once thought, huh, how do I say array in Spanish, right [laughter]? So, like, I can say everything else except array, and I'm like, oh, man, how do you say that, right? But, like, it's kind of funny, right? You're like, yeah, I understand, but not all the lingo.
\n\nMATT: Have you looked? Is there a direct translation?
\n\nEDDY: There is, and if you're interested, I can tell you.
\n\nMATT: I am.
\n\nEDDY: Yeah, array in Spanish is regla like a ruler.
\n\nMATT: Great. Interesting.
\n\nEDDY: It is, yeah.
\n\nMATT: So, one of the other things I think is really important for onboarding is to have a plan instead of just flying by the cuff every time we bring someone on, and I know I'm guilty of that. But having a plan, having a schedule, assigning these buddies, assigning a pair, those things, if you have them lined up up front, will really help improve the process.
\n\nMIKE: About seven years ago-ish, more or less, Acima was running their first apprenticeship program. And the one who had been running it actually took a position in a different company after they were about two weeks in. And I was brought in to lead that program and a team two weeks in [laughs]. That was a challenge [laughs], I've got to say, because that continuity was lost, you know, and the preparation was [inaudible 15:45]. And I put a lot of time into getting on top of that. And I really wish that I'd had the preparation ahead of time.
\n\nIn subsequent years, I learned my lesson [laughs] and tried to get well out ahead of that. You know, for an internship or apprenticeship, you know, we've got a schedule. We've got a project. We've got the person they know to cling to and talk to. We've got the buddies lined up. And having those things lined up means that you can come in and have it go much more smoothly.
\n\nMATT: I think another new challenge we're facing this year, in particular, is as we're operating under the corporate umbrella, some of these interns are in an entirely different state now, and we're used to having them in office historically. So, that, I think, presents some new challenges that we need to overcome.
\n\nMIKE: One thing we're doing with the interns is dividing. So, in general, the Draper office, we should have local folks primarily. But, you know, the pandemic made things really interesting because we were all remote, no face-to-face contact, and that brings with its own set of challenges. Now, we're getting farther away from that. Most companies have at least a hybrid connection where some people are seeing each other sometimes. But, you know, it was all on camera or voice, and you do lose something. You do lose something, some connection. And you have to...I'm not saying that you shouldn't do it. But it takes additional work to be connected when you're not physically in the same space.
\n\nMATT: Absolutely. Even working with some of these people that we've worked with that are in our Plano offices for a few years, you don't really feel like you know them until you actually meet them in person and get a little face time. I mean, it improves those relationships so much. I think it's super valuable.
\n\nMIKE: Well, even things like...actually, Eddy and I were talking about this before we started the call. Turning on the camera [laughs] when you're working with remote people (It is a little off-topic from our main subject.), but it makes a difference. It gives you more connection. I've done a lot of remote work, decades, actually, of remote work [chuckle], so I'm very familiar with it. But one thing that I used to years ago, partly out of necessity, not have a camera on, you know, it was all just voice or text chatting. But over the years, I've become much more...well, I'll say I've developed a habit of turning my camera on, even when I don't feel like it [laughs] because it can be exhausting to have people staring at you all day. But I try to do it anyway just to establish that greater human connection.
\n\nEDDY: We were pretty lucky, Ramses, myself, and Tad, just to put names out there, sorry, guys. We were given new laptops, and we got to upgrade from Intel to Mac, right? And that was awesome. But I was also a little skeptical at first because I'm like, dang, I haven't onboarded in a while. Like, do I still remember how to do this? And we got out pretty quickly, but it's only because I had a bunch of the context already that I didn't know I had, you know, until I had to reapply that again.
\n\nAnd I'm like, oh crap, it is not working. What was that again? Oh yeah, cool, cool, cool. And I was able to fill stuff in. I cannot imagine doing that with this being the very first thing. Like, if I'm an intern coming in and like, hey, set up Kubes. Set up AWS. Set up your bundles. Like, it could go over your head. And I realized that maybe documentation could be a lot better. But in order to help facilitate new onboarding, I think documentation is critical to how fast an individual gets up to speed.
\n\nMATT: Absolutely. And, yes, it's really hard without some assistance and guidance setting up, especially our services. We have a pretty complex ecosystem. And I experienced that when I started with the company. It was right when the pandemic hit, and we all got sent home, and I didn't have all of my services set up yet. So, I just kind of had to fumble my way through it, reaching out via Slack where I could. It was tough. So, you're absolutely right. And I think something probably everyone, at least through my experience, can improve on is documentation, especially with onboarding new employees.
\n\nMIKE: Well, let's dig into that. We've talked about having a human connection, but that person can't be there all the time. That's just not possible unless you're some privileged person who can pay for a personal mentor [laughs], but, you know, generally, you're not going to get 100% of somebody's dedicated attention. And you're going to need to figure stuff out on your own sometime. How much do you think we should invest into documentation? Because documentation can be very expensive because it's an artifact, just like code is.
\n\nOne idea that has really stuck with me is the idea that code is debt. Usually, we think, no, we're building this great thing. Well, yes, you built something, but now you've got to maintain it. It may provide value. But what's providing value is that you solve the problems, not necessarily the code itself. And if you have that code, that artifact requires maintenance. Likewise, documentation is the same way, and it doesn't even provide value. It doesn't pay for itself by, you know, having users use it. It indirectly pays for itself by making things go faster. It doesn't mean it's not valuable. But it's expensive. It's expensive and hard to maintain. So, to what degree should we invest in documentation to make onboarding easier?
\n\nMATT: Well, I know that you've said this before. I think that it's worth the upfront investment just for the cost savings you're going to get by, you know, increasing the rate at which people can get onboarded and up to speed. But something you've said a number of times, and it's stuck with me, is while we're onboarding, we have those new employees help maintain that documentation and make sure it gets up to date. That way, you're kind of killing two birds with one stone. You're getting people onboarded. They're getting more familiar because they have to go through and help maintain this documentation. So, it will bring up questions that maybe they haven't thought of before. It'll identify gaps in that documentation that they can help fill. So, I personally think it's invaluable.
\n\nMIKE: So, you just said something, I think, important here. A way you can keep your documentation fresh is everybody who uses it, particularly this onboarding documentation, updates it and make that formally part of the, you know, the responsibility. It builds on something we've already talked about of, you know, teaching and explaining [inaudible 22:38] the documentation.
\n\nEDDY: Actually, I've experienced that firsthand over the past couple of weeks. Part of the project that I'm working on and part of the team is integrating with a third party, right? And a bunch of that has been through the course of APIs and, like, what kind of response, what the shape looks like, what they take, you know, what attributes are required, which ones are optional. And having a robust documentation on that goes leaps and bounds, right, to answering your own questions, and so instead of waiting for individuals to respond and give you the understanding, not just there; it's just in general, right? I just want to harp on, like, how crucial it is to have a robust onboarding, right, that just grows.
\n\nMATT: Yeah, and on that, I know the project you speak of. On that project, you guys have also been creating documentation on the flows, things like that. And I'd be willing to bet that you understand it much, much better because you've had to go in and update and create that workflow and help maintain the documentation on our side.
\n\nEDDY: Agreed.
\n\nMIKE: So, we've talked about pairing people together, putting the new folks together so they can help each other out. We've talked about assigning an experienced buddy. We've talked about documentation. Are there any other key tactics that are helpful in onboarding? And we're speaking kind of generally, but this kind of applies maybe even across industries.
\n\nMATT: Yeah. I think something I try to do is help with also building soft skills. And when you're onboarding people, one of the key things is building trust. It's much easier to work with people that you have trust in. And if you can establish that upfront and help build that trust, not only will it help them trust you, but you're going to help build some trust in them as well because you're opening up those communication channels and really establishing that interpersonal relationship that I think is important to work well with people.
\n\nMIKE: That's interesting. And I had a thought about building trust. I mean, what is it you do to develop trust? You know, in dogs, you see a dog that wants to show that it's trustworthy, you know, it will, like, roll over on its back, show its belly. It shows vulnerability. It makes itself vulnerable. And one of the most important things, I think, that's maybe a key thing that we do to establish trust is show that we're willing to be vulnerable, show that we make mistakes, show that we're willing to, you know, listen to feedback. Establishing trust, I think, begins largely with yourself being willing to listen. What are your thoughts about establishing trust?
\n\nEDDY: Gosh, just having someone you can reach out to when you're in doubt that does wonders, right, to helping you feel better about your job.
\n\nMATT: Yeah, I think also, too, let them know they're doing a good job in picking up on things, you know, reinforce that. Help them build some confidence as well.
\n\nRAMSES: Related to the documentation point, I think having a system that promotes searchability. Whenever I'm learning a new thing or a new process or working on a new feature, if I don't have a point person immediately available, I like to be able to have a good tool where I can search and find out how the feature works myself. So, it's related to documentation. And I think if our system is documented well, you know, and if they don't necessarily have that point person immediately available, they can at least be able to search and try to find an answer.
\n\nMIKE: I actually got a story about that from my first dev job. That searchability is a big deal. I remember that I was writing some code. It was some Windows code accessing libraries. Was it the MDC? Whatever it was back then, a long time ago. And I was just looking through the documentation. And, you know, I looked in the index, you know, looked through the relevant sections of documentation. It was posted, but I couldn't find in the documentation an API that did what I needed to do. And I was kind of giving up. And the guy I was working for Googled it and found the answer.
\n\nAnd this was a big deal because Google was brand new at the time, and I didn't think to use it because I hadn't used Google before. And he pointed this out to say, "You know, I'm not trying to make you feel bad. Google is this amazing tool." Now, there are other search engines now, but that was the one, at the time, that became available and fundamentally changed the way that the documentation was searchable, fundamentally changed the way software development was done.
\n\nBecause instead of poring through documentation, you could search and actually get an answer. That discoverability was just...I don't know how I would have done, you know, had a career in software without that searchability. And the productivity gains that you get from adding that searchability are amazing. And documentation tends to be pretty opaque. It is hard to get through there and find what you're looking for. That's a really great point, I think, you're making, Ramses, that doing what you can to try to make it searchable is a big deal.
\n\nEDDY: I think it's cool. Google is this new thing in our arsenal, in our utility belt that we can use in order to be more productive. Now we have AI [laughs], and that takes it even a bit further. You're like, cool, now I have a catered, like, bot that I can interact with and get even faster results.
\n\nMATT: I'm on board the AI train for sure. But you said something there, Mike, that I think I would at least like to ask everyone's view on, and that is tools, right? Google, this new tool, can get you everything you need. What are you guys' thoughts on tooling, such as standardizing IDEs? You know, we use Vi. We use Visual Studio Code. We use the JetBrains tools in our company. And they all are different, very similar, but different. Do you think there's a benefit in standardizing some tools so workflows can become much more similar? Because then you can help with shortcuts, macros, things like that, code generation. Would that benefit in the onboarding process?
\n\nEDDY: If we can have everyone just use Visual Studio Code, the whole department will be really happy [laughs].
\n\nMATT: Except for a JetBrains user like myself, and I think Mike's a Vi user.
\n\nMIKE: I am [laughs]. And, you know, a lot of that's because I had a mentor who taught me Vi, who was doing a lot of server administration. And it got in my tool belt and became [laughs] really useful because I took the time with it. And that's a tricky question, right, because if you've already got people on different technologies, there's going to be a cost to making that uniform.
\n\nMATT: And I asked because the same thing, like you, you know, I started in Vi and Vim, moved over to some other tools. I think, at the time, I was using Sublime. And then, we had a project that we did a lot of paired programming on, and everyone I was working with used RubyMine. And I saw their workflows and all the cool shortcuts they were using that was really speeding things up. So, I thought, hey, I'm going to get on board, and I'm going to switch to this because this is what everyone I'm working with is using. And I've kind of just stuck with it since. But I think that was a big part of the onboarding process for that particular project that really helped me out.
\n\nMIKE: It's almost inevitable that you'll probably end up using the tooling of your mentor. And even if you don't choose to standardize, and maybe that's a discussion for another day, getting somebody set up in the tooling that you're using so that you can do something in common is probably going to help them move a lot faster.
\n\nMATT: We're all going to go back to Macromedia.
\n\n[laughter]
\n\nMIKE: Oh boy [laughter]. The olden days of yore.
\n\nMATT: Yes. It's interesting things to think about.
\n\nMIKE: Well, so, we started scratching on tooling. I mentioned, you know, search engines have changed things. I don't know how much AI is going to change things in the future, but I'm sure that it will. And the next generation of AI that goes beyond, you know, text generation, you know, maybe they add reinforcement learning; maybe they add a new algorithm we haven't thought of yet may fundamentally change the game again.
\n\nAnd our industry is like that. It's quickly moving, and there's new tools. And it's easy to miss that and end up getting behind. I think we need to be careful about that. And going back to the idea of trust, maybe your new hires have some good ideas. And we shouldn't get so ingrained in our flows that we're not open to improving our process, and probably should actively, you know, seek for that, look for ideas from new hires. What do they have that they can offer that might change the way we do things?
\n\nWe recently hired somebody who has a lot of experience with PostgreSQL and using some of the maybe less-used features like search for doing full-text searching. And he's got some great ideas as to how we might employ those. It might change the way we're doing things. But if we don't consider that, then we might end up stuck and never end up doing it better.
\n\nA few months ago, we had a new hire who improved our unit test suite, made it go significantly faster by going and making a variety of changes from experience that he had, tooling that we hadn't used before. It made a big difference because rather than just relying on what we knew, we let the new guy show some of his experience. You know, you give a new person, let her, let him do their thing, you may end up learning a lot more yourself than you expected, as well as just teaching.
\n\nMATT: Yeah, well, I mean, we hired all of these people for a reason, right? And everyone has something to offer. We just need to be open to listening and seeing those things that they do have to offer us. Yeah, I mean, could you imagine being able to have a conversational chat and just look for something and have it go through all of our Slack history, all of our Confluence docs, all of our Wikis, all in one go, and just be able to ask it a question? "Hey, how do I patch this particular thing because my system isn't running?" And someone's asked that question before in Slack at some point. And it just responds and says, "Oh, well, here's the solution." Powerful.
\n\nMIKE: So, we've talked, you know, having a group to work with, having a buddy, documentation, discoverability in that documentation, and flexibility of the tools, taking time to think about tools and work together on tools. Again, these things aren't even necessarily industry-specific, not even work-specific, because a lot of these things could apply to a three-year-old. You know, without thinking about it, we can easily overlook it and not take the time, not invest the time, to make that onboarding process work well. Are there any other key things that we're missing that you all want to bring up?
\n\nMATT: As you are summarizing things, I am also taking notes to make sure that not only are we talking about it, we're putting some things into action and helping to improve our process here.
\n\nEDDY: Would you think that the individuals who are local can get some benefit with being desk buddies with the individual who's mentoring them?
\n\nMIKE: I do. I remember starting at a job a lot of years ago. It was a startup, and they were in a tiny, little office, and [laughs] me and three other people basically just crammed in a corner of this [laughs] space, kind of almost on top of each other. It was hard to even get out of the little corner we were in. And later, we moved to a bigger, nicer office space where we were separated from each other. And then, we ended up just...we ended up very much more isolated. Because we all just ended up messaging each other, doing some sort of text messaging, rather than talking to each other because, you know, you don't want to talk across the aisle and interrupt everybody else around you.
\n\nSo, we ended up not talking nearly so much as we did when we were kind of forced to be in a closed space. And I'll tell you, when we were in a closed space, I learned so much. I learned so much, and part of it is that I was new. But my understanding of what I needed to do just leaped forward because I was just so closely exposed all the time as to what I needed to learn. Have you had that experience?
\n\nMATT: Yeah. You know, what is the likelihood, even though it's right at our fingertips, of someone who's sitting at home working remotely, spinning on something versus sitting next to one of their peers in conversational range just turning their head and asking the question? I personally think that the likelihood of the question in person is going to happen much, much more quickly than if you're isolated at your home, even though we have Slack right here and everyone available. I'm going to ask that verbal question much sooner than I am going to reach out via some form of messenger and ask the question.
\n\nMIKE: It requires work. You have to develop a habit of becoming...it feels annoying when you're not used to it. You have to make a real effort to be much more assertive than you would otherwise be when you're in a remote position. And that takes time, and so that's a gap. That's a barrier that absolutely is there that takes time and effort to overcome. Now, maybe you're a remote-first company. That absolutely happens in a lot of cases. If you're in that situation, you have to make that effort. You have to encourage that culture strongly to encourage that inquisitiveness.
\n\nMATT: Yeah, and I think by just general human nature, we don't want to be invasive, and we don't want to bug other people. But I think in order to be successful, we have to ask those questions. And the likelihood that the person on the receiving end is perfectly fine with it is pretty high, you know, I mean, people ask me questions, and they think they're annoying me. I am not annoyed whatsoever. If I am available, I'd love to have those conversations. I'd love to answer questions and help people. And I think most people really feel that way.
\n\nMIKE: Absolutely. I'm usually buried in questions [chuckles], to tell you the truth. If I'm not in a meeting, I'm answering questions somewhere else. So, I'm answering questions in a meeting, or I'm answering questions in some sort of messaging tool. I don't find that annoying. That's, like, my job, right [chuckles]? To go and help people. It's what I expect people to do.
\n\nAnd if people are not asking the questions, that's worse because then I feel bad. You know, then I'm thinking, well, now you're unable to be effective, and I'm unable to help you because you didn't ask. So, I love the fact that people be proactive. But, again, you have to establish that culture. That's a critical thing for this onboarding is that...and this is brought up a couple of times now, that you have to establish that culture and encourage the safety.
\n\nMATT: Yeah. If you're not asking me questions, then I'm asking questions, you know [chuckle], entirely different types of questions than I would be asking. So, I encourage it. And I think we all want everyone to grow and be successful.
\n\nMIKE: You know, and that's probably a good place to finish this conversation is that it comes down to that relationship. You know, we're talking about solving business problems, but, in the end, we're people working together, and we should treat people with that humanity. If you want somebody to be successful, treat them like a person [chuckles] and develop that kind of human relationship. Think about what the human needs are and be responsive to them. And I think you would be far more successful and happier as a result, too.
\n\nAny final words from anyone?
\n\nMATT: As always, I always enjoy being a part of this. So, thank you all for letting me participate.
\n\nMIKE: Of course.
\n\nEDDY: It's always a treat when we can get Matt [laughs].
\n\nMATT: Thanks, Eddy.
\n\nMIKE: Well, thank you, Eddy, Ramses, Matt. Until next time on the Acima Development Podcast.
","summary":"","date_published":"2024-07-10T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/caa15d67-67dc-4a20-8c07-1347f6487c2c.mp3","mime_type":"audio/mpeg","size_in_bytes":24087015,"duration_in_seconds":2409}]},{"id":"905124ad-399d-4310-b4c8-dff5e4372df0","title":"Episode 49: Breaking Down Work","url":"https://acima-development.fireside.fm/49","content_text":"In this episode of the Acima Development Podcast, Mike and the team delve into the importance of breaking down projects into manageable iterations to avoid stagnation and inefficiency. Mike shares a story about a past experience with a developer who struggled to produce releasable code, which led to the realization that breaking projects into smaller milestones can significantly enhance workflow and productivity. This approach allows for continuous integration and deployment, preventing the team from getting stuck on incomplete tasks. Mike emphasizes that this skill of breaking down work is crucial yet often overlooked in engineering education.\n\nWill adds to the discussion by highlighting the value of creating \"jigs\" or scaffolding in both woodworking and software development. He explains that in his experience, especially with mobile app development, creating temporary structures or mockups can facilitate progress even when back-end systems are not fully ready. This method allows for continuous progress and testing, making it easier to adapt and iterate on the final product. Will’s anecdote about using a reverse proxy to simulate API endpoints underlines the practicality and effectiveness of this approach.\n\nThe conversation wraps up with broader reflections on iterative development and its applications in various fields, including aerospace and automotive technology. The team discusses how companies like SpaceX have revolutionized their industries through iterative processes, emphasizing the importance of starting with a functional but imperfect product and continuously improving it. They conclude by stressing the necessity of having a clear roadmap and the willingness to \"cheat\" by using tools and frameworks to eliminate human error, thus ensuring consistent and reliable outcomes. The episode ends with the advice to always build a jig and embrace iterative development for better efficiency and success in engineering projects.\n\nTranscript:\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm hosting again today. With me, I have Will, Ramses, and Eddy. I have a story I'm going to tell before I introduce the topic, and I think about this a lot. I was thinking about it this morning. I think I thought about it yesterday. I think about it probably at least monthly about..., and I've probably even shared it on the podcast before [laughs]. \n\nBut several years ago, I worked with a developer who was assigned to a project. We had talked about it as a team. We were all really excited about it. We had this new idea. It was kind of a developer-driven initiative. They worked on a little bit here, a little bit there, and a [chuckles] little bit over there. And this kept on going for, like, a month, and we thought that, you know, in a month, you'd have some code out. And looked at it, and there was kind of a framework or something there but there was nothing that was releasable. There were just pieces here and there, and it really felt like it stalled. \n\nNow, they'd been working on this day in and day out for weeks, but nothing had made it into production. And in a continuous integration, continuous deployment environment where you can get stuff out there piece by piece, that was unusual. And I thought, you know, what's going on here? And I consider this a failing on my side. And I thought about it, so what am I doing wrong here? \n\nBut I think there's some maturity in career experience here for this developer. They hadn't learned how to take a project and break it down into iterations. I worked with the team to do that. And I say I worked with the...we kind of talked about this idea, and the team jumped in, you know, and I was just a minor player. But as they became aware of that, it completely changed the workflow of the team I was working in, where everybody focused on, well, how do I break this up into milestones? And, on a large scale, like, having a big project, how to break it up into milestones, and then, a small scale, developers are breaking up. \n\nI had one developer come onto the team who made it like a singular focus. They'd come from another company where they spent, like, months on something [laughs] before they released it, and now they spend, like, multiple pull requests a day. And it's like their life is totally changed, and they're completely happier [laughs] because they've completely changed their workflow. They really embraced this and became kind of an evangelist. And I've seen it; I've seen this just be so successful for people who do this. And even for teams that get good at breaking things up, versus people who just stall for weeks or months. I've seen other...and that's certainly not the only instance I've seen. I just saw that one change, and then that developer became successful. \n\nI've seen other scenarios where somebody jumps into something, you know, a challenging problem, and they spin, and they spin, and they spin, and they get weeks in, and then farther in, and just never get anywhere [laughs]. And it's frustrating for the person who's doing it. And there's a few things that feel worse than being deep in a problem you just can't solve it. And you just feel like there's no light at the end of the tunnel. It's frustrating for everybody who's working around them. It's frustrating for everybody.\n\nLike I said, I think about this over and over again because I feel like it's one of the big skills in engineering that nobody really teaches, and that's a problem. It's just breaking up work. How do you break up work? And that's our topic today is, you know, how do you break up work, and why? \n\nWILL: The North Star, for me...I do kind of want to pull on this a little bit because I've done stuff that just doesn't work like this, right? I mean, like, most of the business development, product ticket stuff that we work with can be addressed in this way. And then, basically, it's just sort of, like, what can you get out into someone's hands? And I would say, like, I don't know how to translate...I don't know how to segue in this, right? But, like, get it out into people's hands, right? And the thing that I think tends to jam people up is, maybe it's just me, but I think other people as well, is, like, you got to be okay with sort of like, let's call it, like, call it actual construction, right, where we're woodworking, or something like that.\n\nYou have to be okay making a jig for something, right? You have to be okay making scaffolding for something, right? Where I'm going to build this entire structure, right? Entire structure. But it isn't actually ever going to go out. Like, I'm building it so that I can do the small steps. So, one of the things I'm working on, right, not at Acima, at another very large retailer, is that I work on a mobile app, right? And so, the thing about the mobile app is a lot of the time, we're front-running the back-end API stuff, right? And so, what I'll do is I will scaffold out all kinds of stuff. I'll go and I'll negotiate back and forth with the back-end team, and I'll say like, \"Okay, okay. Well, what's the data going to look like?\" And they'll say, like, \"Okay, it's going to look like this,\" right? \n\nSo, we'll do a contract, right? Which is just a contract. It's just aspirational, right? This is pure vaporware. But I'll get the contract going, and then I'll start charging ahead, right? And I'll just be like, okay, mock data, you know what I mean? Promise that's going to result to this thing, right? And then, I use a tool. It's a reverse proxy. And I can use that to create, like, a fake API endpoint, right? Where it's like, if you go to this API, this URL, it's going to give you back [vocalization], right? It's going to give you just...it's going to serve up this static file, right? \n\nAnd now, oh, okay, now I'm making, like, real API requests to fake API, right? And all this stuff is junk, right? It's junk. It'll never go live. But I can actually release the thing. It is real stuff. It might even really be on the server hidden behind, like, some feature flag wall, right? And so, it's out. It's in production. It exists. It's a real thing. But, also, no, it's not, right? It's walled off, and it requires, like, all this fake stuff. I'm like, hey, hey, you know what? \n\nAnd I'll tell you, like, honestly, like, I have hit on a contract before, but I am much more likely to miss on something. And it's like, oh, well, I have to go to the pricing and availability service, so it's going to be here. And I have to make another call. This JSON's going to...and you know what? It's fine. It's fine. I will have to go back and rework, but parsing Jason is really not that hard. In the end of things, it's really not that hard to parse some JSON. And so, like, you know, and then you'll go back.\n\nBut, like, if I wanted to do it, like, the quote, unquote \"right way,\" and get it a hundred percent, then I would have all of these sort of, like, blocking features, where I can't move until the feature's done. I can't move until this is done. I can't move until this is done. And I'm just like, eh, F it. Let's roll. And so, you just do it that way, right? And so, you're making assumptions, making trade-offs, debating stuff, and scaffolding, and, like, you know what I mean, going with prototypes. But you're always putting something out into the world. And that has been very, very, very successful. And it's allowed them to get things out at a pace that they ordinarily just...there's no way [laughs]. There's no way.\n\nMIKE: Yeah, it's interesting you mentioned the woodworking. My dad spent most of his career as a professional woodworker. That is exactly what [laughs] they spent most of their time on was: building those jigs, building the tooling to actually do what you needed. I don't know how much time my dad spent building tools. He still...he makes tools. Like, he'll see a problem. He'll go and make a tool because that's how he thinks now [laughs]. \n\nAbout ten years ago, my brother-in-law was showing him some grips for a handgun. My dad's never been, like, a huge gun enthusiast, but he saw that as a problem. He got curious about it, and he went and built a jig and made grips. And it turns out they were better than most of the stuff on the market. And he ended up doing it as kind of a side project hobby that kind of made him a living for several years [laughter] because he took the time to make that jig. Like, I don't really even hear that word outside of that industry, you know, outside of woodworking, but that's the word they use. And it's not exactly a tool, right? It's like a template. \n\nWILL: Yeah. Yeah. Like a template. So, for people who are not necessarily, like, wood butcher nerds...so, I'll give you an example, right? So, a guy I know he made this really beautiful grill table, right? And you could think of it like an outdoor kitchen table with this circular hole, and his grill goes in the middle. And you've got, like, your whole cook surface out there, and it's super, super cool. And I looked at it, right, and it's like, it's this beautiful table. His grill goes right on the side, and you could do all this stuff. \n\nBut, like, what he did is he had this beautiful three-foot circular hole for his grill to go on, right? One does not just cut a perfect three-foot circular hole. Like, one does not just walk into Mordor or cut a perfect circle [chuckles] in a butcher block countertop. And so, I was like, \"Oh, what did you do,\" right? Well, he created this, like, not exactly, like, a router. The router was a part of it, but, like, it was this thing to hold the tabletop in place. And he had, like, a thing, and it had an arm that it swung out, and the router cut this perfect circle. But he built, like, a scaffolding machine so that he could cut this perfect circle because you couldn't possibly do that by hand precisely.\n\nI might have dogged it and done it with like a, you know, done it with, like, a jigsaw and then just, like, put a little trim over it, like, a little metal, [laughter] like, a fat metal piece of trim, like, that big. And it's just like, ah, it's bad, but you can't see it, so who cares? So, that's what a jig is, you know what I mean? Like, it holds the work in place so that you can work on it effectively and precisely a lot of the time. Because if you just try and freehand it, you're screwed. That's why [inaudible 10:07] shop projects, you know what I mean? Like, when you did woodshop, if you did woodshop, they all look terrible because...\n\nMIKE: [laughs] Right.\n\nWILL: Because you tried to freehand it. You're just like, oh, well, let's just cut this. And I'm like, no, no, no, no [laughs]. You get something to hold it precisely so that you have a template, and you can do everything perfectly. \n\nMIKE: No, that's exactly it. The professionals, it's not that they're better at freehanding it, although they might be, is they don't trust themselves to freehand it.\n\nWILL: Exactly. \n\nMIKE: And so, they don't [laughs]. They build a system so that they eliminate the human mistake. That completely changes it, and that's how you end up with a quality piece of work. It's such a perfect analogy. You take the time to build the jig, you know, to build the scaffolding, to build the framework that allows you to test and deploy independently a component without necessarily having the other pieces in place. And without that, though, you're blocked, right? Because there's always going to be some other thing that you're working with. \n\nWhat we do [chuckles] is we read data from one place, and we transform it, and we write it somewhere else. That's what we do for a living. If your data sources aren't ready yet, then you're blocked, unless you define a contract and you code to that. And then you say...you have some sort of test harness that you can test against that contract, knowing what they have may not be ready yet. And you might even have the wrong contract. You might have to make some changes later, but at least you'll have something that you can make tweaks to rather than having to start from scratch.\n\nWILL: I think it's a good rule of thumb. I think it's a good rubric. Although I have been involved in projects where, like, you know what I mean, things were...you had to do...actually, you know what, honestly, I think I've always done that. I haven't always had the latitude to, like, front-run as much as I wanted to. Like, one of the things that I did, like, way back in the day, is I did a bunch of audio processing stuff, right, for phones and stuff like that back when, like, you know, the world was new on the iPhone. And I would do audio processing.\n\nAnd the thing about audio processing is audio processing, like, there's not a lot of, like, intermediate steps. You really got to, like, you got to kind of, like, do the whole thing. You know, like, you have to have, like, the machine has to, like, do finished products. But, like, honestly, like, I still did the same thing. I mean, in that I would just make it play a song. I was like, oh, I can't play a song, right? Because, like, okay, oh, you want to play a song, right? Well, I had to have all kinds of stuff. \n\nI had to have, like, a wave decoder, and then a wave, you know what I mean, like, a wave consumer, and stuff like that. And so, I was like, oh, that's too hard. I'll just make a sine wave because I could do that in math. I could do that mathematically. That's a mathematical function, right? Then I don't have to have codecs or anything like that. And then, I did that. And I was like, oh, okay, I did that. Okay. And now, I'll do a wave. Okay. Now I'll do a wave, right? It's like, okay, now I'll do an MP3 into a wave into, like, the speaker. I was like, okay, now I did that.\n\nNow, I will take the MP3 into a wave. I'll capture the audio and do nothing, right? Nothing, just a hand, just passing it through, right? And it'll go out. And then, I'll, you know, and then I'll just do, you know, something else, and then, you know what I mean? And so, I would, you know, just kind of do stuff like that.\n\nMIKE: But the process, like, even if you're not releasing it, in order to be able to...and this ties into testing, it seems like, right? Like, you mentioned the testing. At every step, you're doing something that you could verify. You wanted something that was kind of tangible. And I know none of this is purely tangible, but it was...the closest you're going to get to tangible is something...like, it was making it into sound that was making it into your ears. There was something that you could measure that you could validate on. And once you have that, you could build around it. \n\nWILL: Yeah. Yeah. And I built all kinds of jigs. One thing that I did is I was...so, we were working on, like, continuous DJ mixes, right? And so, it was a bunch of MP3s that were encoded and recorded, you know, in such a way so that there would be a continuous stream of music. So, it'd go play from track one to track two to track three to track four to track five. You would never hear a transition, right? You could do that. But I was transforming and manipulating the stuff, right? \n\nAnd so, like, when it would go over, it would pop. It would be a hitch. And I was trying to debug that one particular thing. And I was like, ah, like, my ADD brain won't let me sit and wait for the thing to roll over. So, I was just like, okay, I'm going to make a jig so that I just jump in five seconds before it ends. And then, I'll play through the transition, and I'll go and do five seconds again, and then I'll, you know, and that's how that goes through the song.\n\nSo, I'm only doing, like, the specific part that I want to see because I don't have time for all that, you know? It's just jigs. Just that's a way of doing it, I guess. My dad always taught me...my dad was an engineer, not a woodworker, but he always said, \"Go from the known to the unknown.\" You always want to be working from a known good state, you know what I mean? It can be as stupid as you want it to be. \n\nMIKE: [laughs]\n\nWILL: As dumb, as useless, like, I've looked at a lot of blinking, red lights, bright in my heart. \n\nMIKE: [laughs]\n\nWILL: Like joy. Like, where I'm just like, look at that. Let's blink it, baby. Yeah, we're blinking. We're blinking hard. And I'm just like, is that it? That's what you did today? It's like, yeah, baby. Look at it [laughter]. If you're a real engineer, you're just like, ooh, that's a good blink. \n\nMIKE: [laughs]\n\nWILL: What does that mean? What [laughs] does that mean? What does that light flashing on and off signify in your brain? You know, what is that? It represents progress towards some goal, you know? But, like, yeah, just that stupid, easily that stupid. All day [laughs]. \n\nMIKE: You mentioned a blinking light. You say it represented something, signified something, right? You've got that [inaudible 16:18]. You've got something that you can actually wrap your head around. You can verify there is blinking light. I have power [laughs], and it is making something happen.\n\nWILL: We're blinking hard. We're blinking hard today, Mike [laughs]. \n\nMIKE: There is a project that was challenging to test because [laughter] there's a...and probably [laughs] anybody who's done this for very long, you probably have encountered this situation before. It's not unique. And you have a partner who doesn't have a sandbox, or they do, and it doesn't work very well. So, you try to test against this third party, and it just doesn't work right. Like, there's not a good ability to test against the API. And when we're running unit tests, we run into this all the time, and we just say \"No,\" right? There's no way you're going to run your unit test suite against the third-party service. And if you do, you're suffering because [laughs], you know, it's so unreliable.\n\nYou can't have reliable tests that actually test something if you're running against an unreliable service. And they'll be, like, 100 times slower, and all the problems with that. You know, you build. You mock it out, right? You build a fake service so you can test against that, and that's what you work with. But sometimes we don't think to do that when we're doing manual testing. Like, well, my unit test does it [inaudible 17:39] manual test. I need to test against the real thing. You know, I want to do an integration test. It has to be perfect. Instead of building the tool to test against.\n\nAnd, in this project, I regret, in retrospect, not pushing hard to say, \"Build the test service. Build the test service. It's going to save you so much time.\" People spun their wheels for hours and hours trying to get stuff done, trying to share a staging environment to test against this sandbox on the service that was sometimes up and sometimes down. Or if they had just had a service running locally that maybe wasn't perfect but it was pretty close to the third party, they could have saved themselves a lot of grief. \n\nWILL: Mm-hmm. Mm-hmm. Yeah. Yeah, absolutely. I mean, I will say that, like, a little...one of the things I've learned at Acima is the many blessings of the VCR gem. If anybody's listening who doesn't know about VCR, basically, all you do is you run your test suite against a, you know, a third-party, or external or, like, whatever, external API source, and you go out, and you hit the real API. And you save it. \n\nAnd then, you're testing against the real call, but you don't have to, like, go out and do all that every single time, you know. And you could configure it in various ways so that, like, you refresh the stuff, or you make sure it doesn't get stale, and stuff like that. Because, like, yeah, I want the real, real, you know. I don't trust any of you people. You guys are all liars. Engineers cannot be trusted [chuckles]. \n\nMIKE: It does give you...you get exactly the response, the real thing. But then you can save it so you don't have to hit them again. So, you get your reliable test. And you can build a service that will respond with that data and run it in your test environments. You can do some manual testing and stuff through the process. Why not? \n\nWILL: Like, I love my reverse proxy for mobile development, right? Mobile development against unstable APIs, shifting APIs, you know, like, I found something today, just today, and I just patched it. If every single thing failed on me, right, I'm hitting a bunch of endpoints, and I'm aggregating together, and, like, none of them should fail. And almost always, at least one of them would come back. But if every single endpoint that should never fail actually did fail, then it was taking down my whole...not my whole app, but my whole, like, page within the app. \n\nI made a jig, right? And I made a jig because I was in a hurry. And I was just like, I'm just going to take this API call and I'm going to, like, I'm going to butcher it so it could never fail, right? So, it's just going to fail all over the place. I'd, like, dug into the source code, and I'm just like, and you will die. Promise dot reject abort, you know what I mean? And then, fixing the problem was really easy because I was sort of refreshing, refreshing, refreshing, but I couldn't get this intermittent failure to go. Unfortunately, I work for a very large retailer, and I will get those millions of requests in the wild, you know, very quickly, you know. And so, anyway, make a jig [laughs].\n\nMIKE: I think Will hit on something critical, which is, you know, you build the support structure so that you can build these incremental pieces. One thing that we really haven't talked about is you get a project, and this happens at any scale, you know, whether it's something that takes two hours, something that takes two days, something that takes two months, something that takes two years. You've got this big thing, and you got to start somewhere. And I think that sometimes we want to see progress, so we just start somewhere, right [chuckles]? Let's chip away at something. And that's one way to do it. \n\nAnd going back to our starting, where we started this podcast, you can chip away here and there. You end up with a lot of this and that, but the whole thing doesn't move forward. I think you need to be really methodical about choosing what you do first. And it goes back to that jig idea. You have to have some sort of framework, mental framework, to map out how you're going to do the work. \n\nI'm thinking of another project that I worked on a few years ago. I had spent several weeks in meetings with product and business, and they were laying out these ideas. And mostly, what they had was mockups. It's like, this is what it's going to look like. But nowhere in there was anything about how it was actually going to work [chuckles]. And there were a lot of really big questions. You know, here's how it looks like in the user interface. But how on earth are you going to make this work behind the scenes? You know, go and work with whatever providers, and leave out the details. But, you know, you're going to need third-party data to make this work, and it's not trivial.\n\nAnd after doing this, I got together with a skilled product manager, and we sat down for a few hours and hashed out a roadmap and said, \"These are the milestones we need to hit.\" And that roadmap, more or less unchanged, ended up being how that project got done. It was on a really tight timeframe. We got it out in about three months, made it before Christmas, and you get the release. It wasn't the greatest product [laughs], but we got the thing done.\n\nAnd the problem was actually not our implementation as much as that we were trying out a new business idea that wasn't as good as, you know, as they'd hoped. It happens. The important thing is we got it done. And the only reason we got it done, instead of spending the next two of those three months in endless meetings talking about the user interface, is that we sat down and said, \"Well, what is the practical plan? What could we do first?\" \n\nAnd the thing that we could do first...and then, we went and actually talked to the business and said, \"What do you need first?\" \"We need to be able to accept a credit card payment,\" or whatever it was. And having that first thing opened the gate to do another thing. It's like Will's blinking lights or being able to play a pure tone sine wave [vocalization] [chuckles]. \n\nYou get that. You get something to play. You get something to start with. That zero to something is so much more than even the subsequent steps. Something to hang on is just wildly better [chuckles] than nothing. The zero to something is the biggest, hardest part. And getting that tangible sort of thing made a huge difference. And then, other people can start talking about, where do they fit in the process? You know, you can start coordinating across teams to figure out where they fit. And pretty soon, you have a project running. And you do that a lot. \n\nI've worked many projects like this. I'm working on one right now, where the very first thing we did is we sat down, laid down the roadmap, and the project's going well. It's going to be...other than some challenges dealing with a government entity that's just sort of slow [laughs], like, we're going to be on time, close to on budget, you know, it's just going to work out because we've mapped it out like that. \n\nYou see, the difference is really not that much. You know, you take a few hours and grapple with the problem and think about how to break it up, rather than getting overwhelmed and just chipping at something and getting one little piece. You're probably never going to make it very far. Now, chipping one little piece is better than nothing, but I think...well, maybe [laughs]. But I think that taking some time to analyze the problem and it's work, and figure out what comes first, and then what comes next, and then what comes next...well, where are your most risky pieces? Maybe you have some government entity you have to get something approved by. Well, you better get that done first. \n\nYou know, laying out an order of operations and doing those is just, I think, one of the most valuable things that we do. And I don't think I was, you know, I don't know that it's something they teach in school. They just expect you to know it. But I feel like that's something that ought to be just repeated over and over and over again. \n\nWILL: I couldn't possibly agree more. And I'll tell you, like, also, like, I mean, it's like, you know, sort of, like, in terms of, like, the tactical sort of, like, thrust and parry dealing with, like, business product, stakeholders, stuff like that. It is...how do I put it? Like, if you can distill a feature set down to, like, the absolute, absolute, absolute minimum, like, when you're faced with sort of, like, you know, a lot of demands, a lot of shifting demands, a lot of crazy deadlines, a lot of pushes, and stuff like that...And I understand that, like, what I'm saying here is just, like, plain vanilla, basic agile. But it's the kind of thing it's that's easy to say but very, very difficult to do. \n\nBut, like, the more you could distill it down to, like, just the basic core, raw functionality, and then, like, you add stuff on it, I found that when you get that sort of, like, that core workflow finished and you find yourself in a situation where it's like, hey, I'm not going to make this deadline, most product people, like, that I've dealt with, have been very practical, and pragmatic, and reasonable. If you give them something and you say like, \"Listen, I can do this other stuff, right, but it's going to push it by a month. Do you want me to do that?\" And then, they'll just be like, \"No,\" like, they can make a purchase. They could buy a widget. They can do this thing that they want to do.\n\nAnd, like, really distilling that down, finding the stuff, where it's like, oh, well, you know what? I'm not going to handle errors gracefully. Like, I'm just going to be, like, is it right? Cool. And then, you get the green check. Is it wrong? No. I'm bailing you out. I'm dumping the whole thing. I'm just dumping, right? No slickness, cleverness, anything. If you can give product scenarios like that, then I've found my ability to have an untroubled existence as an engineer while still maintaining a reputation for actually putting out products has, like, it's gotten so much better. \n\nI don't know, I mean, they get it, but, like, when it's not done, when they don't have a done thing that they can either invest more in or they can ship right now, then, like, that's when the sort of, like, the wish list grows, and grows, and grows, and grows, and grows because it's not finished, right? \n\nAnd this is real tactical stuff, but if it's done, and they have it, and they can either go to market, or they can delay. If you give them the choice, they almost always go to market. If you could give them something that works, they'll take it, but if you don't, then it's just like, oh, I got to have that. I got to have this. I have to have this feature. We couldn't possibly go without this feature because it's not something or nothing. It's nothing or another flavor of nothing, whatever. That's your problem, you know.\n\nMIKE: That, what you just said, you know [laughs], if you've got nothing, like, you imagine any kinds of nothing, and what you have is nothing. But if you have something, something, right, you can work with that. And maybe it's not enough to go to market with, but it's at least something you can talk about. \n\nLike you said, this goes back to the agile process. The core idea of agile software development is around communication loops. You want to have an iterative cycle rather than no cycle, you know, just planning upfront, build it, and then done. And you can only have that iterative loop if you actually have something to iterate on. And we've talked about this before a lot of times. \n\nYou look at aerospace [laughs] because it's big, and things blow up, and it's easy for us all to see. You look at what SpaceX has done to just absolutely dominate, not just, like, the U.S. market, but they launch more rockets than, like, the whole world put together. Like, the nation-state, right [laughs]? And it's because they have this very iterative process. You know, they're like, well, we're not going to build a perfect rocket. Let's build something that's maybe going to blow up, but at least it should be able to get off the ground, and we can measure some stuff on it. And they do that, and it probably blows up. \n\nBut they got those measurements, and then the next one gets a bit higher. And the willingness to let things blow up and to be interested in that interaction, right, in that iteration more than in the perfection, drives the costs wildly down. \n\nWILL: I'm actually really interested in, like, so one of the other Elon projects that I'm personally extremely interested in is, like, the full self-driving mode on the Tesla. And one of the things that I'm very, very interested in, in that capacity, is willingness to...I hate to say, like, blow up some rockets, but, like, willingness to put out a full self-driving automobile that is just a little bit better than a human, right? Because, I mean, we're all right. We're not great, you know, we're all right, you know.\n\nBut I think if General Motors, you know, or one of the large institutional players was going out and putting together a self-driving car, or even somebody like Google that has a lot to lose, I think they would and do really struggle with, sort of, like, something that's just better and not perfect, right? Like, no, I don't want it to be worse. I don't want it to be worse. That's not cool, you know what I mean? Like, we can't have, like, flying, like, battering rams just barreling down the freeway murdering people. Like, that's not okay. However, what if it's just, like, 20% better than a human, 20% safer than a human? Isn't that better? \n\nMIKE: That is better. \n\nWILL: You know? Anyway, I mean, and so I think that that mindset, I think is, I don't know, I'm interested to see how it goes out. Because, like, it's also one of those sort of things where it's like, you know, you're kind of, like, gambling with somebody else's life there a little bit, Elon. And move fast and break things is not meant to be taken quite so literally.\n\nMIKE: [laughs] That's an interesting one because to drive better than a human, you have to have superhuman skills, and let me explain what I mean. I'm going to have a very specific meaning that may not be what you're interpreting me to mean. And they call this the March of Nines. Have you heard this Match of Nines? If you want to have 90% accuracy, it takes a certain amount of work. And then, to get to 99% accuracy, you've only got one digit further, right? It's like ten times as much work. And to get one digit further, you know, 99.9, you got to do about ten times as much work, and so on. \n\nAnd each one of those is harder, and part of the reason for this is that you think about driving, and most of the time, driving is pretty boring. Most of the time, driving is pretty boring until the nearby zoo has an error, and then a kangaroo ends up jumping across the road in front of you. And to deal with that situation, you have to have the concept...well, maybe it's not even a kangaroo, right? You know, maybe it's something that you've never even seen before. I almost hit a possum the other day, literally almost hit a possum on my bicycle. And [laughs] had to slam on my brakes, or I would have run over the possum [laughter]. That's not something that happens every day, right? You don't every day go riding along and almost hit a possum. \n\nAnd I didn't necessarily need to recognize it was a possum, although it took me a moment before I realized what it was. You just have to know that there is something that is walking across the road, and I need to stop. But having that concept of an animal, and that it has direction, and knowing which way to steer because you can tell which direction it's going, and this is very much out of the norm, requires an understanding of a lot more than driving, right? You have to understand something about biology, and something about physics, and some other problems.\n\nWhat if the street sign's broken, and there's a police officer standing in the middle of the intersection, and they're waving people with their hand, and doing hand signals to say which way to go? Now, your car needs to not just understand traffic lights. They need to understand human gestures. And maybe the police officer is just yelling at you, \"Hey, please! Your turn. Go.\" Now, you have to understand human speech and have a microphone. \n\nLike, as you deal with more and more of these situations, there are situations that require human understanding because our world of driving is built around humans. And I've actually heard this talked about by self-driving engineers. It's on my mind. These roads are not designed for the machines. And so, the problem is a challenging one and challenging in ways, like, it's hard to measure. \n\nNow, this doesn't really go against what you were saying before. You may be able, like, because humans aren't that great at drivers, make the car 20% better, and then have, like, a data center somewhere where people are sitting there, and they'll take over. And they'll have a little camera and see, \"Oh, the police officer is waving. Okay, make the car go left, you know, and take over manually.\" I mean, you might have something like that where you actually take human control or give it back to the human and say, \"Hey, you know what? I'm not going to self-drive anymore. Your job.\" There are solutions like that where you just bail. \n\nWILL: I mean, honestly, like, what I think ought to be done, I mean, like, I don't know. I mean, like, everybody's sort of, like, dumping money into this intention of, like, you know, like, carving out their, like, little digital fiefdom monopoly thing. And I don't think transportation is, like, the kind of thing that can really support that kind of a capitalist enterprise because it's public good, you know? \n\nAnd so, I think it should be a public-private partnership, where we start creating roadways that have, you know, affordances built into them for self-driving cars. And, like, this is just me, but it goes right back to, like, what we've been talking about. What if your self-driving car was just good on the big streets? That's it. It's good on the big streets, you know what I mean? Like, get it to, like, a four-lane road, you know what I mean? Like, whatever your four-lane stoplight road is, you know what I mean? And you push a button, and you say, \"Bang it out. I'm watching Netflix,\" you know what I mean? And that's it. \n\nMIKE: [laughs]\n\nWILL: That's cool. That's cool. We're good. We're good, man. This is a good gig. Like, I could watch Netflix. I could check my email. I can do my stuff. I don't have to sweat the traffic jams on the highway. I don't have to sweat stop-and-go traffic. I'm cool. We're all right. And more over than that, you know what I mean? I could do even better than that. And I could just say like, hey, you know what? I got my e-bike. Like, I'm just going to go to the city bus...and my city bus, instead of being the bus, you know what I mean? \n\nSo, I have to, like, pedal, you know, a block or two to, like, my transit point, throw my e-bike on there. And then, it just takes me right to my office, and we're good to go, you know what I mean? And cars have gone away. We didn't solve the hard part. I don't need to know what...like, my car doesn't know what a zebra is. It doesn't care, you know what I mean? Like, I just built, you know, I built the car to deal with, like, you know what I mean? I bounded the problem, right, so that the self-driving stuff works. And I made the roadway in a way so that the self-driving stuff can, like, process it and, like, we're all good. Any true engineer is always looking to cheat.\n\nMIKE: [Chuckles] And that's been kind of the theme of the conversation, right? A good engineer as Will is interested in cheating. Don't freehand it. \n\nWILL: Don't freehand it, yeah.\n\nMIKE: Because that's a solvable problem [laughs]. But you can take away the human element, and then you have a different problem that's solvable. \n\nWILL: Exactly. Yeah. My hand shakes just as much as yours does. That's why I made a jig, and that circle is flawless every time. I can make a thousand of them, and each one would be just as perfect as the last. \n\nMIKE: Well, that feels like it kind of ties things up, doesn't it [laughs]? \n\nWILL: I love it [laughs]. \n\nMIKE: We went from solving our everyday problems to dealing with the big problems of the world. And they have the same constraints. We will close this up. Thank you, all, for listening. And, you know, build a jig [laughs]. \n\nWILL: Build a jig. \n\nMIKE: Build a jig. \n\nWILL: Good engineers cheat. Build a jig [laughs].","content_html":"In this episode of the Acima Development Podcast, Mike and the team delve into the importance of breaking down projects into manageable iterations to avoid stagnation and inefficiency. Mike shares a story about a past experience with a developer who struggled to produce releasable code, which led to the realization that breaking projects into smaller milestones can significantly enhance workflow and productivity. This approach allows for continuous integration and deployment, preventing the team from getting stuck on incomplete tasks. Mike emphasizes that this skill of breaking down work is crucial yet often overlooked in engineering education.
\n\nWill adds to the discussion by highlighting the value of creating "jigs" or scaffolding in both woodworking and software development. He explains that in his experience, especially with mobile app development, creating temporary structures or mockups can facilitate progress even when back-end systems are not fully ready. This method allows for continuous progress and testing, making it easier to adapt and iterate on the final product. Will’s anecdote about using a reverse proxy to simulate API endpoints underlines the practicality and effectiveness of this approach.
\n\nThe conversation wraps up with broader reflections on iterative development and its applications in various fields, including aerospace and automotive technology. The team discusses how companies like SpaceX have revolutionized their industries through iterative processes, emphasizing the importance of starting with a functional but imperfect product and continuously improving it. They conclude by stressing the necessity of having a clear roadmap and the willingness to "cheat" by using tools and frameworks to eliminate human error, thus ensuring consistent and reliable outcomes. The episode ends with the advice to always build a jig and embrace iterative development for better efficiency and success in engineering projects.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm hosting again today. With me, I have Will, Ramses, and Eddy. I have a story I'm going to tell before I introduce the topic, and I think about this a lot. I was thinking about it this morning. I think I thought about it yesterday. I think about it probably at least monthly about..., and I've probably even shared it on the podcast before [laughs].
\n\nBut several years ago, I worked with a developer who was assigned to a project. We had talked about it as a team. We were all really excited about it. We had this new idea. It was kind of a developer-driven initiative. They worked on a little bit here, a little bit there, and a [chuckles] little bit over there. And this kept on going for, like, a month, and we thought that, you know, in a month, you'd have some code out. And looked at it, and there was kind of a framework or something there but there was nothing that was releasable. There were just pieces here and there, and it really felt like it stalled.
\n\nNow, they'd been working on this day in and day out for weeks, but nothing had made it into production. And in a continuous integration, continuous deployment environment where you can get stuff out there piece by piece, that was unusual. And I thought, you know, what's going on here? And I consider this a failing on my side. And I thought about it, so what am I doing wrong here?
\n\nBut I think there's some maturity in career experience here for this developer. They hadn't learned how to take a project and break it down into iterations. I worked with the team to do that. And I say I worked with the...we kind of talked about this idea, and the team jumped in, you know, and I was just a minor player. But as they became aware of that, it completely changed the workflow of the team I was working in, where everybody focused on, well, how do I break this up into milestones? And, on a large scale, like, having a big project, how to break it up into milestones, and then, a small scale, developers are breaking up.
\n\nI had one developer come onto the team who made it like a singular focus. They'd come from another company where they spent, like, months on something [laughs] before they released it, and now they spend, like, multiple pull requests a day. And it's like their life is totally changed, and they're completely happier [laughs] because they've completely changed their workflow. They really embraced this and became kind of an evangelist. And I've seen it; I've seen this just be so successful for people who do this. And even for teams that get good at breaking things up, versus people who just stall for weeks or months. I've seen other...and that's certainly not the only instance I've seen. I just saw that one change, and then that developer became successful.
\n\nI've seen other scenarios where somebody jumps into something, you know, a challenging problem, and they spin, and they spin, and they spin, and they get weeks in, and then farther in, and just never get anywhere [laughs]. And it's frustrating for the person who's doing it. And there's a few things that feel worse than being deep in a problem you just can't solve it. And you just feel like there's no light at the end of the tunnel. It's frustrating for everybody who's working around them. It's frustrating for everybody.
\n\nLike I said, I think about this over and over again because I feel like it's one of the big skills in engineering that nobody really teaches, and that's a problem. It's just breaking up work. How do you break up work? And that's our topic today is, you know, how do you break up work, and why?
\n\nWILL: The North Star, for me...I do kind of want to pull on this a little bit because I've done stuff that just doesn't work like this, right? I mean, like, most of the business development, product ticket stuff that we work with can be addressed in this way. And then, basically, it's just sort of, like, what can you get out into someone's hands? And I would say, like, I don't know how to translate...I don't know how to segue in this, right? But, like, get it out into people's hands, right? And the thing that I think tends to jam people up is, maybe it's just me, but I think other people as well, is, like, you got to be okay with sort of like, let's call it, like, call it actual construction, right, where we're woodworking, or something like that.
\n\nYou have to be okay making a jig for something, right? You have to be okay making scaffolding for something, right? Where I'm going to build this entire structure, right? Entire structure. But it isn't actually ever going to go out. Like, I'm building it so that I can do the small steps. So, one of the things I'm working on, right, not at Acima, at another very large retailer, is that I work on a mobile app, right? And so, the thing about the mobile app is a lot of the time, we're front-running the back-end API stuff, right? And so, what I'll do is I will scaffold out all kinds of stuff. I'll go and I'll negotiate back and forth with the back-end team, and I'll say like, "Okay, okay. Well, what's the data going to look like?" And they'll say, like, "Okay, it's going to look like this," right?
\n\nSo, we'll do a contract, right? Which is just a contract. It's just aspirational, right? This is pure vaporware. But I'll get the contract going, and then I'll start charging ahead, right? And I'll just be like, okay, mock data, you know what I mean? Promise that's going to result to this thing, right? And then, I use a tool. It's a reverse proxy. And I can use that to create, like, a fake API endpoint, right? Where it's like, if you go to this API, this URL, it's going to give you back [vocalization], right? It's going to give you just...it's going to serve up this static file, right?
\n\nAnd now, oh, okay, now I'm making, like, real API requests to fake API, right? And all this stuff is junk, right? It's junk. It'll never go live. But I can actually release the thing. It is real stuff. It might even really be on the server hidden behind, like, some feature flag wall, right? And so, it's out. It's in production. It exists. It's a real thing. But, also, no, it's not, right? It's walled off, and it requires, like, all this fake stuff. I'm like, hey, hey, you know what?
\n\nAnd I'll tell you, like, honestly, like, I have hit on a contract before, but I am much more likely to miss on something. And it's like, oh, well, I have to go to the pricing and availability service, so it's going to be here. And I have to make another call. This JSON's going to...and you know what? It's fine. It's fine. I will have to go back and rework, but parsing Jason is really not that hard. In the end of things, it's really not that hard to parse some JSON. And so, like, you know, and then you'll go back.
\n\nBut, like, if I wanted to do it, like, the quote, unquote "right way," and get it a hundred percent, then I would have all of these sort of, like, blocking features, where I can't move until the feature's done. I can't move until this is done. I can't move until this is done. And I'm just like, eh, F it. Let's roll. And so, you just do it that way, right? And so, you're making assumptions, making trade-offs, debating stuff, and scaffolding, and, like, you know what I mean, going with prototypes. But you're always putting something out into the world. And that has been very, very, very successful. And it's allowed them to get things out at a pace that they ordinarily just...there's no way [laughs]. There's no way.
\n\nMIKE: Yeah, it's interesting you mentioned the woodworking. My dad spent most of his career as a professional woodworker. That is exactly what [laughs] they spent most of their time on was: building those jigs, building the tooling to actually do what you needed. I don't know how much time my dad spent building tools. He still...he makes tools. Like, he'll see a problem. He'll go and make a tool because that's how he thinks now [laughs].
\n\nAbout ten years ago, my brother-in-law was showing him some grips for a handgun. My dad's never been, like, a huge gun enthusiast, but he saw that as a problem. He got curious about it, and he went and built a jig and made grips. And it turns out they were better than most of the stuff on the market. And he ended up doing it as kind of a side project hobby that kind of made him a living for several years [laughter] because he took the time to make that jig. Like, I don't really even hear that word outside of that industry, you know, outside of woodworking, but that's the word they use. And it's not exactly a tool, right? It's like a template.
\n\nWILL: Yeah. Yeah. Like a template. So, for people who are not necessarily, like, wood butcher nerds...so, I'll give you an example, right? So, a guy I know he made this really beautiful grill table, right? And you could think of it like an outdoor kitchen table with this circular hole, and his grill goes in the middle. And you've got, like, your whole cook surface out there, and it's super, super cool. And I looked at it, right, and it's like, it's this beautiful table. His grill goes right on the side, and you could do all this stuff.
\n\nBut, like, what he did is he had this beautiful three-foot circular hole for his grill to go on, right? One does not just cut a perfect three-foot circular hole. Like, one does not just walk into Mordor or cut a perfect circle [chuckles] in a butcher block countertop. And so, I was like, "Oh, what did you do," right? Well, he created this, like, not exactly, like, a router. The router was a part of it, but, like, it was this thing to hold the tabletop in place. And he had, like, a thing, and it had an arm that it swung out, and the router cut this perfect circle. But he built, like, a scaffolding machine so that he could cut this perfect circle because you couldn't possibly do that by hand precisely.
\n\nI might have dogged it and done it with like a, you know, done it with, like, a jigsaw and then just, like, put a little trim over it, like, a little metal, [laughter] like, a fat metal piece of trim, like, that big. And it's just like, ah, it's bad, but you can't see it, so who cares? So, that's what a jig is, you know what I mean? Like, it holds the work in place so that you can work on it effectively and precisely a lot of the time. Because if you just try and freehand it, you're screwed. That's why [inaudible 10:07] shop projects, you know what I mean? Like, when you did woodshop, if you did woodshop, they all look terrible because...
\n\nMIKE: [laughs] Right.
\n\nWILL: Because you tried to freehand it. You're just like, oh, well, let's just cut this. And I'm like, no, no, no, no [laughs]. You get something to hold it precisely so that you have a template, and you can do everything perfectly.
\n\nMIKE: No, that's exactly it. The professionals, it's not that they're better at freehanding it, although they might be, is they don't trust themselves to freehand it.
\n\nWILL: Exactly.
\n\nMIKE: And so, they don't [laughs]. They build a system so that they eliminate the human mistake. That completely changes it, and that's how you end up with a quality piece of work. It's such a perfect analogy. You take the time to build the jig, you know, to build the scaffolding, to build the framework that allows you to test and deploy independently a component without necessarily having the other pieces in place. And without that, though, you're blocked, right? Because there's always going to be some other thing that you're working with.
\n\nWhat we do [chuckles] is we read data from one place, and we transform it, and we write it somewhere else. That's what we do for a living. If your data sources aren't ready yet, then you're blocked, unless you define a contract and you code to that. And then you say...you have some sort of test harness that you can test against that contract, knowing what they have may not be ready yet. And you might even have the wrong contract. You might have to make some changes later, but at least you'll have something that you can make tweaks to rather than having to start from scratch.
\n\nWILL: I think it's a good rule of thumb. I think it's a good rubric. Although I have been involved in projects where, like, you know what I mean, things were...you had to do...actually, you know what, honestly, I think I've always done that. I haven't always had the latitude to, like, front-run as much as I wanted to. Like, one of the things that I did, like, way back in the day, is I did a bunch of audio processing stuff, right, for phones and stuff like that back when, like, you know, the world was new on the iPhone. And I would do audio processing.
\n\nAnd the thing about audio processing is audio processing, like, there's not a lot of, like, intermediate steps. You really got to, like, you got to kind of, like, do the whole thing. You know, like, you have to have, like, the machine has to, like, do finished products. But, like, honestly, like, I still did the same thing. I mean, in that I would just make it play a song. I was like, oh, I can't play a song, right? Because, like, okay, oh, you want to play a song, right? Well, I had to have all kinds of stuff.
\n\nI had to have, like, a wave decoder, and then a wave, you know what I mean, like, a wave consumer, and stuff like that. And so, I was like, oh, that's too hard. I'll just make a sine wave because I could do that in math. I could do that mathematically. That's a mathematical function, right? Then I don't have to have codecs or anything like that. And then, I did that. And I was like, oh, okay, I did that. Okay. And now, I'll do a wave. Okay. Now I'll do a wave, right? It's like, okay, now I'll do an MP3 into a wave into, like, the speaker. I was like, okay, now I did that.
\n\nNow, I will take the MP3 into a wave. I'll capture the audio and do nothing, right? Nothing, just a hand, just passing it through, right? And it'll go out. And then, I'll, you know, and then I'll just do, you know, something else, and then, you know what I mean? And so, I would, you know, just kind of do stuff like that.
\n\nMIKE: But the process, like, even if you're not releasing it, in order to be able to...and this ties into testing, it seems like, right? Like, you mentioned the testing. At every step, you're doing something that you could verify. You wanted something that was kind of tangible. And I know none of this is purely tangible, but it was...the closest you're going to get to tangible is something...like, it was making it into sound that was making it into your ears. There was something that you could measure that you could validate on. And once you have that, you could build around it.
\n\nWILL: Yeah. Yeah. And I built all kinds of jigs. One thing that I did is I was...so, we were working on, like, continuous DJ mixes, right? And so, it was a bunch of MP3s that were encoded and recorded, you know, in such a way so that there would be a continuous stream of music. So, it'd go play from track one to track two to track three to track four to track five. You would never hear a transition, right? You could do that. But I was transforming and manipulating the stuff, right?
\n\nAnd so, like, when it would go over, it would pop. It would be a hitch. And I was trying to debug that one particular thing. And I was like, ah, like, my ADD brain won't let me sit and wait for the thing to roll over. So, I was just like, okay, I'm going to make a jig so that I just jump in five seconds before it ends. And then, I'll play through the transition, and I'll go and do five seconds again, and then I'll, you know, and that's how that goes through the song.
\n\nSo, I'm only doing, like, the specific part that I want to see because I don't have time for all that, you know? It's just jigs. Just that's a way of doing it, I guess. My dad always taught me...my dad was an engineer, not a woodworker, but he always said, "Go from the known to the unknown." You always want to be working from a known good state, you know what I mean? It can be as stupid as you want it to be.
\n\nMIKE: [laughs]
\n\nWILL: As dumb, as useless, like, I've looked at a lot of blinking, red lights, bright in my heart.
\n\nMIKE: [laughs]
\n\nWILL: Like joy. Like, where I'm just like, look at that. Let's blink it, baby. Yeah, we're blinking. We're blinking hard. And I'm just like, is that it? That's what you did today? It's like, yeah, baby. Look at it [laughter]. If you're a real engineer, you're just like, ooh, that's a good blink.
\n\nMIKE: [laughs]
\n\nWILL: What does that mean? What [laughs] does that mean? What does that light flashing on and off signify in your brain? You know, what is that? It represents progress towards some goal, you know? But, like, yeah, just that stupid, easily that stupid. All day [laughs].
\n\nMIKE: You mentioned a blinking light. You say it represented something, signified something, right? You've got that [inaudible 16:18]. You've got something that you can actually wrap your head around. You can verify there is blinking light. I have power [laughs], and it is making something happen.
\n\nWILL: We're blinking hard. We're blinking hard today, Mike [laughs].
\n\nMIKE: There is a project that was challenging to test because [laughter] there's a...and probably [laughs] anybody who's done this for very long, you probably have encountered this situation before. It's not unique. And you have a partner who doesn't have a sandbox, or they do, and it doesn't work very well. So, you try to test against this third party, and it just doesn't work right. Like, there's not a good ability to test against the API. And when we're running unit tests, we run into this all the time, and we just say "No," right? There's no way you're going to run your unit test suite against the third-party service. And if you do, you're suffering because [laughs], you know, it's so unreliable.
\n\nYou can't have reliable tests that actually test something if you're running against an unreliable service. And they'll be, like, 100 times slower, and all the problems with that. You know, you build. You mock it out, right? You build a fake service so you can test against that, and that's what you work with. But sometimes we don't think to do that when we're doing manual testing. Like, well, my unit test does it [inaudible 17:39] manual test. I need to test against the real thing. You know, I want to do an integration test. It has to be perfect. Instead of building the tool to test against.
\n\nAnd, in this project, I regret, in retrospect, not pushing hard to say, "Build the test service. Build the test service. It's going to save you so much time." People spun their wheels for hours and hours trying to get stuff done, trying to share a staging environment to test against this sandbox on the service that was sometimes up and sometimes down. Or if they had just had a service running locally that maybe wasn't perfect but it was pretty close to the third party, they could have saved themselves a lot of grief.
\n\nWILL: Mm-hmm. Mm-hmm. Yeah. Yeah, absolutely. I mean, I will say that, like, a little...one of the things I've learned at Acima is the many blessings of the VCR gem. If anybody's listening who doesn't know about VCR, basically, all you do is you run your test suite against a, you know, a third-party, or external or, like, whatever, external API source, and you go out, and you hit the real API. And you save it.
\n\nAnd then, you're testing against the real call, but you don't have to, like, go out and do all that every single time, you know. And you could configure it in various ways so that, like, you refresh the stuff, or you make sure it doesn't get stale, and stuff like that. Because, like, yeah, I want the real, real, you know. I don't trust any of you people. You guys are all liars. Engineers cannot be trusted [chuckles].
\n\nMIKE: It does give you...you get exactly the response, the real thing. But then you can save it so you don't have to hit them again. So, you get your reliable test. And you can build a service that will respond with that data and run it in your test environments. You can do some manual testing and stuff through the process. Why not?
\n\nWILL: Like, I love my reverse proxy for mobile development, right? Mobile development against unstable APIs, shifting APIs, you know, like, I found something today, just today, and I just patched it. If every single thing failed on me, right, I'm hitting a bunch of endpoints, and I'm aggregating together, and, like, none of them should fail. And almost always, at least one of them would come back. But if every single endpoint that should never fail actually did fail, then it was taking down my whole...not my whole app, but my whole, like, page within the app.
\n\nI made a jig, right? And I made a jig because I was in a hurry. And I was just like, I'm just going to take this API call and I'm going to, like, I'm going to butcher it so it could never fail, right? So, it's just going to fail all over the place. I'd, like, dug into the source code, and I'm just like, and you will die. Promise dot reject abort, you know what I mean? And then, fixing the problem was really easy because I was sort of refreshing, refreshing, refreshing, but I couldn't get this intermittent failure to go. Unfortunately, I work for a very large retailer, and I will get those millions of requests in the wild, you know, very quickly, you know. And so, anyway, make a jig [laughs].
\n\nMIKE: I think Will hit on something critical, which is, you know, you build the support structure so that you can build these incremental pieces. One thing that we really haven't talked about is you get a project, and this happens at any scale, you know, whether it's something that takes two hours, something that takes two days, something that takes two months, something that takes two years. You've got this big thing, and you got to start somewhere. And I think that sometimes we want to see progress, so we just start somewhere, right [chuckles]? Let's chip away at something. And that's one way to do it.
\n\nAnd going back to our starting, where we started this podcast, you can chip away here and there. You end up with a lot of this and that, but the whole thing doesn't move forward. I think you need to be really methodical about choosing what you do first. And it goes back to that jig idea. You have to have some sort of framework, mental framework, to map out how you're going to do the work.
\n\nI'm thinking of another project that I worked on a few years ago. I had spent several weeks in meetings with product and business, and they were laying out these ideas. And mostly, what they had was mockups. It's like, this is what it's going to look like. But nowhere in there was anything about how it was actually going to work [chuckles]. And there were a lot of really big questions. You know, here's how it looks like in the user interface. But how on earth are you going to make this work behind the scenes? You know, go and work with whatever providers, and leave out the details. But, you know, you're going to need third-party data to make this work, and it's not trivial.
\n\nAnd after doing this, I got together with a skilled product manager, and we sat down for a few hours and hashed out a roadmap and said, "These are the milestones we need to hit." And that roadmap, more or less unchanged, ended up being how that project got done. It was on a really tight timeframe. We got it out in about three months, made it before Christmas, and you get the release. It wasn't the greatest product [laughs], but we got the thing done.
\n\nAnd the problem was actually not our implementation as much as that we were trying out a new business idea that wasn't as good as, you know, as they'd hoped. It happens. The important thing is we got it done. And the only reason we got it done, instead of spending the next two of those three months in endless meetings talking about the user interface, is that we sat down and said, "Well, what is the practical plan? What could we do first?"
\n\nAnd the thing that we could do first...and then, we went and actually talked to the business and said, "What do you need first?" "We need to be able to accept a credit card payment," or whatever it was. And having that first thing opened the gate to do another thing. It's like Will's blinking lights or being able to play a pure tone sine wave [vocalization] [chuckles].
\n\nYou get that. You get something to play. You get something to start with. That zero to something is so much more than even the subsequent steps. Something to hang on is just wildly better [chuckles] than nothing. The zero to something is the biggest, hardest part. And getting that tangible sort of thing made a huge difference. And then, other people can start talking about, where do they fit in the process? You know, you can start coordinating across teams to figure out where they fit. And pretty soon, you have a project running. And you do that a lot.
\n\nI've worked many projects like this. I'm working on one right now, where the very first thing we did is we sat down, laid down the roadmap, and the project's going well. It's going to be...other than some challenges dealing with a government entity that's just sort of slow [laughs], like, we're going to be on time, close to on budget, you know, it's just going to work out because we've mapped it out like that.
\n\nYou see, the difference is really not that much. You know, you take a few hours and grapple with the problem and think about how to break it up, rather than getting overwhelmed and just chipping at something and getting one little piece. You're probably never going to make it very far. Now, chipping one little piece is better than nothing, but I think...well, maybe [laughs]. But I think that taking some time to analyze the problem and it's work, and figure out what comes first, and then what comes next, and then what comes next...well, where are your most risky pieces? Maybe you have some government entity you have to get something approved by. Well, you better get that done first.
\n\nYou know, laying out an order of operations and doing those is just, I think, one of the most valuable things that we do. And I don't think I was, you know, I don't know that it's something they teach in school. They just expect you to know it. But I feel like that's something that ought to be just repeated over and over and over again.
\n\nWILL: I couldn't possibly agree more. And I'll tell you, like, also, like, I mean, it's like, you know, sort of, like, in terms of, like, the tactical sort of, like, thrust and parry dealing with, like, business product, stakeholders, stuff like that. It is...how do I put it? Like, if you can distill a feature set down to, like, the absolute, absolute, absolute minimum, like, when you're faced with sort of, like, you know, a lot of demands, a lot of shifting demands, a lot of crazy deadlines, a lot of pushes, and stuff like that...And I understand that, like, what I'm saying here is just, like, plain vanilla, basic agile. But it's the kind of thing it's that's easy to say but very, very difficult to do.
\n\nBut, like, the more you could distill it down to, like, just the basic core, raw functionality, and then, like, you add stuff on it, I found that when you get that sort of, like, that core workflow finished and you find yourself in a situation where it's like, hey, I'm not going to make this deadline, most product people, like, that I've dealt with, have been very practical, and pragmatic, and reasonable. If you give them something and you say like, "Listen, I can do this other stuff, right, but it's going to push it by a month. Do you want me to do that?" And then, they'll just be like, "No," like, they can make a purchase. They could buy a widget. They can do this thing that they want to do.
\n\nAnd, like, really distilling that down, finding the stuff, where it's like, oh, well, you know what? I'm not going to handle errors gracefully. Like, I'm just going to be, like, is it right? Cool. And then, you get the green check. Is it wrong? No. I'm bailing you out. I'm dumping the whole thing. I'm just dumping, right? No slickness, cleverness, anything. If you can give product scenarios like that, then I've found my ability to have an untroubled existence as an engineer while still maintaining a reputation for actually putting out products has, like, it's gotten so much better.
\n\nI don't know, I mean, they get it, but, like, when it's not done, when they don't have a done thing that they can either invest more in or they can ship right now, then, like, that's when the sort of, like, the wish list grows, and grows, and grows, and grows, and grows because it's not finished, right?
\n\nAnd this is real tactical stuff, but if it's done, and they have it, and they can either go to market, or they can delay. If you give them the choice, they almost always go to market. If you could give them something that works, they'll take it, but if you don't, then it's just like, oh, I got to have that. I got to have this. I have to have this feature. We couldn't possibly go without this feature because it's not something or nothing. It's nothing or another flavor of nothing, whatever. That's your problem, you know.
\n\nMIKE: That, what you just said, you know [laughs], if you've got nothing, like, you imagine any kinds of nothing, and what you have is nothing. But if you have something, something, right, you can work with that. And maybe it's not enough to go to market with, but it's at least something you can talk about.
\n\nLike you said, this goes back to the agile process. The core idea of agile software development is around communication loops. You want to have an iterative cycle rather than no cycle, you know, just planning upfront, build it, and then done. And you can only have that iterative loop if you actually have something to iterate on. And we've talked about this before a lot of times.
\n\nYou look at aerospace [laughs] because it's big, and things blow up, and it's easy for us all to see. You look at what SpaceX has done to just absolutely dominate, not just, like, the U.S. market, but they launch more rockets than, like, the whole world put together. Like, the nation-state, right [laughs]? And it's because they have this very iterative process. You know, they're like, well, we're not going to build a perfect rocket. Let's build something that's maybe going to blow up, but at least it should be able to get off the ground, and we can measure some stuff on it. And they do that, and it probably blows up.
\n\nBut they got those measurements, and then the next one gets a bit higher. And the willingness to let things blow up and to be interested in that interaction, right, in that iteration more than in the perfection, drives the costs wildly down.
\n\nWILL: I'm actually really interested in, like, so one of the other Elon projects that I'm personally extremely interested in is, like, the full self-driving mode on the Tesla. And one of the things that I'm very, very interested in, in that capacity, is willingness to...I hate to say, like, blow up some rockets, but, like, willingness to put out a full self-driving automobile that is just a little bit better than a human, right? Because, I mean, we're all right. We're not great, you know, we're all right, you know.
\n\nBut I think if General Motors, you know, or one of the large institutional players was going out and putting together a self-driving car, or even somebody like Google that has a lot to lose, I think they would and do really struggle with, sort of, like, something that's just better and not perfect, right? Like, no, I don't want it to be worse. I don't want it to be worse. That's not cool, you know what I mean? Like, we can't have, like, flying, like, battering rams just barreling down the freeway murdering people. Like, that's not okay. However, what if it's just, like, 20% better than a human, 20% safer than a human? Isn't that better?
\n\nMIKE: That is better.
\n\nWILL: You know? Anyway, I mean, and so I think that that mindset, I think is, I don't know, I'm interested to see how it goes out. Because, like, it's also one of those sort of things where it's like, you know, you're kind of, like, gambling with somebody else's life there a little bit, Elon. And move fast and break things is not meant to be taken quite so literally.
\n\nMIKE: [laughs] That's an interesting one because to drive better than a human, you have to have superhuman skills, and let me explain what I mean. I'm going to have a very specific meaning that may not be what you're interpreting me to mean. And they call this the March of Nines. Have you heard this Match of Nines? If you want to have 90% accuracy, it takes a certain amount of work. And then, to get to 99% accuracy, you've only got one digit further, right? It's like ten times as much work. And to get one digit further, you know, 99.9, you got to do about ten times as much work, and so on.
\n\nAnd each one of those is harder, and part of the reason for this is that you think about driving, and most of the time, driving is pretty boring. Most of the time, driving is pretty boring until the nearby zoo has an error, and then a kangaroo ends up jumping across the road in front of you. And to deal with that situation, you have to have the concept...well, maybe it's not even a kangaroo, right? You know, maybe it's something that you've never even seen before. I almost hit a possum the other day, literally almost hit a possum on my bicycle. And [laughs] had to slam on my brakes, or I would have run over the possum [laughter]. That's not something that happens every day, right? You don't every day go riding along and almost hit a possum.
\n\nAnd I didn't necessarily need to recognize it was a possum, although it took me a moment before I realized what it was. You just have to know that there is something that is walking across the road, and I need to stop. But having that concept of an animal, and that it has direction, and knowing which way to steer because you can tell which direction it's going, and this is very much out of the norm, requires an understanding of a lot more than driving, right? You have to understand something about biology, and something about physics, and some other problems.
\n\nWhat if the street sign's broken, and there's a police officer standing in the middle of the intersection, and they're waving people with their hand, and doing hand signals to say which way to go? Now, your car needs to not just understand traffic lights. They need to understand human gestures. And maybe the police officer is just yelling at you, "Hey, please! Your turn. Go." Now, you have to understand human speech and have a microphone.
\n\nLike, as you deal with more and more of these situations, there are situations that require human understanding because our world of driving is built around humans. And I've actually heard this talked about by self-driving engineers. It's on my mind. These roads are not designed for the machines. And so, the problem is a challenging one and challenging in ways, like, it's hard to measure.
\n\nNow, this doesn't really go against what you were saying before. You may be able, like, because humans aren't that great at drivers, make the car 20% better, and then have, like, a data center somewhere where people are sitting there, and they'll take over. And they'll have a little camera and see, "Oh, the police officer is waving. Okay, make the car go left, you know, and take over manually." I mean, you might have something like that where you actually take human control or give it back to the human and say, "Hey, you know what? I'm not going to self-drive anymore. Your job." There are solutions like that where you just bail.
\n\nWILL: I mean, honestly, like, what I think ought to be done, I mean, like, I don't know. I mean, like, everybody's sort of, like, dumping money into this intention of, like, you know, like, carving out their, like, little digital fiefdom monopoly thing. And I don't think transportation is, like, the kind of thing that can really support that kind of a capitalist enterprise because it's public good, you know?
\n\nAnd so, I think it should be a public-private partnership, where we start creating roadways that have, you know, affordances built into them for self-driving cars. And, like, this is just me, but it goes right back to, like, what we've been talking about. What if your self-driving car was just good on the big streets? That's it. It's good on the big streets, you know what I mean? Like, get it to, like, a four-lane road, you know what I mean? Like, whatever your four-lane stoplight road is, you know what I mean? And you push a button, and you say, "Bang it out. I'm watching Netflix," you know what I mean? And that's it.
\n\nMIKE: [laughs]
\n\nWILL: That's cool. That's cool. We're good. We're good, man. This is a good gig. Like, I could watch Netflix. I could check my email. I can do my stuff. I don't have to sweat the traffic jams on the highway. I don't have to sweat stop-and-go traffic. I'm cool. We're all right. And more over than that, you know what I mean? I could do even better than that. And I could just say like, hey, you know what? I got my e-bike. Like, I'm just going to go to the city bus...and my city bus, instead of being the bus, you know what I mean?
\n\nSo, I have to, like, pedal, you know, a block or two to, like, my transit point, throw my e-bike on there. And then, it just takes me right to my office, and we're good to go, you know what I mean? And cars have gone away. We didn't solve the hard part. I don't need to know what...like, my car doesn't know what a zebra is. It doesn't care, you know what I mean? Like, I just built, you know, I built the car to deal with, like, you know what I mean? I bounded the problem, right, so that the self-driving stuff works. And I made the roadway in a way so that the self-driving stuff can, like, process it and, like, we're all good. Any true engineer is always looking to cheat.
\n\nMIKE: [Chuckles] And that's been kind of the theme of the conversation, right? A good engineer as Will is interested in cheating. Don't freehand it.
\n\nWILL: Don't freehand it, yeah.
\n\nMIKE: Because that's a solvable problem [laughs]. But you can take away the human element, and then you have a different problem that's solvable.
\n\nWILL: Exactly. Yeah. My hand shakes just as much as yours does. That's why I made a jig, and that circle is flawless every time. I can make a thousand of them, and each one would be just as perfect as the last.
\n\nMIKE: Well, that feels like it kind of ties things up, doesn't it [laughs]?
\n\nWILL: I love it [laughs].
\n\nMIKE: We went from solving our everyday problems to dealing with the big problems of the world. And they have the same constraints. We will close this up. Thank you, all, for listening. And, you know, build a jig [laughs].
\n\nWILL: Build a jig.
\n\nMIKE: Build a jig.
\n\nWILL: Good engineers cheat. Build a jig [laughs].
","summary":"","date_published":"2024-06-26T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/905124ad-399d-4310-b4c8-dff5e4372df0.mp3","mime_type":"audio/mpeg","size_in_bytes":22687692,"duration_in_seconds":2282}]},{"id":"003f19ed-16fc-4295-82ec-3f92d98ce964","title":"Episode 48: Strategies and Pitfalls of Estimation","url":"https://acima-development.fireside.fm/48","content_text":"In this episode of the Acima Development Podcast, Mike and the panel talk about the intricacies of project estimation, sharing personal anecdotes and professional experiences. Mike begins with a story from his childhood, illustrating how his father's ability to estimate distances accurately influenced his understanding of estimation as a skill that can be developed with practice. He draws parallels between estimating physical distances and estimating project timelines, emphasizing the importance of breaking down tasks into smaller, manageable pieces to improve accuracy.\n\nThe conversation transitions to discussing the best practices for project estimation within engineering teams. Matt and Justin highlight the effectiveness of comparing new tasks to similar past projects and the necessity of having a stable team to ensure consistent delivery. They stress the importance of planning in small increments and maintaining clear communication among team members to mitigate risks and handle scope changes efficiently. Mike adds that understanding and identifying unknowns early in the process is crucial for making realistic estimates and avoiding common cognitive biases that can lead to significant project delays and budget overruns.\n\nTowards the end, the team explores the challenges of maintaining estimation accuracy during organizational changes, such as team reassignments and company-wide reorgs. Will raises concerns about the impact of these changes on planning bandwidth and overall productivity. The group agrees that preserving team dynamics and ensuring clear lines of communication are essential to minimizing disruption. They discuss the importance of having documented rules and metrics at every planning level to measure effectiveness and ensure alignment with business goals. The episode concludes with a reflection on the necessity of disciplined planning and continuous improvement to successfully manage complex engineering projects.\n\nTranscript:\n\n MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I have with me here Will, Justin, Eddy, and Matt. And we're going to be talking today about strategies and pitfalls in estimation. I'm going to start with just a story from my childhood. \n\nWe were talking in the pre-recording for a bit about math. I was remembering that my dad used to ask math-related questions to me and my siblings and make a game out of it. Like, he wasn't, like, grumpy, or pushy, or anything. He was like, \"What do you think of this?\" And then, we'd think about it. This is on road trips. He'd always do it on road trips. Like, that's the only time I ever remember this happening [laughs]. You know, you're on a road trip back in the long ago era before there was internet in your car [laughs]. And you had to do something to fill the space. \n\nI remember that there was mountain ranges, and he'd pick a landmark. You know, there'd be, like, this mountain. \"How far away do you think that is? Guess.\" And my dad was always right. And all of us were wildly wrong [laughter]. He was always really close. My dad's a carpenter. He's very, very good at recognizing distances. Like, he can look at something 15 inches long. He'll look at it and say, \"That's 15 inches [laughs].\" And he's right. You know, he's as good as a ruler [laughs]. \n\nHe's just really good at that perception, you know, distance perception. But it applies even to larger scales. So, you know, he'd say, \"How far is this away?\" And I'd say, \"Oh, that's three miles.\" And my sister would say, \"Oh, that's two miles.\" My dad would say, \"Oh, I think that's 13 miles.\" And it'd probably be, like, 12.5 [laughs]. And it's something that you have to work on. I've seen this.\n\nMost people, you ask them, you know, \"How long is three inches?\" And they don't know because they don't work with it every day. Like, how would you develop that skill unless you're a carpenter [laughs], right? Unless you're practicing with it many times a day. And estimation of how long something takes, I don't think, is any different than that. It's something that can be developed as a skill, but it's hard. And it's especially hard when we're doing that with projects that you're working on. \n\nYou don't see the mountain out there, right [chuckles]? So, you don't really have a good landmark. You're basing it on where you think the landmark's going to be. So, you're not just guessing how far is the landmark, but you're guessing where that milestone is. And it makes for a really difficult problem that hits some of our cognitive biases really badly. And we just get it wrong over and over and over again. So, that's kind of framing of the problem. \n\nJust in general, distance estimation is a tricky problem that you have to develop as a skill and estimating projects. And I think this, you know, we're talking about engineering, but it probably applies to other kinds of projects as well. It's a hard problem because the scale is hard to gauge, and, again, it hits some of our cognitive biases. \n\nWILL: So, I've got a question for you guys, maybe for the group, right? Like, in your experience, right? We've got some miles under our belts. What's the best situation in terms of estimating projects and delivering on those estimations consistently that you guys have all individually experienced firsthand, not somebody that you read about in a book, or a friend's thing, or somebody's plan? Like, what's the best setup that you've had yourself?\n\nJUSTIN: So, the best way for me to estimate something is to get asked to do something that I've done before. \n\n[laughter]\n\nWILL: No, no, no, no, no, no, no. Hang on, hang on, no, no, I'm talking about, like, the best setup, like, doing the work. The best setup where you've been like, \"Hey, we're going to have to do this thing.\" And you're like, \"Okay, I'm going to do this thing,\" you know what I mean? And, like, \"I think it's going to take me six weeks.\" And it takes you, you know, only eight, you know [laughter], or whatever it's going to be, like, the best system that you've worked in yourself. \n\nMATT: I find what works the best for myself, anyway, is to do a comparison on something I've done that's very similar in nature. You know, you have that mountain that Mike spoke about, and it's a lot easier than just conceptualizing it. If you can relate it to something else, then it's a lot easier to break down into the problems. And I find the smaller you can break those problems down, and if you can estimate the problems one at a time, then you have a really good idea of what the larger scope is going to be. That's where I've had the most success.\n\nWILL: Have you had the opportunity to consistently work in that fashion? I mean, like, has that been, like, an ongoing experience for you, or is just, like, what you would like to work on if you could but you can't? \n\nMIKE: I've seen this on teams I've worked with and teams I've worked closely with. And Matt hit on a few of the things that are critical. First of all [chuckles], you have to break it down into small, discrete pieces that are small enough you can wrap your head around them. That is absolutely critical, and that is not free. It takes time. \n\nYou have to break down the work into a map and, you know, say, \"I'm going to do this, and I'm going to do this, and I'm going to do this.\" When I say \"I,\" a collective I, you know, the we. We're going to do this, and we're going to do this, and we're going to do this. And, you know, we usually use story points in software development, which is this unitless measure, right? You say, \"This is how complex it is.\" And if there's anything above a three, then you're not good. It has to be small, discrete projects that somebody can say, \"Oh yeah, I know how to do that.\" \n\nUnless you've broken down everything into, I know how to do that, and they're in order, then you're going to be off. And if you do that, though, if you have everything broken down into, like, nothing bigger than size three, and you have a team that you've worked with before, because unless you have some sort of history to know how...you have to have a history. There's a big caveat here. You have to work together as a team for a while so that you know what you can do as a team over time in terms of those points. Then, it tends to land very close. Maybe not exactly perfect, but on average, pretty good. \n\nWILL: I agree with all of that. And you can't mess with the scope midstream. \n\nMIKE: So, you can't change the team. You can't change the scope. Those have to be fixed. You change the team, well, now you've changed the dynamics, right? You've changed the dynamics of how you work together, and work gets done as a team. It doesn't get done as individuals in that way because the team dynamics are relevant. So, you have to have a stable team. And, yeah, if you change the scope, well, that has to be planned just like everything else, and it has to be additive to it. \n\nMATT: Scope changes will happen, but if you tackle them the same way you tackle the initial problem, then you can also estimate, hey, it's going to add X number of weeks to this particular project, right? Or whatever piece of time that is. The key is small, workable pieces. \n\nJUSTIN: Clearly identifying the unknowns. \n\nMIKE: Well, if it's unknown...so, I'm going to dig a little bit more on that because I think it's critical. Identifying the unknowns, that's not a one-liner [laughs] because...so, I mentioned that, and I said this when I was talking about it, you're measuring the complexity. I don't think the story points should ever be used to measure time when you're estimating. They're not a measurement of time. \n\nMATT: Absolutely not. \n\nMIKE: They are a measurement of complexity. And if there is unknowns, it's not truly estimable because that means that you don't understand the work yet. Like, the rules for this plan, right? This only works if you can do everything that I said, which is that you know what those pieces are. I mean, you don't know exactly what you are, but you can wrap your head around it, right? And you know what you can do. If there are unknowns, that means that you haven't refined it down enough. And it's a measurement of complexity. As for those, you'd bump it up to, like, eight or, you know, something outside of what your boundaries are. Because unless it's down to three, then you don't really know. And here's a critical reason why. \n\nI read an article about this, and I don't have it up in front of me, years ago, but it's brilliant. It says that we're very good at estimating the median time to finish, but the mean is way higher than the median. So, if you line up all the projects, and you pick the one in the middle, we're pretty good at that. So, talking about these cognitive biases, we're actually pretty good at picking that one. \n\nThe problem is the complexity is very non-linear, and we have a hard time wrapping our heads around non-linear things. So, anything to the higher end of that median doesn't just go up linearly. It goes up exponentially or worse. So, the projects that are harder, that are worse than that median, might be ten times worse, or a hundred times worse, and so they drive the mean up really high. And then, you have a project that's three years late and over budget because it's really hard to predict where those unknowns and complexity are going to land.\n\nMATT: And you can't predict things that aren't known. That's the whole thing. Generally, yes, you're going to bump into a few unknowns. Part of it is trying to account for a rough percentage in your complexity. I mean, and it's really, I would say, experience. There are certain things that you encounter often. You just really have to think through and understand your problem to be able to accurately represent it. \n\nJUSTIN: Yeah. And it's almost like going back to what you said, Mike, you've got to resolve those unknowns before you can give an estimate, and so that's separate work. It's, like, a spike to resolve the unknowns. \n\nMIKE: Yes, absolutely. Listeners can't see this, but I just posted in our chat together. There's an xkcd comic that I think is fantastic. Boss is coming in, talking to the developer. He says, \"User takes a photo. The app should check whether they're in a national park.\" She's like, \"Sure, easy GPS lookup. Give me a few hours.\" \n\nJUSTIN: [laughs]\n\nMIKE: He says, \"Check whether the photo's a bird.\" She says, \"I'll need a research team in five years [laughter].\" In computer science, it can be hard to explain the difference between the easy and the virtually impossible, and that is so true. And there's this thing that things that are easy for humans are hard for machines, and vice versa. Like, yeah, fold the laundry, sure, I'll do that in five minutes. Have the machine fold the laundry? Good luck [laughs]. Good luck. In your mind, that little mental shortcut that says, \"Oh yeah, then I'll do the next step,\" may not map very well to how you actually make that happen.\n\nJUSTIN: As an aside, that comic, the second comment from the lady programmer, says, \"I'll need a research team in five years.\" Nowadays, it's like, \"Let me make an API call to ChatGPT.\" It's done in five minutes. \n\nMIKE: Well, what's even better is the [inaudible 11:24] message, which, [inaudible 11:27] xkcd is perfect. It says, \"In the 1960s, Marvin Minsky assigned a couple of undergrads to spend the summer programming a computer to use a camera to identify objects in a scene. He figured they'd have the problem solved by the end of the summer. Half a century later, we're still working on it [laughter].\" That's how it goes. \n\nWILL: So, I'm curious, what is this, like...so, this is an organizational problem, and I think we all sort of, more or less, like, understand, like, how to manage this, right? But on an organizational level, it's really, like, sort of, like, interfacing with, like, the broader teams and, like, where's it gone right and where's it gone wrong and how. Because I myself, like, I've experienced some pretty functional teams in that regard in that, like, you know, we come in with, like, sort of a product plan. We plan the tickets before the sprint starts. We hold to the sprint scope. We plan everything out. Boom, boom, boom, right down the line. And we do MVPs, things like that. \n\nAnd, you know, I mean, I'm sort of, like, experiencing right now in real time a degradation of that process, where product doesn't want to come into the sprint with a defined scope. Our product wants to give me...they want us to start work when I don't have, you know, a Figma design document that tells me where all the buttons are going to be and what they might want to do, you know what I mean? \n\nI'm going out, and I'm developing the frontend when there is no backend at all. And I'm sort of like, and I'm like, \"Well, do you have a schema for what the backend might eventually look like?\" \"Well, not really,\" you know what I mean? You could work on all that kind of stuff, but it increases [inaudible 13:16]. It increases rework, inefficiency. And, quite frankly, like, it really kind of pisses me off, you know, like, where, like, I have to, like, my job gets three times harder because people couldn't be bothered to, like, you know, make an effort at the outset of the project. Now I'm kind of curious about, like, sort of like, I've seen it go good and, like, where you've seen the process break down and how. \n\nMIKE: You just hit on, like, all the failure modes, right [laughter]? Requirements not gathered before the work starts. Now, in the real world, sometimes you don't know everything. But, like, you should at least have the overall direction defined so that...certainly, by the sprint, you know what you're going to be working on. If you don't have the requirements, that's just a recipe for burnout and over budget, over time, over everything.\n\nAnd cross-team, you talked about different teams that are not in alignment. And you're like, maybe the backend's not working yet, but the frontend is. And so, now you have all the misalignment between teams, and getting those coordinated is always, like, the hardest part [laughter]. And this sounds like you're also talking about some team dysfunction, where people are like, \"No, I don't feel like doing that.\" Like, you don't have the sense of collaboration between the parties. And, man, if you don't have engineering and product working together, you're in for a world of hurt. \n\nAnd why does this happen? I think it tends to happen for the same reasons repeatedly is that unless we're working at non-profits, and I think it even applies there, I mean, we're trying to make money, or, you know, we're trying to maximize our utility, and something comes up. They want to get it done. They being leadership at some level, wherever that is, it can happen at any tier, wants to get something done. And you don't have a great process for aligning that to reality. Then you're going to have more than you can get done. \n\nAnd there's going to be this misalignment of reporting because you said, \"Oh, I gave a prediction.\" But now you've added to the scope. You've thrown some other things in there, or you changed the team. You've done a reorg. Whatever it is you've done, you've broken the rules. And when that happens, things get out of kilter, and it's hard to get them back because you need to make a conscious effort to say, \"No, we can't do this.\" The only way this works is when we follow all the rules. And there's a lot of times when somebody is going to not want to follow those rules. And it's hard to explain why those rules are important. It involves math and [laughter] discussion, yeah.\n\nWILL: I mean, I suppose so, and I agree with what you're saying. But, I mean, like, I'm a lot more interested in sort of the fundamental psychology of, like, the planning. And the reason I'm sort of most interested in it is because if we were all sort of, like, very rational, logical actors, even on an upper management leadership level, the better you plan the stuff, the more efficient things run. And, honestly, I mean, like, really spending time in investing up front in your product planning and development that will make you more money.\n\nWe do better when we're very, very, very deliberate about when, where, why, and how we're taking on projects. That lack of discipline, like, it not only hurts, like, sort of the engineering efficiency, but, in my view, it's extremely hazardous in terms of, like, business impacts. \n\nJUSTIN: So, Will, I mean, you're going more towards the clearly defined problems and everything, but, classically, that's called, like, the waterfall solution, which is a bad word these days, right? So, where do you draw the line between planning everything and planning just enough?\n\nMATT: But planning being the operative word here, right? You can be extremely agile. You know, I've worked where we were extreme programming weekly sprints. We planned every single week. We had our work ready every Monday for that week. You can break problems into smaller problems and then just plan those smaller problems. But you do have to have a really good idea of what the primary problem is, right? And the thing you're trying to solve for and your ultimate goal. But once you understand that, you can break it into small problems, and then you plan pieces at a time, and you can be super effective.\n\nWILL: I do agree that, like, waterfall is a dirty word, and it should stay one, frankly. Because where I see things go, like, most badly, is shipping these grand visions versus tiny, little, agile, incremental pieces. Maybe analogize it with the sort of, like, the Apple iOS grand reveal of the new version of their operating system. Versus maybe, like, the Google Android, like, things are coming out all the time. Like, what's even the current version?\n\nJUSTIN: [laughs]\n\nWILL: Is it Oreo, or Nougat, or Zeta [laughter], or whatever? I don't even know. Like -- \n\nMATT: But do you care?\n\nWILL: Come on, who cares? Stuff's coming out just helter skelter pelmel, all the time, right? Versus, like, this, like, this grand, like, unveiling that happens once a year. It's cool that Apple can pull that off, you know, but, like, -- \n\nMIKE: Will, do you think that, internally, they're actually having a grand pull-off? Or do you think that they're doing the same thing that Android is doing and they're just tidying it behind the scenes doing these incremental builds, and when they finally have it ready, then they push it out? I think it's the latter. Like, I think that --\n\nJUSTIN: Yeah, I think it's the latter, too. \n\nMATT: Yeah, I mean, when you're incremental, you're mitigating risk. \n\nMIKE: Exactly. There's huge risk when you're doing it. So, there's aerospace example, and it's easy because it's big, expensive projects people know about. There's the Space Launch System recently launched successfully. After years, you know, they finally have a launch. I don't think they...[laughter] they, like, don't even launch a real payload, and it costs, like, two billion dollars, or something, just to launch, not the development but, like, the launch costs that. And then, I read the other day that one of the SpaceX rockets, the Falcon 9, did its 20th launch, reused, like, the same rocket, launched its 20th time. \n\n[laughter]\n\nAnd, you know, I'm sure it costs some millions, but orders of magnitude difference in price. And SpaceX has blown a lot more things up, but they did it on purpose because they said, \"We're going to do this incrementally, and we're going to start small. And we're going to iterate.\" And now they're just the steamroller that is launching more rockets than, like, all of the nation states put together.\n\nMATT: They're miles ahead. \n\nJUSTIN: Yeah, if only they weren't led by a crazy guy, but anyway. \n\nWILL: Well, you have to be crazy. \n\nMATT: That's why they are so successful [laughs].\n\nWILL: Because, I mean, like, there's...I -- \n\nJUSTIN: Okay. So, at the start, he was crazy, but he was focused on his stuff. Now he's crazy and focused on other things; at least, that's what it seems like. \n\nWILL: A lot of those guys are difficult people. Steve Jobs, God rest his soul, [inaudible 20:24], you know what I mean, had his halo shined considerably in his death. And, at the very least, he was disciplined enough to keep his mouth shut and most of his sociopathic behavior behind closed doors. But, I mean, like, the stories abound of that guy doing terrible stuff, and he never really stopped. His PR team got better, but, like, he was a jerk till the day he died. God bless him, you know? \n\nMIKE: One thing that they have in common, though, is that they honor the engineering process. And I'm not going to even touch Elon Musk as a person, right? That's a topic I'm just not going to bring up here. But he came from the software world and brought that engineering process and cultivated it among engineers.\n\nMATT: That is very true. \n\nMIKE: It really doesn't matter about him, right? What he brought was the process. He brought the agile engineering process with him from software world and just applied it to aerospace, and it works. If you do it, it works. If you don't do it, a recurring theme here, it doesn't work.\n\nWILL: I think it is a validation of that process, you know what I mean, in a lot of different, you know what I mean? You're moving that into other industries and avenues, provided that it is permissible to explode the rockets, and there's nobody [laughter] on them. \n\nMATT: And we all agree, waterfall, bad word. But I would argue a waterfall process is better than no process at all. \n\nMIKE: Sure. So, I think a lot of people they think, Agile, hey, we don't have to plan anymore.\n\nJUSTIN: [laughs].\n\nWILL: You can't be farther from the truth. \n\nMIKE: Exactly. All you're doing is you're tightening your planning loop, right? You're tightening your feedback loop. And instead of doing all of your documentation upfront when you know the least, you are choosing to actively plan, and document, and iterate the whole time. So, instead of doing it once, you never stop doing it. And if you think that being agile means, oh, wait, you know, I'm just not going to plan at all; we'll just wing it, then you're missing the whole idea, which is that these interactions, the communication is hard, and that interaction is critical. And you need to have interaction with your hardware, with your stakeholders, with your software. You know, you're testing it. You are evaluating it. You're improving it continuously rather than once.\n\nAnd it's actually more planning work in the end because you're doing it along a line. But because it's distributed, it's more efficient because you're doing it when you have the most information, which is after you've already done some of the iterations already. \n\nMATT: And it becomes easier with experience because then you have that association. If you've been doing this for a while, which all of us have, there's very few problems that we have never seen before. They just are in a little different context. But, generally, it's the same problems over and over, and we know how to solve them. I think -- \n\nMIKE: You're taking text out of the database and transforming it and showing it to somebody?\n\nMATT: Exactly [laughter]. It's only data, right [laughter]? But, you know, there are new things coming out, AI, for instance. GenAI is new to a lot of people, and we're going to learn that as well. And it may be a little harder to plan those technologies because we don't have the experience yet. So, we may not be as accurate with our estimates on those types of projects. But, for the most part, most of the work we're doing, we have done before in some form. And if you break it down, isn't any different than other problems we've already solved. \n\nJUSTIN: So, I do want to add a caveat to that. Well, not a caveat, just, like, an addendum. It's interesting the organizational changes that are happening within Acima, right? Well, Upbound, right? And last year was, like, a record year for Acima and RAC. And this year, we've got a big organizational change where teams are shifting. Directors are shifting. Product owners are shifting. There's a lot of moving parts here. And I'm afraid that they're going to expect the same record level production from an engineering standpoint that they had last year this year because it's, like, oh, we're reorganizing in a more efficient manner. That means we're going to do even better. And it's like, maybe long term, but that short term is really going to suck. \n\nMATT: Well, and maybe it's up to us, right? Well, it is up to us. I really think, just highlighting what I just said, if we look at it as these aren't different problems; they're the same problems, whether I was on Team A or Team B, I'm still facing the same types of problems today that I was yesterday, and we approach it in that manner, I think we can be absolutely as efficient. Change is hard for people. When you are shifting so many things around all at one time, it's up to us to kind of get our bearings and have that compass to remind us that we're still doing the same thing. \n\nMIKE: Well, there's a couple of things that need to happen. First of all, we should work very hard to preserve team boundaries where we can. Like, let's not disrupt high-functioning teams. Second, leadership needs to be focused on using this as intended to improve lines of communication and not just change them. You know [laughs], let's just shuffle things around, and it looks better on a whiteboard. That's just going to slow us down. \n\nIf we see that there were...you know, in a large organization, there are difficulties with communication; of course, there are. And if we reorganize to try to improve that while allowing the engineers to keep doing their work with minimally disrupting the teams, then we could actually become more effective. But that is a, you know, to Matt's point, it's up to us. Like there is a decision point here, and we have to be aware of that destination. We have a choice, right? We make things better, or we make things worse.\n\nWILL: So, I mean, in regards to, like, sort of, like, these major, like, company-wide reorganizations, how do you account for and even measure sort of, like, impacts of the reorganization, right? Like, impacts on sort of, like, planning bandwidth, right? I mean, you've got people who are, like, coming up with a plan for the next sprint, writing the tickets, like, measuring the stuff out, right? And so, like, they have a certain amount of planning that they can do, right? And that's affected by their familiarity with, like, their operating environment, right?\n\nLike, you bring a manager into a brand new team. They haven't touched any of the code. They have, you know, a certain amount of planning bandwidth, right? And, like, that's going to be constrained by them getting up on the stuff, right? You have a new team, right? Okay, you know, like, you don't want to disrupt high-performing teams. But, honestly, like, maybe you do want to give your A players your biggest impact priority work, right? \n\nSo, you move those people in, and they have to acclimate, right? How do you account for impacts of reorganization? Because this is something that I have seen as well. You know, the large retailer that I work for they love their Q1 reorg. They love, you know, rearranging the furniture. But they're going to have a cost, and I don't know that the cost is accounted for organizationally. \n\nMIKE: And because it's hard to measure, it doesn't get measured, and -- \n\nWILL: If it doesn't get measured, then they can't plan for it, you know what I mean? Upper management, you know, those executives that are sort of, like, rearranging the furniture they don't have that. Do they have that in their heads? Do they have it in their mind? There's a cost. We've all felt it. \n\nJUSTIN: I think you treat it as you would, you know, you're onboarding any new member to your team. This is something that happens all the time with engineering teams. People leave; people come in. And you have to get to know this person and, you know, put them through the same onboarding and really get to know their capabilities and stuff. And so, I think your estimates are going to suffer a little bit until you've had a couple of sprints with them. You treat that as an unknown, and make sure you communicate that up. That's kind of what you would do at the team level. \n\nAnd then, I would think that the folks in the engineering leadership, if they make changes at team levels like that, they just need to get those lines of communication going such that you can set expectations and really understand, \"Hey, we just on-boarded two new people, you know, our estimates are going to suffer for the next sprint or two. And then, we'll be able to give a more accurate estimate after that.\" \n\nMIKE: And there's that bigger question. What metric can you use to measure, aggregated across teams, across an organization? What metric can you use to capture effectiveness as you're doing a reorg? Because we know every metric captures a slice of something and has its own biases. So, what would be an effective metric? Does anybody have an answer to this? What's an effective metric to see how...when you do a reorg, what do you use to measure it? Did this work? \n\nMATT: Velocity over time. I mean --\n\nMIKE: The tricky thing is velocity is team-specific. You rearrange all your teams, velocity changes. If you measure that, then everybody's going to say, \"Oh yeah, we're just going to have...\" this is five points. That's not three. That's five. Like, you're going to bias it toward higher story points, and velocity ceases to become effective as a number. So, it's hard to measure that precisely. And business initiatives aren't exactly equal to each other. So, you can't necessarily say, \"Oh yeah, we've done five initiatives per year [laughs].\" It's a tricky problem.\n\nJUSTIN: Yeah, I think if you had an answer to that, you could write your software engineering estimation book, Mike, and retire on that, so... \n\n[laughter] \n\nMIKE: But it's not a new problem. It's not a new problem. Everybody's dealing with it. And then, we fall into these gut, you know, we don't have an answer, so we just kind of look the other way and go with our gut and don't measure it very well. And then, maybe you have your annual reorg [chuckles] that does more harm than good. \n\nWILL: Well, I mean, I don't know. I mean, I feel like you ought to have, internally, a general rule of thumb for, like, okay, if I have a new hire, this is what I expect the onboarding to look like. At week 1, I'll get X. At week 5, I'll get Y. At week 10, I'll get Z, right? Like, you'll have an arc of their productivity, at their level, right? Like, you know a junior will onboard. You know a senior will onboard, you know, et cetera. \n\nAnd then, like, I think you should probably also have, like, a rough idea of what an internal transfer is going to look like, right? Like, if I move from, like, you know, Team A to Team B, it's not going to look like a new hire, you hope. Although, depending on the team, you know what I mean? Like, I know I'm familiar enough with Acima that there's some teams that you don't just, like, walk into [laughter]. \n\nMIKE: One does not simply walk [laughter]. \n\nWILL: One does not simply walk into a --\n\nMIKE: An underwriting -- [laughs]\n\nWILL: Yeah, underwriting. Yeah, underwriting. \n\nMATT: Or the [inaudible 31:48] service.\n\nJUSTIN: [laughs] \n\nWILL: Oh no, that one is fine. Like -- \n\nMATT: Oh yeah, you worked on that team. \n\nWILL: Yeah, the Haskell. The Haskell, the Haskell folks, you know what I mean? Like e-comm. \n\nMATT: Oh, Lambda. \n\nJUSTIN: Lambda. Yeah. \n\nWILL: That one's there. You know, there's stuff you don't just walk into. So, like, you have that, right? Then you say, okay, reorg. Then I have, like, X number of, like, people moving teams, and probably the same for managers, although, I mean, I will say that, like, I don't think we think enough about management sort of, like, the bandwidth, right? You know, like, we spend a lot of time thinking about, like, okay, coordinating engineers, right? But, like, management bandwidth in terms of planning bandwidth I think it's, you know what I mean, I think it's a little bit unsung. We have a general feeling for, you know, how many engineers a manager can be sort of overseeing, but beyond that, it gets pretty mushy, wouldn't you say? Or am I wrong? \n\nMATT: No, I think about that every day. I'm new to the management team over here on the Upbound side. And it's true that bandwidth gets spread a little thin, right? And that's part of being able to organize your team, having the right people to lead those teams. And everyone has been on...well, not everyone. But a lot of us have been on very large teams versus, like, 3-to-5-member team and seeing the difference in efficiencies, right? And how those teams are managed. \n\nAnd, ideally, smaller teams, in my opinion, are better. So, you need to do that with management as well and whether there's levels. We have a new concept here at our company of delivery managers. And they've kind of taken over a lot of that responsibility to kind of help spread that bandwidth for planning and let people focus where they should be focused. That's the way think about it. \n\nMIKE: So, we've wandered far and wide here a bit [laughter] as to...we started, like, well, yeah, we know what it takes to run a team well. And then, we started getting into all the complexities when you increase in scale, you know. You go to the next tier, and you've got managers and managers over managers over managers, and it can fall apart. Because, at any place in this hierarchy, if somebody isn't paying attention to the rules, then it can fall apart. \n\nIt seems to say something about what you do to run an effective engineering organization is that everybody has to be aware of what the constraints are, be upfront about them, and be willing to stick to some simple rules, right? The planning happens. It happens every time. Every time you can. You don't give it a short shrift, you know; you keep on it. And you don't skip it at any tier. \n\nYou know, up at the top level of management, you know, they have to make some estimates based on incomplete information. That's something we all have to do. But they do everything they can to follow the best process they can: gather the information, make the best estimates they can with the information. It has to be all the way down. And then, you have a really well-run organization, right? \n\nWILL: Mm-hmm. Is there [inaudible 35:06] where, like, people who are just sort of guessing, because the company...and what I mean by that it's like, sort of if you say, like, okay, I've got a corporate, let's call it, like, five-year plan, right? Which is not a crazy thing, like, you don't get a business corporate, you know, strategy kind of a thing, right? But on a software, you know, estimation sort of a thing, that's [laughs] a joke. That's comedy, you know what I mean? Like a five-year, like, I can't plan that, you know what I'm saying? And so, it does need to be done on some kind of level, right? Where does that transition happen, and how? \n\nMIKE: There's a really good thing that we've done for a few years now that's spreading throughout the organization, which is that we recognize explicitly that there are tiers of planning. You can map these to a couple of really useful things. You can map them to groups of employees, or you can map them to Jira issue types. And it works either way. So, tier one, you know, planning level one is what the executives do, and it's associated with an initiative in your project management software. \n\nTier two, planning level two, is associated with milestones within that initiative. I'm going to expand to Columbia, so I've got an initiative. And then, when it comes to milestones, well, maybe you need to negotiate with the government contracts, you know, maybe you need to build some sort of new tax integration. You know, figure out whatever those pieces are. You're developing the milestones, right? But now you have something that's a bigger shape. \n\nAnd then, there's a tier-three level of planning. Now you're talking with your team leads. Those team leads are breaking this, and that's associated with, like, an epic in your project management software, where now you're coordinating between teams. You know which teams are going to be working on it and where those boundaries are, you know, who's going to be working on what.\n\nAnd then, you have a tier four, you know, planning level four, which is within the team. That's your refinement, your sprint planning, and so on, where now I know what my team needs to do, right? So that I know what those boundaries are. And I have the epic, so I know what the overall story is I need for my team. Now, I need to break that down into the two and three-pointed stories. \n\nAnd that works really well because, at every level, you're doing planning based on the information that you have. And you recognize that the accuracy of that planning goes up dramatically as you go from levels one to four. By the time you've done a level four planning and you've completely pointed something out, you know, you can say pretty well when that's going to land.\n\nWhen you're just at the initiative level, you're like, I'm going to expand into Columbia, right? You really don't know. You really don't know very much, but you know something, right? You know something. You know that that is a business priority that you can shuffle around with other business priorities and say, \"Well, this is something I want to do first. And I can start to gather information on it. \n\nWILL: Well, okay, sure. But, I mean, like, so, like, you know, a company like the size of Upbound, right? It's a public traded company. They need to have, like, sort of, like, forward-looking projections about, like, when is this stuff going to land, you know?\n\nMIKE: Yes.\n\nWILL: And what are the business impacts and, like, because, like, because they're beholden to their shareholders. Their shareholders want regularly scheduled updates about, like, okay, you've got an initiative. When am I going to get the initiative? And, I mean, like, is the best we can do on these initiatives just sort of, like, we've done it before and this is about how long it took, you know what I mean? Like, where it's like, okay, you know, I did this, you know, when I expanded into Cincinnati. Like, this is what I got and how. And if I'm doing Columbia, then it's going to be, you know what I mean, ten times harder than doing Cincinnati, right? Like, you got a whole other regulatory language business entity, et cetera. Like, is that the best you could do? \n\nMIKE: Well, I think you can even put time frames on here. So, I'll say, also, that this map roughly to divisions of time. Annual plan, initiative. Quarterly plan; it may be milestones, right?\n\nWILL: Right. \n\nMIKE: And then, you can slot your epics, perhaps, into months. And by the time you get to your stories, you can get that down to about weeks. It kind of maps loosely. Again, this maps to some of these divisions. The precision you get gets more specific. And, generally, at the executive level, you're usually communicating at an annual or a quarterly level. You say, \"Well, this year, we intend to expand into Columbia. By quarter three, we expect to be operational at some stores,\" and so on. You know, you speak in those kinds of broader periods, right? Your resolution is a lot less fine-grained, and that's okay. That's actually expected.\n\nWILL: How do you enforce discipline? I mean, I know, like, on the tier 4 level, right? You're sitting like, okay, I want two or 3-point tickets, right? Like, I want two or 3-point tickets. I want, you know, that's all I want. And, like, if you're doing five or, God help you, an 8 [laughter], you know, things are probably going to go bad, right? And I see how that fundamental process it's got to scale up. But it's a lot less clear how you enforce it, you know, as you go from tier 4 to tier 3 in planning or tier 3 to tier 2 planning or tier 2, God help you, to tier 1 planning. How do you keep a lid on that? Well, because it matters. Like being off by a quarter, that's a big problem. \n\nMIKE: Right, right. \n\nMATT: It is a big problem. \n\nWILL: And for a tier 1, being off by a quarter is actually doing a pretty good job, in my opinion. \n\nMIKE: I agree. \n\nWILL: You're delivering an initiative, and you're only off by a quarter? Not bad, y'all. Not bad. \n\nMIKE: [laughs]\n\nWILL: You know? Like...\n\nMIKE: So, one thing I think you can do...and we talked about the rules down at tier 4, right? That's what we think a lot about. But there's no reason you can't have documented rules at every tier. This is the output. This is the data that went into it. And these are the requirements. Like, you don't say that this initiative is going to get done this year, and unless you have done this, this, and this [laughs], being off by a quarter, that's...it's going to be hard to be within a quarter resolution. \n\nBut you can do the things, the executive things [laughs] that executives need to do: gathering information, delegating that out to people that you trust to go and gather the necessary information, and establish a culture that demands honesty and rewards it, rather than one that rewards saying, \"Yes.\" I mean, there's things that can be done there. And now we're getting into business management. \n\nTo bring it back to the beginning, we've all got some landmarks we're trying to move our way towards. Hopefully, this has provided some food for thought, how to better figure out when we're going to get there. \n\nWILL: Cool. Thanks, y'all. \n\nMATT: Yes. Thank you, everyone. ","content_html":"In this episode of the Acima Development Podcast, Mike and the panel talk about the intricacies of project estimation, sharing personal anecdotes and professional experiences. Mike begins with a story from his childhood, illustrating how his father's ability to estimate distances accurately influenced his understanding of estimation as a skill that can be developed with practice. He draws parallels between estimating physical distances and estimating project timelines, emphasizing the importance of breaking down tasks into smaller, manageable pieces to improve accuracy.
\n\nThe conversation transitions to discussing the best practices for project estimation within engineering teams. Matt and Justin highlight the effectiveness of comparing new tasks to similar past projects and the necessity of having a stable team to ensure consistent delivery. They stress the importance of planning in small increments and maintaining clear communication among team members to mitigate risks and handle scope changes efficiently. Mike adds that understanding and identifying unknowns early in the process is crucial for making realistic estimates and avoiding common cognitive biases that can lead to significant project delays and budget overruns.
\n\nTowards the end, the team explores the challenges of maintaining estimation accuracy during organizational changes, such as team reassignments and company-wide reorgs. Will raises concerns about the impact of these changes on planning bandwidth and overall productivity. The group agrees that preserving team dynamics and ensuring clear lines of communication are essential to minimizing disruption. They discuss the importance of having documented rules and metrics at every planning level to measure effectiveness and ensure alignment with business goals. The episode concludes with a reflection on the necessity of disciplined planning and continuous improvement to successfully manage complex engineering projects.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I have with me here Will, Justin, Eddy, and Matt. And we're going to be talking today about strategies and pitfalls in estimation. I'm going to start with just a story from my childhood.
\n\nWe were talking in the pre-recording for a bit about math. I was remembering that my dad used to ask math-related questions to me and my siblings and make a game out of it. Like, he wasn't, like, grumpy, or pushy, or anything. He was like, "What do you think of this?" And then, we'd think about it. This is on road trips. He'd always do it on road trips. Like, that's the only time I ever remember this happening [laughs]. You know, you're on a road trip back in the long ago era before there was internet in your car [laughs]. And you had to do something to fill the space.
\n\nI remember that there was mountain ranges, and he'd pick a landmark. You know, there'd be, like, this mountain. "How far away do you think that is? Guess." And my dad was always right. And all of us were wildly wrong [laughter]. He was always really close. My dad's a carpenter. He's very, very good at recognizing distances. Like, he can look at something 15 inches long. He'll look at it and say, "That's 15 inches [laughs]." And he's right. You know, he's as good as a ruler [laughs].
\n\nHe's just really good at that perception, you know, distance perception. But it applies even to larger scales. So, you know, he'd say, "How far is this away?" And I'd say, "Oh, that's three miles." And my sister would say, "Oh, that's two miles." My dad would say, "Oh, I think that's 13 miles." And it'd probably be, like, 12.5 [laughs]. And it's something that you have to work on. I've seen this.
\n\nMost people, you ask them, you know, "How long is three inches?" And they don't know because they don't work with it every day. Like, how would you develop that skill unless you're a carpenter [laughs], right? Unless you're practicing with it many times a day. And estimation of how long something takes, I don't think, is any different than that. It's something that can be developed as a skill, but it's hard. And it's especially hard when we're doing that with projects that you're working on.
\n\nYou don't see the mountain out there, right [chuckles]? So, you don't really have a good landmark. You're basing it on where you think the landmark's going to be. So, you're not just guessing how far is the landmark, but you're guessing where that milestone is. And it makes for a really difficult problem that hits some of our cognitive biases really badly. And we just get it wrong over and over and over again. So, that's kind of framing of the problem.
\n\nJust in general, distance estimation is a tricky problem that you have to develop as a skill and estimating projects. And I think this, you know, we're talking about engineering, but it probably applies to other kinds of projects as well. It's a hard problem because the scale is hard to gauge, and, again, it hits some of our cognitive biases.
\n\nWILL: So, I've got a question for you guys, maybe for the group, right? Like, in your experience, right? We've got some miles under our belts. What's the best situation in terms of estimating projects and delivering on those estimations consistently that you guys have all individually experienced firsthand, not somebody that you read about in a book, or a friend's thing, or somebody's plan? Like, what's the best setup that you've had yourself?
\n\nJUSTIN: So, the best way for me to estimate something is to get asked to do something that I've done before.
\n\n[laughter]
\n\nWILL: No, no, no, no, no, no, no. Hang on, hang on, no, no, I'm talking about, like, the best setup, like, doing the work. The best setup where you've been like, "Hey, we're going to have to do this thing." And you're like, "Okay, I'm going to do this thing," you know what I mean? And, like, "I think it's going to take me six weeks." And it takes you, you know, only eight, you know [laughter], or whatever it's going to be, like, the best system that you've worked in yourself.
\n\nMATT: I find what works the best for myself, anyway, is to do a comparison on something I've done that's very similar in nature. You know, you have that mountain that Mike spoke about, and it's a lot easier than just conceptualizing it. If you can relate it to something else, then it's a lot easier to break down into the problems. And I find the smaller you can break those problems down, and if you can estimate the problems one at a time, then you have a really good idea of what the larger scope is going to be. That's where I've had the most success.
\n\nWILL: Have you had the opportunity to consistently work in that fashion? I mean, like, has that been, like, an ongoing experience for you, or is just, like, what you would like to work on if you could but you can't?
\n\nMIKE: I've seen this on teams I've worked with and teams I've worked closely with. And Matt hit on a few of the things that are critical. First of all [chuckles], you have to break it down into small, discrete pieces that are small enough you can wrap your head around them. That is absolutely critical, and that is not free. It takes time.
\n\nYou have to break down the work into a map and, you know, say, "I'm going to do this, and I'm going to do this, and I'm going to do this." When I say "I," a collective I, you know, the we. We're going to do this, and we're going to do this, and we're going to do this. And, you know, we usually use story points in software development, which is this unitless measure, right? You say, "This is how complex it is." And if there's anything above a three, then you're not good. It has to be small, discrete projects that somebody can say, "Oh yeah, I know how to do that."
\n\nUnless you've broken down everything into, I know how to do that, and they're in order, then you're going to be off. And if you do that, though, if you have everything broken down into, like, nothing bigger than size three, and you have a team that you've worked with before, because unless you have some sort of history to know how...you have to have a history. There's a big caveat here. You have to work together as a team for a while so that you know what you can do as a team over time in terms of those points. Then, it tends to land very close. Maybe not exactly perfect, but on average, pretty good.
\n\nWILL: I agree with all of that. And you can't mess with the scope midstream.
\n\nMIKE: So, you can't change the team. You can't change the scope. Those have to be fixed. You change the team, well, now you've changed the dynamics, right? You've changed the dynamics of how you work together, and work gets done as a team. It doesn't get done as individuals in that way because the team dynamics are relevant. So, you have to have a stable team. And, yeah, if you change the scope, well, that has to be planned just like everything else, and it has to be additive to it.
\n\nMATT: Scope changes will happen, but if you tackle them the same way you tackle the initial problem, then you can also estimate, hey, it's going to add X number of weeks to this particular project, right? Or whatever piece of time that is. The key is small, workable pieces.
\n\nJUSTIN: Clearly identifying the unknowns.
\n\nMIKE: Well, if it's unknown...so, I'm going to dig a little bit more on that because I think it's critical. Identifying the unknowns, that's not a one-liner [laughs] because...so, I mentioned that, and I said this when I was talking about it, you're measuring the complexity. I don't think the story points should ever be used to measure time when you're estimating. They're not a measurement of time.
\n\nMATT: Absolutely not.
\n\nMIKE: They are a measurement of complexity. And if there is unknowns, it's not truly estimable because that means that you don't understand the work yet. Like, the rules for this plan, right? This only works if you can do everything that I said, which is that you know what those pieces are. I mean, you don't know exactly what you are, but you can wrap your head around it, right? And you know what you can do. If there are unknowns, that means that you haven't refined it down enough. And it's a measurement of complexity. As for those, you'd bump it up to, like, eight or, you know, something outside of what your boundaries are. Because unless it's down to three, then you don't really know. And here's a critical reason why.
\n\nI read an article about this, and I don't have it up in front of me, years ago, but it's brilliant. It says that we're very good at estimating the median time to finish, but the mean is way higher than the median. So, if you line up all the projects, and you pick the one in the middle, we're pretty good at that. So, talking about these cognitive biases, we're actually pretty good at picking that one.
\n\nThe problem is the complexity is very non-linear, and we have a hard time wrapping our heads around non-linear things. So, anything to the higher end of that median doesn't just go up linearly. It goes up exponentially or worse. So, the projects that are harder, that are worse than that median, might be ten times worse, or a hundred times worse, and so they drive the mean up really high. And then, you have a project that's three years late and over budget because it's really hard to predict where those unknowns and complexity are going to land.
\n\nMATT: And you can't predict things that aren't known. That's the whole thing. Generally, yes, you're going to bump into a few unknowns. Part of it is trying to account for a rough percentage in your complexity. I mean, and it's really, I would say, experience. There are certain things that you encounter often. You just really have to think through and understand your problem to be able to accurately represent it.
\n\nJUSTIN: Yeah. And it's almost like going back to what you said, Mike, you've got to resolve those unknowns before you can give an estimate, and so that's separate work. It's, like, a spike to resolve the unknowns.
\n\nMIKE: Yes, absolutely. Listeners can't see this, but I just posted in our chat together. There's an xkcd comic that I think is fantastic. Boss is coming in, talking to the developer. He says, "User takes a photo. The app should check whether they're in a national park." She's like, "Sure, easy GPS lookup. Give me a few hours."
\n\nJUSTIN: [laughs]
\n\nMIKE: He says, "Check whether the photo's a bird." She says, "I'll need a research team in five years [laughter]." In computer science, it can be hard to explain the difference between the easy and the virtually impossible, and that is so true. And there's this thing that things that are easy for humans are hard for machines, and vice versa. Like, yeah, fold the laundry, sure, I'll do that in five minutes. Have the machine fold the laundry? Good luck [laughs]. Good luck. In your mind, that little mental shortcut that says, "Oh yeah, then I'll do the next step," may not map very well to how you actually make that happen.
\n\nJUSTIN: As an aside, that comic, the second comment from the lady programmer, says, "I'll need a research team in five years." Nowadays, it's like, "Let me make an API call to ChatGPT." It's done in five minutes.
\n\nMIKE: Well, what's even better is the [inaudible 11:24] message, which, [inaudible 11:27] xkcd is perfect. It says, "In the 1960s, Marvin Minsky assigned a couple of undergrads to spend the summer programming a computer to use a camera to identify objects in a scene. He figured they'd have the problem solved by the end of the summer. Half a century later, we're still working on it [laughter]." That's how it goes.
\n\nWILL: So, I'm curious, what is this, like...so, this is an organizational problem, and I think we all sort of, more or less, like, understand, like, how to manage this, right? But on an organizational level, it's really, like, sort of, like, interfacing with, like, the broader teams and, like, where's it gone right and where's it gone wrong and how. Because I myself, like, I've experienced some pretty functional teams in that regard in that, like, you know, we come in with, like, sort of a product plan. We plan the tickets before the sprint starts. We hold to the sprint scope. We plan everything out. Boom, boom, boom, right down the line. And we do MVPs, things like that.
\n\nAnd, you know, I mean, I'm sort of, like, experiencing right now in real time a degradation of that process, where product doesn't want to come into the sprint with a defined scope. Our product wants to give me...they want us to start work when I don't have, you know, a Figma design document that tells me where all the buttons are going to be and what they might want to do, you know what I mean?
\n\nI'm going out, and I'm developing the frontend when there is no backend at all. And I'm sort of like, and I'm like, "Well, do you have a schema for what the backend might eventually look like?" "Well, not really," you know what I mean? You could work on all that kind of stuff, but it increases [inaudible 13:16]. It increases rework, inefficiency. And, quite frankly, like, it really kind of pisses me off, you know, like, where, like, I have to, like, my job gets three times harder because people couldn't be bothered to, like, you know, make an effort at the outset of the project. Now I'm kind of curious about, like, sort of like, I've seen it go good and, like, where you've seen the process break down and how.
\n\nMIKE: You just hit on, like, all the failure modes, right [laughter]? Requirements not gathered before the work starts. Now, in the real world, sometimes you don't know everything. But, like, you should at least have the overall direction defined so that...certainly, by the sprint, you know what you're going to be working on. If you don't have the requirements, that's just a recipe for burnout and over budget, over time, over everything.
\n\nAnd cross-team, you talked about different teams that are not in alignment. And you're like, maybe the backend's not working yet, but the frontend is. And so, now you have all the misalignment between teams, and getting those coordinated is always, like, the hardest part [laughter]. And this sounds like you're also talking about some team dysfunction, where people are like, "No, I don't feel like doing that." Like, you don't have the sense of collaboration between the parties. And, man, if you don't have engineering and product working together, you're in for a world of hurt.
\n\nAnd why does this happen? I think it tends to happen for the same reasons repeatedly is that unless we're working at non-profits, and I think it even applies there, I mean, we're trying to make money, or, you know, we're trying to maximize our utility, and something comes up. They want to get it done. They being leadership at some level, wherever that is, it can happen at any tier, wants to get something done. And you don't have a great process for aligning that to reality. Then you're going to have more than you can get done.
\n\nAnd there's going to be this misalignment of reporting because you said, "Oh, I gave a prediction." But now you've added to the scope. You've thrown some other things in there, or you changed the team. You've done a reorg. Whatever it is you've done, you've broken the rules. And when that happens, things get out of kilter, and it's hard to get them back because you need to make a conscious effort to say, "No, we can't do this." The only way this works is when we follow all the rules. And there's a lot of times when somebody is going to not want to follow those rules. And it's hard to explain why those rules are important. It involves math and [laughter] discussion, yeah.
\n\nWILL: I mean, I suppose so, and I agree with what you're saying. But, I mean, like, I'm a lot more interested in sort of the fundamental psychology of, like, the planning. And the reason I'm sort of most interested in it is because if we were all sort of, like, very rational, logical actors, even on an upper management leadership level, the better you plan the stuff, the more efficient things run. And, honestly, I mean, like, really spending time in investing up front in your product planning and development that will make you more money.
\n\nWe do better when we're very, very, very deliberate about when, where, why, and how we're taking on projects. That lack of discipline, like, it not only hurts, like, sort of the engineering efficiency, but, in my view, it's extremely hazardous in terms of, like, business impacts.
\n\nJUSTIN: So, Will, I mean, you're going more towards the clearly defined problems and everything, but, classically, that's called, like, the waterfall solution, which is a bad word these days, right? So, where do you draw the line between planning everything and planning just enough?
\n\nMATT: But planning being the operative word here, right? You can be extremely agile. You know, I've worked where we were extreme programming weekly sprints. We planned every single week. We had our work ready every Monday for that week. You can break problems into smaller problems and then just plan those smaller problems. But you do have to have a really good idea of what the primary problem is, right? And the thing you're trying to solve for and your ultimate goal. But once you understand that, you can break it into small problems, and then you plan pieces at a time, and you can be super effective.
\n\nWILL: I do agree that, like, waterfall is a dirty word, and it should stay one, frankly. Because where I see things go, like, most badly, is shipping these grand visions versus tiny, little, agile, incremental pieces. Maybe analogize it with the sort of, like, the Apple iOS grand reveal of the new version of their operating system. Versus maybe, like, the Google Android, like, things are coming out all the time. Like, what's even the current version?
\n\nJUSTIN: [laughs]
\n\nWILL: Is it Oreo, or Nougat, or Zeta [laughter], or whatever? I don't even know. Like --
\n\nMATT: But do you care?
\n\nWILL: Come on, who cares? Stuff's coming out just helter skelter pelmel, all the time, right? Versus, like, this, like, this grand, like, unveiling that happens once a year. It's cool that Apple can pull that off, you know, but, like, --
\n\nMIKE: Will, do you think that, internally, they're actually having a grand pull-off? Or do you think that they're doing the same thing that Android is doing and they're just tidying it behind the scenes doing these incremental builds, and when they finally have it ready, then they push it out? I think it's the latter. Like, I think that --
\n\nJUSTIN: Yeah, I think it's the latter, too.
\n\nMATT: Yeah, I mean, when you're incremental, you're mitigating risk.
\n\nMIKE: Exactly. There's huge risk when you're doing it. So, there's aerospace example, and it's easy because it's big, expensive projects people know about. There's the Space Launch System recently launched successfully. After years, you know, they finally have a launch. I don't think they...[laughter] they, like, don't even launch a real payload, and it costs, like, two billion dollars, or something, just to launch, not the development but, like, the launch costs that. And then, I read the other day that one of the SpaceX rockets, the Falcon 9, did its 20th launch, reused, like, the same rocket, launched its 20th time.
\n\n[laughter]
\n\nAnd, you know, I'm sure it costs some millions, but orders of magnitude difference in price. And SpaceX has blown a lot more things up, but they did it on purpose because they said, "We're going to do this incrementally, and we're going to start small. And we're going to iterate." And now they're just the steamroller that is launching more rockets than, like, all of the nation states put together.
\n\nMATT: They're miles ahead.
\n\nJUSTIN: Yeah, if only they weren't led by a crazy guy, but anyway.
\n\nWILL: Well, you have to be crazy.
\n\nMATT: That's why they are so successful [laughs].
\n\nWILL: Because, I mean, like, there's...I --
\n\nJUSTIN: Okay. So, at the start, he was crazy, but he was focused on his stuff. Now he's crazy and focused on other things; at least, that's what it seems like.
\n\nWILL: A lot of those guys are difficult people. Steve Jobs, God rest his soul, [inaudible 20:24], you know what I mean, had his halo shined considerably in his death. And, at the very least, he was disciplined enough to keep his mouth shut and most of his sociopathic behavior behind closed doors. But, I mean, like, the stories abound of that guy doing terrible stuff, and he never really stopped. His PR team got better, but, like, he was a jerk till the day he died. God bless him, you know?
\n\nMIKE: One thing that they have in common, though, is that they honor the engineering process. And I'm not going to even touch Elon Musk as a person, right? That's a topic I'm just not going to bring up here. But he came from the software world and brought that engineering process and cultivated it among engineers.
\n\nMATT: That is very true.
\n\nMIKE: It really doesn't matter about him, right? What he brought was the process. He brought the agile engineering process with him from software world and just applied it to aerospace, and it works. If you do it, it works. If you don't do it, a recurring theme here, it doesn't work.
\n\nWILL: I think it is a validation of that process, you know what I mean, in a lot of different, you know what I mean? You're moving that into other industries and avenues, provided that it is permissible to explode the rockets, and there's nobody [laughter] on them.
\n\nMATT: And we all agree, waterfall, bad word. But I would argue a waterfall process is better than no process at all.
\n\nMIKE: Sure. So, I think a lot of people they think, Agile, hey, we don't have to plan anymore.
\n\nJUSTIN: [laughs].
\n\nWILL: You can't be farther from the truth.
\n\nMIKE: Exactly. All you're doing is you're tightening your planning loop, right? You're tightening your feedback loop. And instead of doing all of your documentation upfront when you know the least, you are choosing to actively plan, and document, and iterate the whole time. So, instead of doing it once, you never stop doing it. And if you think that being agile means, oh, wait, you know, I'm just not going to plan at all; we'll just wing it, then you're missing the whole idea, which is that these interactions, the communication is hard, and that interaction is critical. And you need to have interaction with your hardware, with your stakeholders, with your software. You know, you're testing it. You are evaluating it. You're improving it continuously rather than once.
\n\nAnd it's actually more planning work in the end because you're doing it along a line. But because it's distributed, it's more efficient because you're doing it when you have the most information, which is after you've already done some of the iterations already.
\n\nMATT: And it becomes easier with experience because then you have that association. If you've been doing this for a while, which all of us have, there's very few problems that we have never seen before. They just are in a little different context. But, generally, it's the same problems over and over, and we know how to solve them. I think --
\n\nMIKE: You're taking text out of the database and transforming it and showing it to somebody?
\n\nMATT: Exactly [laughter]. It's only data, right [laughter]? But, you know, there are new things coming out, AI, for instance. GenAI is new to a lot of people, and we're going to learn that as well. And it may be a little harder to plan those technologies because we don't have the experience yet. So, we may not be as accurate with our estimates on those types of projects. But, for the most part, most of the work we're doing, we have done before in some form. And if you break it down, isn't any different than other problems we've already solved.
\n\nJUSTIN: So, I do want to add a caveat to that. Well, not a caveat, just, like, an addendum. It's interesting the organizational changes that are happening within Acima, right? Well, Upbound, right? And last year was, like, a record year for Acima and RAC. And this year, we've got a big organizational change where teams are shifting. Directors are shifting. Product owners are shifting. There's a lot of moving parts here. And I'm afraid that they're going to expect the same record level production from an engineering standpoint that they had last year this year because it's, like, oh, we're reorganizing in a more efficient manner. That means we're going to do even better. And it's like, maybe long term, but that short term is really going to suck.
\n\nMATT: Well, and maybe it's up to us, right? Well, it is up to us. I really think, just highlighting what I just said, if we look at it as these aren't different problems; they're the same problems, whether I was on Team A or Team B, I'm still facing the same types of problems today that I was yesterday, and we approach it in that manner, I think we can be absolutely as efficient. Change is hard for people. When you are shifting so many things around all at one time, it's up to us to kind of get our bearings and have that compass to remind us that we're still doing the same thing.
\n\nMIKE: Well, there's a couple of things that need to happen. First of all, we should work very hard to preserve team boundaries where we can. Like, let's not disrupt high-functioning teams. Second, leadership needs to be focused on using this as intended to improve lines of communication and not just change them. You know [laughs], let's just shuffle things around, and it looks better on a whiteboard. That's just going to slow us down.
\n\nIf we see that there were...you know, in a large organization, there are difficulties with communication; of course, there are. And if we reorganize to try to improve that while allowing the engineers to keep doing their work with minimally disrupting the teams, then we could actually become more effective. But that is a, you know, to Matt's point, it's up to us. Like there is a decision point here, and we have to be aware of that destination. We have a choice, right? We make things better, or we make things worse.
\n\nWILL: So, I mean, in regards to, like, sort of, like, these major, like, company-wide reorganizations, how do you account for and even measure sort of, like, impacts of the reorganization, right? Like, impacts on sort of, like, planning bandwidth, right? I mean, you've got people who are, like, coming up with a plan for the next sprint, writing the tickets, like, measuring the stuff out, right? And so, like, they have a certain amount of planning that they can do, right? And that's affected by their familiarity with, like, their operating environment, right?
\n\nLike, you bring a manager into a brand new team. They haven't touched any of the code. They have, you know, a certain amount of planning bandwidth, right? And, like, that's going to be constrained by them getting up on the stuff, right? You have a new team, right? Okay, you know, like, you don't want to disrupt high-performing teams. But, honestly, like, maybe you do want to give your A players your biggest impact priority work, right?
\n\nSo, you move those people in, and they have to acclimate, right? How do you account for impacts of reorganization? Because this is something that I have seen as well. You know, the large retailer that I work for they love their Q1 reorg. They love, you know, rearranging the furniture. But they're going to have a cost, and I don't know that the cost is accounted for organizationally.
\n\nMIKE: And because it's hard to measure, it doesn't get measured, and --
\n\nWILL: If it doesn't get measured, then they can't plan for it, you know what I mean? Upper management, you know, those executives that are sort of, like, rearranging the furniture they don't have that. Do they have that in their heads? Do they have it in their mind? There's a cost. We've all felt it.
\n\nJUSTIN: I think you treat it as you would, you know, you're onboarding any new member to your team. This is something that happens all the time with engineering teams. People leave; people come in. And you have to get to know this person and, you know, put them through the same onboarding and really get to know their capabilities and stuff. And so, I think your estimates are going to suffer a little bit until you've had a couple of sprints with them. You treat that as an unknown, and make sure you communicate that up. That's kind of what you would do at the team level.
\n\nAnd then, I would think that the folks in the engineering leadership, if they make changes at team levels like that, they just need to get those lines of communication going such that you can set expectations and really understand, "Hey, we just on-boarded two new people, you know, our estimates are going to suffer for the next sprint or two. And then, we'll be able to give a more accurate estimate after that."
\n\nMIKE: And there's that bigger question. What metric can you use to measure, aggregated across teams, across an organization? What metric can you use to capture effectiveness as you're doing a reorg? Because we know every metric captures a slice of something and has its own biases. So, what would be an effective metric? Does anybody have an answer to this? What's an effective metric to see how...when you do a reorg, what do you use to measure it? Did this work?
\n\nMATT: Velocity over time. I mean --
\n\nMIKE: The tricky thing is velocity is team-specific. You rearrange all your teams, velocity changes. If you measure that, then everybody's going to say, "Oh yeah, we're just going to have..." this is five points. That's not three. That's five. Like, you're going to bias it toward higher story points, and velocity ceases to become effective as a number. So, it's hard to measure that precisely. And business initiatives aren't exactly equal to each other. So, you can't necessarily say, "Oh yeah, we've done five initiatives per year [laughs]." It's a tricky problem.
\n\nJUSTIN: Yeah, I think if you had an answer to that, you could write your software engineering estimation book, Mike, and retire on that, so...
\n\n[laughter]
\n\nMIKE: But it's not a new problem. It's not a new problem. Everybody's dealing with it. And then, we fall into these gut, you know, we don't have an answer, so we just kind of look the other way and go with our gut and don't measure it very well. And then, maybe you have your annual reorg [chuckles] that does more harm than good.
\n\nWILL: Well, I mean, I don't know. I mean, I feel like you ought to have, internally, a general rule of thumb for, like, okay, if I have a new hire, this is what I expect the onboarding to look like. At week 1, I'll get X. At week 5, I'll get Y. At week 10, I'll get Z, right? Like, you'll have an arc of their productivity, at their level, right? Like, you know a junior will onboard. You know a senior will onboard, you know, et cetera.
\n\nAnd then, like, I think you should probably also have, like, a rough idea of what an internal transfer is going to look like, right? Like, if I move from, like, you know, Team A to Team B, it's not going to look like a new hire, you hope. Although, depending on the team, you know what I mean? Like, I know I'm familiar enough with Acima that there's some teams that you don't just, like, walk into [laughter].
\n\nMIKE: One does not simply walk [laughter].
\n\nWILL: One does not simply walk into a --
\n\nMIKE: An underwriting -- [laughs]
\n\nWILL: Yeah, underwriting. Yeah, underwriting.
\n\nMATT: Or the [inaudible 31:48] service.
\n\nJUSTIN: [laughs]
\n\nWILL: Oh no, that one is fine. Like --
\n\nMATT: Oh yeah, you worked on that team.
\n\nWILL: Yeah, the Haskell. The Haskell, the Haskell folks, you know what I mean? Like e-comm.
\n\nMATT: Oh, Lambda.
\n\nJUSTIN: Lambda. Yeah.
\n\nWILL: That one's there. You know, there's stuff you don't just walk into. So, like, you have that, right? Then you say, okay, reorg. Then I have, like, X number of, like, people moving teams, and probably the same for managers, although, I mean, I will say that, like, I don't think we think enough about management sort of, like, the bandwidth, right? You know, like, we spend a lot of time thinking about, like, okay, coordinating engineers, right? But, like, management bandwidth in terms of planning bandwidth I think it's, you know what I mean, I think it's a little bit unsung. We have a general feeling for, you know, how many engineers a manager can be sort of overseeing, but beyond that, it gets pretty mushy, wouldn't you say? Or am I wrong?
\n\nMATT: No, I think about that every day. I'm new to the management team over here on the Upbound side. And it's true that bandwidth gets spread a little thin, right? And that's part of being able to organize your team, having the right people to lead those teams. And everyone has been on...well, not everyone. But a lot of us have been on very large teams versus, like, 3-to-5-member team and seeing the difference in efficiencies, right? And how those teams are managed.
\n\nAnd, ideally, smaller teams, in my opinion, are better. So, you need to do that with management as well and whether there's levels. We have a new concept here at our company of delivery managers. And they've kind of taken over a lot of that responsibility to kind of help spread that bandwidth for planning and let people focus where they should be focused. That's the way think about it.
\n\nMIKE: So, we've wandered far and wide here a bit [laughter] as to...we started, like, well, yeah, we know what it takes to run a team well. And then, we started getting into all the complexities when you increase in scale, you know. You go to the next tier, and you've got managers and managers over managers over managers, and it can fall apart. Because, at any place in this hierarchy, if somebody isn't paying attention to the rules, then it can fall apart.
\n\nIt seems to say something about what you do to run an effective engineering organization is that everybody has to be aware of what the constraints are, be upfront about them, and be willing to stick to some simple rules, right? The planning happens. It happens every time. Every time you can. You don't give it a short shrift, you know; you keep on it. And you don't skip it at any tier.
\n\nYou know, up at the top level of management, you know, they have to make some estimates based on incomplete information. That's something we all have to do. But they do everything they can to follow the best process they can: gather the information, make the best estimates they can with the information. It has to be all the way down. And then, you have a really well-run organization, right?
\n\nWILL: Mm-hmm. Is there [inaudible 35:06] where, like, people who are just sort of guessing, because the company...and what I mean by that it's like, sort of if you say, like, okay, I've got a corporate, let's call it, like, five-year plan, right? Which is not a crazy thing, like, you don't get a business corporate, you know, strategy kind of a thing, right? But on a software, you know, estimation sort of a thing, that's [laughs] a joke. That's comedy, you know what I mean? Like a five-year, like, I can't plan that, you know what I'm saying? And so, it does need to be done on some kind of level, right? Where does that transition happen, and how?
\n\nMIKE: There's a really good thing that we've done for a few years now that's spreading throughout the organization, which is that we recognize explicitly that there are tiers of planning. You can map these to a couple of really useful things. You can map them to groups of employees, or you can map them to Jira issue types. And it works either way. So, tier one, you know, planning level one is what the executives do, and it's associated with an initiative in your project management software.
\n\nTier two, planning level two, is associated with milestones within that initiative. I'm going to expand to Columbia, so I've got an initiative. And then, when it comes to milestones, well, maybe you need to negotiate with the government contracts, you know, maybe you need to build some sort of new tax integration. You know, figure out whatever those pieces are. You're developing the milestones, right? But now you have something that's a bigger shape.
\n\nAnd then, there's a tier-three level of planning. Now you're talking with your team leads. Those team leads are breaking this, and that's associated with, like, an epic in your project management software, where now you're coordinating between teams. You know which teams are going to be working on it and where those boundaries are, you know, who's going to be working on what.
\n\nAnd then, you have a tier four, you know, planning level four, which is within the team. That's your refinement, your sprint planning, and so on, where now I know what my team needs to do, right? So that I know what those boundaries are. And I have the epic, so I know what the overall story is I need for my team. Now, I need to break that down into the two and three-pointed stories.
\n\nAnd that works really well because, at every level, you're doing planning based on the information that you have. And you recognize that the accuracy of that planning goes up dramatically as you go from levels one to four. By the time you've done a level four planning and you've completely pointed something out, you know, you can say pretty well when that's going to land.
\n\nWhen you're just at the initiative level, you're like, I'm going to expand into Columbia, right? You really don't know. You really don't know very much, but you know something, right? You know something. You know that that is a business priority that you can shuffle around with other business priorities and say, "Well, this is something I want to do first. And I can start to gather information on it.
\n\nWILL: Well, okay, sure. But, I mean, like, so, like, you know, a company like the size of Upbound, right? It's a public traded company. They need to have, like, sort of, like, forward-looking projections about, like, when is this stuff going to land, you know?
\n\nMIKE: Yes.
\n\nWILL: And what are the business impacts and, like, because, like, because they're beholden to their shareholders. Their shareholders want regularly scheduled updates about, like, okay, you've got an initiative. When am I going to get the initiative? And, I mean, like, is the best we can do on these initiatives just sort of, like, we've done it before and this is about how long it took, you know what I mean? Like, where it's like, okay, you know, I did this, you know, when I expanded into Cincinnati. Like, this is what I got and how. And if I'm doing Columbia, then it's going to be, you know what I mean, ten times harder than doing Cincinnati, right? Like, you got a whole other regulatory language business entity, et cetera. Like, is that the best you could do?
\n\nMIKE: Well, I think you can even put time frames on here. So, I'll say, also, that this map roughly to divisions of time. Annual plan, initiative. Quarterly plan; it may be milestones, right?
\n\nWILL: Right.
\n\nMIKE: And then, you can slot your epics, perhaps, into months. And by the time you get to your stories, you can get that down to about weeks. It kind of maps loosely. Again, this maps to some of these divisions. The precision you get gets more specific. And, generally, at the executive level, you're usually communicating at an annual or a quarterly level. You say, "Well, this year, we intend to expand into Columbia. By quarter three, we expect to be operational at some stores," and so on. You know, you speak in those kinds of broader periods, right? Your resolution is a lot less fine-grained, and that's okay. That's actually expected.
\n\nWILL: How do you enforce discipline? I mean, I know, like, on the tier 4 level, right? You're sitting like, okay, I want two or 3-point tickets, right? Like, I want two or 3-point tickets. I want, you know, that's all I want. And, like, if you're doing five or, God help you, an 8 [laughter], you know, things are probably going to go bad, right? And I see how that fundamental process it's got to scale up. But it's a lot less clear how you enforce it, you know, as you go from tier 4 to tier 3 in planning or tier 3 to tier 2 planning or tier 2, God help you, to tier 1 planning. How do you keep a lid on that? Well, because it matters. Like being off by a quarter, that's a big problem.
\n\nMIKE: Right, right.
\n\nMATT: It is a big problem.
\n\nWILL: And for a tier 1, being off by a quarter is actually doing a pretty good job, in my opinion.
\n\nMIKE: I agree.
\n\nWILL: You're delivering an initiative, and you're only off by a quarter? Not bad, y'all. Not bad.
\n\nMIKE: [laughs]
\n\nWILL: You know? Like...
\n\nMIKE: So, one thing I think you can do...and we talked about the rules down at tier 4, right? That's what we think a lot about. But there's no reason you can't have documented rules at every tier. This is the output. This is the data that went into it. And these are the requirements. Like, you don't say that this initiative is going to get done this year, and unless you have done this, this, and this [laughs], being off by a quarter, that's...it's going to be hard to be within a quarter resolution.
\n\nBut you can do the things, the executive things [laughs] that executives need to do: gathering information, delegating that out to people that you trust to go and gather the necessary information, and establish a culture that demands honesty and rewards it, rather than one that rewards saying, "Yes." I mean, there's things that can be done there. And now we're getting into business management.
\n\nTo bring it back to the beginning, we've all got some landmarks we're trying to move our way towards. Hopefully, this has provided some food for thought, how to better figure out when we're going to get there.
\n\nWILL: Cool. Thanks, y'all.
\n\nMATT: Yes. Thank you, everyone.
","summary":"","date_published":"2024-06-13T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/003f19ed-16fc-4295-82ec-3f92d98ce964.mp3","mime_type":"audio/mpeg","size_in_bytes":25412373,"duration_in_seconds":2558}]},{"id":"3b5f9d7b-fa63-40de-9a00-4d3a450c23a6","title":"Episode 47: Onboarding New Employees","url":"https://acima-development.fireside.fm/47","content_text":"The panel delves into the challenges and strategies of onboarding new employees to discuss the importance of communication, mentorship, and understanding context. Mike shares a story from his construction days in New Orleans, where he learned the value of being paired with an experienced team member. This buddy system helped him overcome communication barriers and adapt more quickly to his new environment.\n\nEffective onboarding involves more than just providing documentation. While documentation is valuable, it must be up-to-date and supplemented with hands-on guidance and practical experience. The panel advocates for giving new employees context about their tasks and the organization. This can include having them use the software as end-users or working directly with customers to understand the system and its impact better. Regular check-ins and skills clinics are also recommended to help employees stay updated and improve their skills.\n\nAdditionally, the podcast highlights the importance of continuous learning and mentorship for all employees, not just new hires. Regular mentor-mentee interactions and collaborative updates to documentation ensure that onboarding remains practical and relevant. The panelists also note the pitfalls to avoid, such as not following through on commitments and assigning unsuitable onboarding buddies. \n\nTranscript:\n\n MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today [laughs]. With me right now, we've got Justin, Dave, and Matt. We're going to talk about onboarding new employees. It's a tricky problem. I don't know that anybody has it perfect, and I don't think we have it perfect. So, we're going to talk about some ideas, some things that we've seen go well and maybe not so well. I've been remembering onboarding in days past. \n\nI tell a story about the late '90s. I was living in New Orleans doing construction work. We would go in and remodel office space. So, sometimes, we'd tear out everything and then rebuild it. You know, we had teams all over. The company I was working for had teams all over the city doing this. And the team I started on, I started just as a laborer. I was not doing anything fancy to begin with. \n\nBut what I remember is a couple of things. The day I started, the foreman I was working with set me up with a partner. His name was also Mike [laughs], and they called him Big Mike. And they sometimes would compare him to George Foreman because they looked similar. He was a big guy. He previously worked out on the oil rigs out in the Gulf of Mexico and a big, strong guy. And we got to be fast friends pretty quickly.\n\nHowever, the day I started, I had not been living in Louisiana for all that long, and he grew up way out in the Bayou somewhere. And when he started talking to me, I picked up about one word out of three of what he was saying [laughs], maybe. And it was that way for a few days. You know, maybe started out with one word out of three. After a while, I got to two out of three. There's a mix of accents there. If you've got a Southern accent and a heavy French accent... \n\nDAVE: Mm-hmm. The Creole.\n\nMIKE: Plus, there's some African-influenced accent as well, and you mix those all together. And I'm a White guy from farther North [laughs]; I did not pick up very quickly. But we got to be friends. And he was patient [laughs]. He was patient with me. And, actually, after a few months, we'd hung out outside of work. We were actually quite close friends. We've lost touch over the years, but I'd love to get back in touch with him. After the storms they had down there, that drove out a lot of the population. He's probably moved, and I don't know where he's gone.\n\n[laughter]\n\nBut there are things about this story that were relevant. First of all, the foreman did a great thing. When he brought me in, he paired me with somebody so that I didn't have to know everything. I just had to be able to ask Mike, and [laughs] we could get some stuff done. The second thing is communication is hard [laughs]. We were speaking the same language, and we still couldn't understand each other. He could probably understand me. I was the one who was struggling [laughs]. \n\nBut, you know, it took us a while to get things right, and we had to work on it. It had to be an active, active effort, especially on my part, to learn to understand. And working on it worked, though. You know, over time, we got to work really well together. We were frequently called on to get a lot of stuff done because we had more effective partnerships [laughs]. We both had enough carpentry skills that we could get a lot done besides just being laborers. \n\nI lay this out, and it's outside of software engineering. I think a lot of times, it helps to think about something outside of software engineering to lay some context. We bring people in, and we let them loose. And you've got to figure stuff out. You may be talking with somebody [laughs] who has a different background, and he's going to use the same words and mean different things, and you're in an unfamiliar project. There's a lot that has to happen for you to onboard successfully. \n\nAnd there's a few things that I think make a huge difference to be successful and one of them is that regular communication with somebody. And another is, you know, well, getting that communication, but having a buddy, right? Having that lifeline, I think, are some of the key aspects I've seen be effective in onboarding. I think there's a lot else as well, but there's my story to launch this off. And what do you all think? \n\nMATT: Well, you hit on communication, and while I think, you know, trying to dissect a Creole Cajun dialect is tough, [laughter] there's also communication differences in the same language and dialect. For instance, the four of us all have very different communication styles, and I think being able to pick up on that and how people communicate, and their intent is a very important aspect of that. \n\nJUSTIN: I like how they assigned somebody to you who was already part of the thing. They had, you know, knowledge that they've built up as kind of a veteran working there. And they were able to answer your questions, and you were able to be much more effective because you had somebody to ask questions to, and they had to answer right away. You weren't, like, left alone. \"Go do your thing [laughs].\"\n\nYeah, I've had experiences with both. And a lot of how you communicate culture to a new team member is, you know, whoever is introducing you, and whoever your onboarding buddy is, whoever you have the most exposure to, that is how they view the whole company almost. And if you don't have somebody, you know, doing that correctly, you don't have a good communication in not just, you know, knowledge, but also culture, and friendships, and there's a whole bunch of stuff there.\n\nDAVE: But, for me, it's, like, context. There's so much out-of-band stuff you can pick up by, like, a personal interaction, where I was talking with Adam a while back, and I'm like, \"I want to pair with you on this problem.\" And he had been thinking through this problem. And he's like, \"Well, I know it's not the login. I know it's not this. I know it's not this conditioning thing. I know it's not this sequence in the system.\" And I'm like, \"Adam, I need you to take me with you to hunt badgers.\" And he's like, \"What do you mean?\" And I said, \"I don't need you to show me how to shoot the badger once you've found it. I need you to take me through the hills and show me every place you check for badgers. That's what I need.\" \n\nBecause he was thinking, I don't want to show you the login system because that's not going to be the problem, and I don't want to show you the pipeline because that's not...I'm like, no, show me that you checked the login, right? Like, literally, the gift in the box was not what I wanted. I wanted the box, and the wrapper, and [laughter]...right? And all the trappings that went with it.\n\nMIKE: That's interesting. You wanted the box. \n\nDAVE: Mm-hmm. \n\nMIKE: Again, this is a little bit outside of engineering, but it's related to that. You know, you think about math class. You can memorize the rules for solving a problem. And as soon as you forget any one of those or you make one little mistake, you're just completely lost. But if you can have somebody who takes the time to help you understand why you're doing what you're doing...and it takes a lot longer. It absolutely takes a lot longer, and in a classroom setting, that's hard. You know, it's a gifted teacher who can bring everybody to that level, and that's, you know, a difficult thing to do.\n\nBut if you can do it, if you can help somebody get deep mastery of why those things are there, you know, teach the intuition and understanding, if somebody gets lost, they can backtrack. You know, you can figure out what you're doing or even come up with your own way of doing things and be creative about it. It completely changes your perception of that problem-solving. We're in a problem-solving industry. That same idea is directly applicable. If you could show somebody this is what you do and, you know, tell them to just do that, it's not very useful at all.\n\nMATT: The journey is just as important as the destination. \n\nJUSTIN: I think, to kind of summarize, if we were to put, like, points on a board about, you know, how do we onboard someone, so, right at the start is, like, choose an onboarding buddy who's going to be very helpful for this person in whatever. And I think that's part of leadership's responsibility, you know, whoever is in charge of onboarding this person, whether it's the tech lead, or the director, or whoever the team lead. So, they need to make that decision of who's going to be this person's onboarding buddy. And then recognize that that's going to take time, and that's real work. And you can't, like, you know, expect them to do the same level of work as they did before, perhaps, because they are, you know, if they're going to do it right, it's going to take time.\n\nMATT: And based on the information we have about these new hires, who is going to be the best fit, not only in experience, but personality type, communication type, those things? \n\nMIKE: That investment can go a long way. If you do your onboarding poorly, then you're going to have somebody who doesn't know what they're doing. And somebody can sit around for months and get very little done. They'd be busy, busy all of that time, and not get very much done because they don't know what they're doing. \n\nDAVE: I can't tell if I feel seen or attacked there, Mike. \n\n[laughter]\n\nMATT: But that's important, right? Encouraging people to ask questions and not just sit and spin their gears, ensuring that they understand the things you're going through and leading them. You know, I could sit and write code for hours and have someone paired with me. But if I'm not ensuring that they're understanding what I'm doing, communicating my thought process of why I'm doing it, I don't feel like I'm really helping them. And they're probably not learning a whole lot during that time, right? \n\nMIKE: One thing about our brains is they don't tend to stay connected to something they're not actively engaged with. You show me somebody who can watch somebody do a detailed technical task for a long period of time, and [chuckles] I'll show you something imaginary [laughter]. It's not the way our brains work. \n\nDAVE: There's a really great experiment that demonstrates this, which is that if you just start reciting numbers at somebody and say, \"Memorize this. You don't get to write it down. Just memorize it,\" we tend to be able to hold about seven numbers. Like, some people are down to five. Some people, as many as nine...can hold this in their working memory. And what we miss is that if you can tie these things together with a story...the people that memorize Pi out to, like, a million places, they have a story that ties all the numbers together, and where you are in the numbers, where you are in the story, and, to them, it's just one story. \n\nAnd that is the essence of, like, \"Oh yeah, you know, sign into this. The database is over here. The server is over there.\" And I'm like, okay, that's three things that aren't connected [laughs], right? And there's 23 more to go. You better start making a story out of this for me [laughs]. \n\nMIKE: You know, that says something, right? Without that story. And it also says something about communication. You know, a lot of the best communicators will dip into stories that don't directly connect to the material they're talking about. But then they'll make the connection like, oh, that's great. That was entertaining. And it's entertaining, sure, but it's a lot more than that. Without that story, you would never have learned the idea in the first place. \n\nIt may superficially look like they're just trying to make things fun, but that's really not what...making things fun is not what really good communicators do. What really good communicators do is connect you with the material they're talking with. That could be fun, and it's going to be engaging, but the goal is different. They're not trying to force something to be entertaining. Let's make math fun. No, they actually see the fun in it. They see the story, and they want to share it. \n\nDAVE: I had a co-worker...oh gosh, this was around Y2K. This was a while back. And we were struggling with the inheritance rules. I had some co-workers that didn't understand, like, protected versus private versus public versus, you know, friend was the thing. I blurted out the rules of C++ inheritance in terms of intimate encounters, right? Your children cannot touch your privates. Your friends can touch your privates, right? \n\nI got sent to HR, which is fine; I deserved it. But a week later, I'm typing away at two cubicles over. I hear, \"Damn it, Dave!\" [laughter] And I'm like, \"What?\" He's like, \"I know the difference between protected and private, you jerk!\" and just kept typing. And I'm like, yep, that's in your brain rent-free for the rest of your life [laughs]. I've gotten better at little, you know, more tasteful stories since then. You're all going to remember it now, too. \n\n[laughter]\n\nMIKE: So, reinforcing the point about stories, having to have that connection and the importance of context, the importance of context. \n\nJUSTIN: Related to that story there and onboarding new people, the best places I've seen that do onboarding is where you come in, and you're actually onboarded as a user of whatever system that you are going to be doing, and so you know how the users are using it. And you can see, you know, oh, okay, here I'm a customer service rep, and here's me logging in, and here's me helping a customer, looking up the customer name. And then, here's me looking up their lease number, and their payments, and their history, and things like that. And I can, you know, see there. And here's the customer service rep complaining about something.\n\nAnd so, you go in, and you spend a day or two just immersing yourself in that system. And then, you come back, and you have a story in your head of how this thing actually works from a front end, and then you can dive into, oh, okay, this is how the app works. And this is what is actually happening, and this is where the data is being stored. And I understand what's going on here. And here's this third party that we're calling, and things like that. So, that right there is key, for me, to understanding, you know, see how our users are using it, and then I can see behind the scenes. \n\nDAVE: There's a fundamental problem in computer science, and I call it the A versus B problem, which is where this system over here, you got A matching up against A, and it works. System B matches up against B, and it works. And you get a bug that comes in. Your trouble ticket is, I did this. I expected A, but I got B. And you're like, okay, should you be getting A, or should you be expecting to get B? Which is the right answer, right? It's like, oh, plus four on the zip code. This piece over here only has room for five digits in the printing label. Don't ever put a plus-four on there. That's a bug, right? Anybody else working with postal codes is going to be like, no, you always want the plus four. Why would you want to throw away data? \n\nOne of these is right. But if they don't match, you have to know which one of the two is correct, and it's the context. Seeing a user use it is what, you know, it's like, if this is checked or unchecked, if it's checked, we always do the thing. And if it's unchecked, does that mean we can do the thing, or does it mean that we never do the thing, right? There's that context to it. \n\nMIKE: You know, you talked about sitting in the place of customer service and using the software. I'd take that even further. Some of the most successful onboarding I've seen is when the new person is actively assigned to work with a user of the software. It's not always possible. It depends on the context. But you can have them sit with customer support and help them field calls for a couple of days, or, you know, go out in the field and use the software with the users. You know, actually using that software with real users provides a depth of understanding that I think is almost impossible to get otherwise. \n\nDAVE: I can think of a time when I have been sent to work with the end users that...In 2006, I worked on a system for a year, and I finally got to go sit with the users. And this has happened every time I've sat with users. And I was surprised after a year that this still happened to me. I walked back into the bullpen with my co-workers the next day, and I said, \"Guys, we're building the wrong thing.\" Just half a day with the people using it, and you realize we are going around welding shut every door that you need to access. The way that we're trying to get you in and out of the system is like crawling up and down the chimney. We have built this completely wrong. We need to put a lock on this door and make it swing easily instead of messing up your life, yeah. \n\nMIKE: So, we've talked about a few things: having a buddy [laughs], taking the time to get context, assigning somebody to actually use the software, and, if possible, pairing them with real users. Saying that all of those are important for onboarding. How valuable do y'all think documentation is? \n\nJUSTIN: I wouldn't want to dive into documentation to start off with. I'd want to go to those other things first. Because documentation is great. I love documentation, but without the context, I don't know if that documentation is dated. I don't know if it's, you know, even applicable for the system I'm on. And so, without that context or without asking my buddy, it's almost worse than having no documentation [laughs]. You could be looking, like I said, at outdated stuff, or you could be doing stuff like that.\n\nBut later on, when I'm more experienced in the system, I love documentation because I have the context there, and I'm just looking for details, or maybe some other stuff when I already, you know, have a good, solid base of everything. So, yes, documentation, but I don't want to push a bunch of documentation at somebody who just started yesterday and say, \"Read all this [laughs],\" so... \n\nDAVE: If it's a part of the system that is very static, very stable, and we've been using it for five years, then yeah, hand you a piece of documentation that says, \"Start here. When you're done, you will have this. Here's the steps.\" And that's kind of fun sometimes where you hand that to them and say, \"We're trying to improve this documentation. Please go through this. And as soon as you get stuck or lost, come find me, and we'll fix the documentation.\" That's a lot of fun. \n\nAnd, again, there's a trick to that, which is now they're engaged looking for the problems in the documentation. And now they're paying attention to the system. Instead of \"Memorize these seven things and plug them in,\" it's like, \"Okay, I'm in step three. I don't have access to Postgres. What should I do?\" right? \"Oh, let me add that step.\" \n\nMIKE: You know, I think we all wished we had perfect documentation. But documentation is a lot of work, both to create initially and to keep up to date. And I'm not complaining about documentation. You know, any documentation is almost necessarily out of date unless you keep it in lockstep with your changes. Unless any changes to documentation go out exactly with any changes to your software, it's going to be out of date kind of the moment it's written. \n\nSo, it feels like there has to be another layer, either you put a huge amount of effort into your documentation, which I think is unpalatable for a lot of organizations because the work is hard; it's expensive, or you have some system outside of the documentation to communicate some of that knowledge. And that's hard. That's a tricky balancing act. Because there's probably things in the documentation that somebody is going to forget to tell you. \n\nSo, to ask another question, I asked about documentation: how do you avoid those gaps? And we've talked about the value of partnering with somebody. What happens if you never happen to walk by that hole in the ground? You say, \"Don't step in that.\" [laughter] How do you avoid that? What are some things you can do to avoid some of those gaps in knowledge? \n\nJUSTIN: Document. Oh, wait [laughter]. Find it out and document it. I like what you said, though, when you have your mentor there, and you have your new onboarding checklist, you know, to get permissions for all the things and to get all your environment set up. If you're both doing it together and then you update anything that's missing or, you know, common missteps on that onboarding document or series of onboarding documents, usually, that's really helpful, and it kind of updates itself as you onboard new people. And that way, you aren't dealing with an onboarding document that was last updated in 2021. \n\nSo, I don't know if that answers your question exactly, but that, you know, goes back to having your mentor and you going through it together and updating anything that you find is missing. \n\nMATT: And things change, right? Something that was relevant even as recent as, let's use our company for an example, five months ago isn't relevant today, right? Because we're doing a lot of things differently. So, if we can make these things a living document and adjust as we go, and maybe we find a better way to do something that we have documented or a different way that's more efficient, then we can update it and keep that document living. And it provides a lot of value for the next person coming through the line. \n\nMIKE: So, we've got another item in our checklist here [laughs]. Have the new person work with their mentor to update the documentation as they go so that it does become that living document as they're using it. One thing...I still think that sometimes you miss those things, the things that you didn't think to document that everybody just knows. One thing that I've seen among people who've been really successful, a lot of times, they'll say, \"The time I learned the most was when I didn't have anybody else to help me, and I had to do it on my own.\" \n\nAnd [chuckles] maybe they're at a job where they're the only engineer, or they took over DevOps. You know, whatever the case may be, a lot of times it's when [chuckles] somebody had to take care of things themselves, and there's nobody else to go to. You have to figure it out. And, boy, that burns [inaudible 22:22] your brain. \n\nMATT: Trial by fire. \n\nMIKE: But, you know, we don't want to lay everybody off once a month just to give somebody a chance to do that. That's not a good way [laughs] to run a company. So, we're not going to do that. So, I think that setting up some sort of environment that gives people an opportunity to learn and more of a sandbox is really useful. One thing I've seen for security training that was extremely helpful is we rotated weeks. And every week, somebody would add an insecurity to the application from the OWASP Top 10. And then, the rest of the team, knowing that there was that kind of vulnerability in the app, would look for it and try to exploit it.\n\nJUSTIN: In production? \n\nMIKE: No. \n\nMATT: No.\n\n[laughter]\n\nJUSTIN: Okay. \n\nMATT: No.\n\n[laughter]\n\nMIKE: We built a...We built a...\n\nDAVE: So, they're playing. They're just not playing for keeps. \n\nJUSTIN: Yeah. I was like --\n\nMATT: I believe, Justin, this goes back to when you first came aboard. I remember I was doing the OWASP Top 10. Prior to that, the trainings were an application that Mike actually had hosted on his AWS instance called Insecurity. And then, we moved over to the Juice Shop when I took over. But prior to the Juice Shop, it was this Insecurity app that we did exercises on. \n\nJUSTIN: Oh, that's really cool. \n\nMIKE: The thing about that is when you're introducing the vulnerability, you had to understand it well enough to break the code [inaudible 23:54] to it. And sometimes that's harder than it sounds. Like, the frame will fight you [laughs]. And it's hard to get that in there. And so, you really learn to understand the guardrails and how you can break through them. And then, from the flip side, it's fun for other people to try to figure out what it is you've broken. The teams I work with doing that learn...They universally said they learned more about security working through those exercises than they did in years of trainings because that hands-on makes a huge difference. \n\nDAVE: It makes it alive. \n\nMATT: Yeah, I mean, try adding the SQL injection to Ruby on Rails ActiveRecord. It's not easy. \n\n[laughter]\n\nMIKE: It's not. It's possible, but very difficult [laughs] [inaudible 24:45]\n\nMATT: Yeah, you have to try to make that vulnerability. \n\nDAVE: And you can tell when somebody's up against that because they'll start saying oddly specific things like, \"How do I serialize a lambda to the database?\" [laughter] Yeah, yeah, whatever you need that for, stop it.\n\n[laughter] \n\nMATT: But, you know, something that maybe I want to touch on just for a second, we were talking about the documentation and the living document. Another thing that this does is, you know, the reason we hire people is because we want to hire smart, good people who are going to provide benefit, right? Hopefully, we're hiring people who are smarter than us and better than us at our job.\n\nMIKE: Probably, yeah.\n\nMATT: So, it also provides them the opportunity to give their insight on the things we do. And they may have a different viewpoint on something like patterns or generally things we do that they may have done differently, and we've never really thought about doing in a way that they have. And it opens that conversation, and it gives us an opportunity to not only help them onboard but to improve our systems as well.\n\nMIKE: I can think of a few cases where a capable person came on, and during the onboarding, they're like, \"Well, you know, your test suite is running kind of slowly. What if you...\" and, you know, fill in the blank. And, like, \"No, that's a good idea. Why don't you try that?\" And they did. And now everything works better.\n\nDAVE: We brought somebody on a while back. And a couple of months ago, in architecture, they were like, \"Yeah, we've mostly got the database in memory now, and everything is, like, so much faster.\" I'm like, I'm really glad this guy's here. \n\n[laughter]\n\nMATT: Yeah. And they're going to feel really good about their new job, right? Like, they came on immediately adding value. That's really fulfilling, and it's going to give them a really positive outlook on the [inaudible 26:45]\n\nJUSTIN: I'm glad you mentioned that, Matt. One of the things is to give them a small task or something that they can be successful at in a small amount of time and have them do that thing such that they know the system end to end, whether it's, like, fix a small bug, or here is a small, new feature. Those types of things you could probably do. As a tech lead, you could probably do that in an hour or two. But as a new engineer in a new team, you can give this to them and say, \"Okay, here it is. Here is our process. And here's how you do everything. Work with your mentor on solving this issue. Here's something that you could be successful at. Go for it.\"\n\nMATT: Yeah. Quick wins are important, right? Going back to when I started with the company, it was...I came on, and I was told, \"Well, we're expecting you to provide lift within two weeks.\" \n\nJUSTIN: [laughs]\n\nMATT: I said, \"Okay.\" And then COVID hit. [chuckles] And I got sent to work from home with no training, and it was a little rough, you know. But something that did, for me, was make me really work to provide that lift because I had a goal. And I wanted to say, \"Hey, you guys need to see that I'm going to provide value, and I'm going to do it quickly.\" And it gave me that motivation. So, yeah, I totally agree; giving someone tasks early that they can get in and have a win that's a really big morale boost. \n\nDAVE: I worked at a shop where the development process was you shepherded your PR all the way to production, even if you were on another team, or if you were collaborating across the building. If you submitted a PR, you had to...and that meant deploying somebody else's server, which meant that everybody's deploy process had to be pretty well documented and sort of...like, if somebody else could not deploy your service, you had to stop and improve your documentation and your process, which I think was a pretty great thing. But I sat down on day one, and my mentor said, \"We need to have you deploying to production by tomorrow night.\" And I'm like, \"Oh.\" \n\nThey walk me through everything on that first day. And he's like, \"Okay.\" And he pointed me at the...we've got a board here at Acima we call the Scooby Snack board, I think, which is basically just tiny, little things that somebody new could just pick up, fix it, and ship it, right? And it was that. They had a board of, like, tiny, little tasks that somebody could do.\n\nThe difficulty had nothing to do with changing this one thing on the website. The difficulty was I got to figure out how to deploy this to production and make sure that I haven't taken anything out and make sure that it all still works. And yeah, being able to focus laser tight on I got to write this. I got to get it through review. I got to get, you know, all the things super, like, clarity. And anytime I got spun off into the weeds, I had that story of, I have to deploy. What is stopping me from getting back on track to that? And that's my next obstacle to solve. \n\nMATT: Yeah. Then you have some purpose. And I don't know about you guys, but everyone in this group today has a lot of experience and years behind us, right? But to this day...\n\nDAVE: It's kind of an old guy podcast today, isn't it? \n\n[laughter] \n\nMATT: To this day, when I start somewhere new, there's some nerves involved. No matter how experienced you are, there are some nerves involved. And I think helping people get those wins early alleviates those nerves and gives them some confidence, and then you can really see productivity out of people once they have some confidence. \n\nDAVE: How do we onboard people continuously? What can we do to onboard Matt, or Mike, or Dave on the new stuff that's coming through or the way we're doing stuff next? \n\nMATT: That's a great question. And I could have used a little bit recently [laughter]. For those listening, I have moved my role here at the company. And there are a lot of things that I'm doing now that some of that continuous onboarding really would have helped.\n\nMIKE: Let me answer that question with a question. Would we expect the process to be any different than it would be for a new hire? \n\nDAVE: I think we do because if we bring you on board to a new thing, we don't sit you down and walk you through all the setup of everything and talk you through, like, you know, \"Here's the lunchroom, here's...\" it's more like, \"There's the database; there's the cluster; there's the deploy. Let me know if you need anything.\" And, generally, if we're seeing you're...and not even senior. A lot of people that have been, you know, done this more than once or twice know what it's like to be abandoned in the middle of a desert and go, \"Okay, let's start walking.\" You know, a lot of times, we just drop you into a target-rich environment and say, \"Good luck.\" \n\nMIKE: You say a lot of times that happens. And just because somebody can doesn't mean that that's necessarily the best way [inaudible 31:37] about continuous improvement, and not that I've thought about this. I'm thinking out loud here based on the question. What if everybody had a dedicated mentor that when they want to give them a, you know if you wanted to add a question, you knew that you had that person who was there to help you and who is going to give you opportunities on a regular basis to go stretch and do something you hadn't done before. Maybe spend some time pairing with you, or maybe you have periodic times when you go, and you work out on the floor, you know, you go and actually...software. All these things we've talked about, I don't see any reason why they would not provide value ten years in. \n\nMATT: I really, really like that idea. And sorry, Mike, you got stuck with me because I just kind of use you for that all the time. \n\n[laughter]\n\nMIKE: Well, good [laughs].\n\nMATT: Yeah, you know, I was lucky enough to end up on your team. And now that I have ended up in management and you are a director, I lean on you all the time. And I greatly appreciate your support in that. But having someone that you can go to and just ask those questions and will walk you through the things that you've never done it's invaluable. \n\nDAVE: I'm kind of in scan mode. I'm like, how best to refine this? Yeah, I'm just thinking about, like, what I'm going to do on Monday, right? It's like, who do I need to be mentoring? Who do I need to mentor me on some things? Yeah. \n\nMIKE: That's exactly what you got me thinking as well. Like, what can I be doing in my role today to make that effective for the people I'm working with? Maybe I can find somebody to latch onto and say, \"Hey [chuckles]. Will you be my buddy and help me out here?\"\n\nDAVE: Yeah. And kind of related to this, sometimes it's like, okay, you decide this is what we're going to do. And then, you kind of have to trust the process a little bit, right? It's like we used to do...here at Acima, we used to do skills clinic every single day for like an hour. And it was fantastic. And the skills on the team went just through the roof, and then, you know, COVID hit. And business priorities and things got, you know, rougher, and attendance in skills clinic is way, way down. \n\nI was talking with Tad. He's running them right now. I've had lunch with him today, and I was talking with him about that, and I'm like, \"You know what? I have not been trusting the skills clinic process, and I have not been going to skills clinic. I need to start going to skills clinic just for the process of taking time to sharpen and being able to share with other people while sharpening.\" It's like, \"Oh, hey, you know, we're doing SQL right now. You can do this with a sub-query. Have you tried doing it with a window function?\" And, you know, people around the table going, \"You can do that?\" \"Let me show you something.\" Yeah.\n\nMATT: Well, and regardless of how many years of experience we have, everybody has something to offer, and everybody sees things from a little bit different perspective. So, I've learned so many things from what we have labeled as, like, juniors because they're thinking about things differently than I do, you know. I've done the same things for so many years that sometimes you get a little bit tunnel-visioned, and you don't look at things from a different viewpoint. And they really help along those lines and open up your eyes really, right? \n\nJUSTIN: Help keep your skills fresh. \n\nMATT: Yeah, absolutely. \n\nDAVE: And you can be with somebody who's very, very junior, and they are probably thinking, there's nothing I can teach this guy. But what they don't know is that you're sat there going, if I don't learn anything from you, it's because I've failed as a student. I'm going to watch you until I learn something. And, invariably, I learn something amazing when I do that. \n\nI worked with a girl who, halfway through the discussion, I found out she was a lawyer. She was a junior programmer. She had passed the bar in Colorado. And I'm like, \"Why are you in here and not practicing law?\" She's like, \"Because I hate law. I don't want to do law. I want to be a programmer.\" And I'm like, \"Okay.\" And sure enough, that afternoon, we're typing along, and something came by. It was like TCPA or something like that, and I'm like, \"A or B?\" And she was like, \"It's B. It's B. A is against the law. Do B.\"\n\n[laughter]\n\nDAVE: I'm like, \"Oh, okay.\" \n\n[laughter]\n\nMATT: Yeah. We had a contractor who was also practicing, the attorney, in a different country. But...\n\nDAVE: Yeah, somebody who shows up with that, you know, they can think.\n\nMATT: Yep. Again, everybody has something to offer, and we all have something to learn. \n\nJUSTIN: So, I got a couple of really quick, rapid-fire questions. One that I've noticed was really good was as a, you know, a person leader, the manager is, like, having regular check-ins with your new employee, like, at the start, especially. Those would probably be, you know, weekly, that sort of thing at least. And then, of course, like, a big lunch meeting to introduce everybody at a restaurant, or something like that, celebrate the onboarding, but also, you know, weekly check-ins. And then, what are you guys' thoughts on a 30, 60, 90-day plan, like creating one for your new employees? Is that something that works for engineers, or is that something that is mainly something that exists outside the engineering world? \n\nDAVE: I've only ever seen it done once, and when it was done, it was every bit as awkward as we all thought it would be. And it was profoundly effective, and I have missed it ever since. \n\n[laughter]\n\nJUSTIN: Wow. That did not go in the direction I thought it would go. I was like, [vocalization]. \n\nDAVE: Yap. It was with the first time I ever saw a manager who felt that being a manager was a full-time job and required him to study and learn management. And so, he was literally learning things like, when you have your one-on-one meeting, you have to quickly triage the meeting into, are they looking for training? Are they looking to just check in? Or are they melting down, and they need to vent? Because you have to handle those very, very differently. And if you try to go and fix and train when they're venting, it's going to go horribly. I'm like, I never had thought about that. And this particular person would come and say, \"Hey, we need to go do our one-on-one.\"\n\nAnd it was just...I'm like, this is awkward. This is dorky. \"Okay, Carl, fine.\" And they'd get up...and we'd go to lunch, and it would start awkward. And then, five minutes in, we're just chatting, shooting the breeze. And we're talking architecture and where does the team go. And I grew a lot. And this was 10-12 years ago. It was kind of middle of my career. And my skills leapfrogged every single month. \n\nThat was the first place where I put on, as my personal goals, to lose weight or to be able to run a mile under a certain time. And Carl was very, very proud of me when I put that on because he basically...I said, \"If I do good cardio, I'm going to think more clearly, and I'm going to be more effective as a programmer.\" And he's like, \"I think that's a fantastic goal. Put it down. Let me know what your time is in 30 days.\" \n\nMATT: Interesting. I like that.\n\nMIKE: I think we have rightly done so, talked about things that work well. One final question I want to ask is, is there anything that poisons the process? Is there anything that makes it just work terribly? To maybe illustrate the opposite, right? You know, as to what you can do well. \n\nMATT: Yes, not following through. That's key, right? As people get busy, people get sidetracked, things like that, I think it's extremely important to follow through on the things that you promise to deliver, and not only is that relevant for onboarding. I think it's relevant just in business, in life, et cetera. But, you know, let's say I'm onboarding someone, and I say, \"Okay, next week, I'm going to spend two days with you going through x,\" and I get sidetracked. I don't follow through. That's a really big failure on my part and, letting them down and not giving them the room to succeed. So, I -- \n\nDAVE: And it's critical. It's critical at that time, too, right?\n\nMATT: Yeah.\n\nDAVE: Because that one failure is 100% of their interactions with you to date and that set the direction that they're going to expect everything from them. You could never miss again, and they'll always wonder, is this the time that he's not going to follow through? \n\nMATT: Yep. You paint that picture. \n\nJUSTIN: One thing I've seen is when they've chosen the wrong person to be the onboarding buddy. And if they choose someone who is bitter about their current position or is not optimistic, it kind of can make that new person follow that persuasion, which is probably not what you want. So, -- \n\nDAVE: It's important to distinguish between bitterness and pessimistic, I think, maybe. Because I've worked with a programmer who just he was very much, like, leave me alone, don't, you know, da da da da. And the onboarding was basically...Our boss, I remember on day one, the very first thing she said was, \"That's Terrence's office. Stay off his radar. He likes to fire new guys.\" I'm like, \"Whoa, okay!\" \n\nJUSTIN: [laughs]\n\nDAVE: And it was a government contractor. You could play that kind of politics and kind of stuff. And that was really, really good advice. And I didn't follow it, and exactly what she told me would happen to me happened to me at the next layoff [laughter]. It didn't make me bitter. It didn't affect my attitude. It wasn't office politics. It was office sociology. It was just, you know, be aware. That's a live wire. If you plug it into the power system, it'll run the whole city, but if you lick it, it's going to ruin your day. And so...\n\nJUSTIN: [laughs]\n\nDAVE: And she wasn't bitter. She loved the company. She loved her job. But she was very, very realistic about, like, that's awesome, and that's garbage and, you know -- \n\nMATT: Pragmatist. \n\nDAVE: Pragmatic. Pragmatism. Yeah, that's exactly it. If it works, it's true. That's pragmatism. If it works, it's true. \n\n[laughter]\n\nMATT: But yeah, we definitely want to avoid people poisoning the well, right? Because it does, it carries over, and it kind of just...it spreads as well. \n\nMIKE: We've talked before about psychological safety. You're bringing somebody in. It's not just code. And this is a critical thing. Software engineering, even somebody who's just starting and they're going to be writing a lot of code, they likely will not spend most of their day writing code, at least not every day. Software engineering is a lot of things that aren't code. It is a group endeavor. And you cannot build large projects effectively in isolation. It doesn't work that way. So, you're not just getting somebody to understand a codebase. You're helping somebody understand and build a culture. And you can't forget that it's more than one thing you're building. \n\nDAVE: And I think I've mentioned this before: my favorite epiphany that I took away from skills clinic is that we think of development as a process where the developer is in the box, and we take a problem, and we put a problem in the box, and the solution comes out of the box. And that's not a programming career at all. The box is where the effort takes place, and we take a programmer at a problem and we put them in the box. And what you get out is a solution and a smarter programmer. \n\nAnd if you focus on investing in that programmer, they're going to grow, and they're going to get smarter. And if you focus only on just product, product, product, product, product, some people will thrive, and some people they just miss...and it's just bad luck. It's not that they're not, you know, good or hardworking. It's that they got so focused on optimizing the process that they end up...it's like not stopping to sharpen the saw, right? You get so busy creating the output that you never increase your ability to create output. \n\nMATT: I wanted to make a Beyond Thunderdome reference there, Dave. Two men enter, one man leaves. \n\n[laughter]\n\nDAVE: Right. That's right. Two problems enter, one solution leaves. I like it. I like it. \n\nMIKE: To come back to a story, several years ago, I was riding bikes with my kids. And my oldest son was pulling somebody [laughs], one of my other kids. And he was back behind. And he was really having a hard time keeping up, which is unusual for him because of who he is [laughs]; I'll say that. He usually does not have a hard time keeping up. I usually have a hard time keeping up with him. \n\nSo [laughs], he was just dragging, and he said, \"Man, maybe I'm tired today.\" But he was just trying to muscle through it, and muscle through it, and muscle through it, and muscle through it.\" Finally, he said, \"Can we take a break?\" And he looked, and the bike he was pulling, you know, the trailer he was pulling, the tire was completely flat. So, he'd been, like, dragging a plow [laughs] through and was riding [inaudible 44:31] for miles [laughs]. \n\nDAVE: Just pulling [inaudible 44:33] the whole time. \n\nMIKE: Yeah. If you don't take that time to look and make sure your tools are in good order and keep things going, you maybe can muscle through it for a while, but it's not going to work the long term. \n\nDAVE: Tying it back to earlier, that's all about the hunting badgers, right? It's like the great thing that can come out of that is not, oh, I needed to fix the tire. The takeaway is sometimes I should stop and check my equipment. And that's the [laughter] aha moment of it. And that's the difference between having a good job and making a whole career, right? It's like that. You'll come back to that. \n\nMATT: Instead of fixing the flat, prevent the flat.\n\nDAVE: Or just be aware that --\n\nMIKE: Be aware.\n\nDAVE: You know, check your equipment, yeah. \n\nMIKE: Sometimes flats happen [laughs], and you got to be aware of that. \n\nJUSTIN: I think from a security point, the guy that thwarted the recent attack that was going to be on one of the base systems in Linux was checking his equipment because, all of a sudden, part of it was, like, going slower, and it was just a fraction of a second slower or something like that. But he went in and, like, discovered the bad code because he was checking his equipment. \n\nDAVE: I've never believed so strongly in the a billion eyes makes all bugs shallow [laughter] from Linus Torvalds from the '90s. I'm like, okay, I believe you now, Linus, so... \n\nJUSTIN: [laughs]\n\nMIKE: Any other final words? \n\nDAVE: Be good to each other. Do code reviews. \n\nMATT: Yeah, right. [laughter] Our interactions are always a pleasure. \n\nJUSTIN: Gentlemen, it has been a pleasure. Yeah, thank you. \n\nMATT: Yes. ","content_html":"The panel delves into the challenges and strategies of onboarding new employees to discuss the importance of communication, mentorship, and understanding context. Mike shares a story from his construction days in New Orleans, where he learned the value of being paired with an experienced team member. This buddy system helped him overcome communication barriers and adapt more quickly to his new environment.
\n\nEffective onboarding involves more than just providing documentation. While documentation is valuable, it must be up-to-date and supplemented with hands-on guidance and practical experience. The panel advocates for giving new employees context about their tasks and the organization. This can include having them use the software as end-users or working directly with customers to understand the system and its impact better. Regular check-ins and skills clinics are also recommended to help employees stay updated and improve their skills.
\n\nAdditionally, the podcast highlights the importance of continuous learning and mentorship for all employees, not just new hires. Regular mentor-mentee interactions and collaborative updates to documentation ensure that onboarding remains practical and relevant. The panelists also note the pitfalls to avoid, such as not following through on commitments and assigning unsuitable onboarding buddies.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today [laughs]. With me right now, we've got Justin, Dave, and Matt. We're going to talk about onboarding new employees. It's a tricky problem. I don't know that anybody has it perfect, and I don't think we have it perfect. So, we're going to talk about some ideas, some things that we've seen go well and maybe not so well. I've been remembering onboarding in days past.
\n\nI tell a story about the late '90s. I was living in New Orleans doing construction work. We would go in and remodel office space. So, sometimes, we'd tear out everything and then rebuild it. You know, we had teams all over. The company I was working for had teams all over the city doing this. And the team I started on, I started just as a laborer. I was not doing anything fancy to begin with.
\n\nBut what I remember is a couple of things. The day I started, the foreman I was working with set me up with a partner. His name was also Mike [laughs], and they called him Big Mike. And they sometimes would compare him to George Foreman because they looked similar. He was a big guy. He previously worked out on the oil rigs out in the Gulf of Mexico and a big, strong guy. And we got to be fast friends pretty quickly.
\n\nHowever, the day I started, I had not been living in Louisiana for all that long, and he grew up way out in the Bayou somewhere. And when he started talking to me, I picked up about one word out of three of what he was saying [laughs], maybe. And it was that way for a few days. You know, maybe started out with one word out of three. After a while, I got to two out of three. There's a mix of accents there. If you've got a Southern accent and a heavy French accent...
\n\nDAVE: Mm-hmm. The Creole.
\n\nMIKE: Plus, there's some African-influenced accent as well, and you mix those all together. And I'm a White guy from farther North [laughs]; I did not pick up very quickly. But we got to be friends. And he was patient [laughs]. He was patient with me. And, actually, after a few months, we'd hung out outside of work. We were actually quite close friends. We've lost touch over the years, but I'd love to get back in touch with him. After the storms they had down there, that drove out a lot of the population. He's probably moved, and I don't know where he's gone.
\n\n[laughter]
\n\nBut there are things about this story that were relevant. First of all, the foreman did a great thing. When he brought me in, he paired me with somebody so that I didn't have to know everything. I just had to be able to ask Mike, and [laughs] we could get some stuff done. The second thing is communication is hard [laughs]. We were speaking the same language, and we still couldn't understand each other. He could probably understand me. I was the one who was struggling [laughs].
\n\nBut, you know, it took us a while to get things right, and we had to work on it. It had to be an active, active effort, especially on my part, to learn to understand. And working on it worked, though. You know, over time, we got to work really well together. We were frequently called on to get a lot of stuff done because we had more effective partnerships [laughs]. We both had enough carpentry skills that we could get a lot done besides just being laborers.
\n\nI lay this out, and it's outside of software engineering. I think a lot of times, it helps to think about something outside of software engineering to lay some context. We bring people in, and we let them loose. And you've got to figure stuff out. You may be talking with somebody [laughs] who has a different background, and he's going to use the same words and mean different things, and you're in an unfamiliar project. There's a lot that has to happen for you to onboard successfully.
\n\nAnd there's a few things that I think make a huge difference to be successful and one of them is that regular communication with somebody. And another is, you know, well, getting that communication, but having a buddy, right? Having that lifeline, I think, are some of the key aspects I've seen be effective in onboarding. I think there's a lot else as well, but there's my story to launch this off. And what do you all think?
\n\nMATT: Well, you hit on communication, and while I think, you know, trying to dissect a Creole Cajun dialect is tough, [laughter] there's also communication differences in the same language and dialect. For instance, the four of us all have very different communication styles, and I think being able to pick up on that and how people communicate, and their intent is a very important aspect of that.
\n\nJUSTIN: I like how they assigned somebody to you who was already part of the thing. They had, you know, knowledge that they've built up as kind of a veteran working there. And they were able to answer your questions, and you were able to be much more effective because you had somebody to ask questions to, and they had to answer right away. You weren't, like, left alone. "Go do your thing [laughs]."
\n\nYeah, I've had experiences with both. And a lot of how you communicate culture to a new team member is, you know, whoever is introducing you, and whoever your onboarding buddy is, whoever you have the most exposure to, that is how they view the whole company almost. And if you don't have somebody, you know, doing that correctly, you don't have a good communication in not just, you know, knowledge, but also culture, and friendships, and there's a whole bunch of stuff there.
\n\nDAVE: But, for me, it's, like, context. There's so much out-of-band stuff you can pick up by, like, a personal interaction, where I was talking with Adam a while back, and I'm like, "I want to pair with you on this problem." And he had been thinking through this problem. And he's like, "Well, I know it's not the login. I know it's not this. I know it's not this conditioning thing. I know it's not this sequence in the system." And I'm like, "Adam, I need you to take me with you to hunt badgers." And he's like, "What do you mean?" And I said, "I don't need you to show me how to shoot the badger once you've found it. I need you to take me through the hills and show me every place you check for badgers. That's what I need."
\n\nBecause he was thinking, I don't want to show you the login system because that's not going to be the problem, and I don't want to show you the pipeline because that's not...I'm like, no, show me that you checked the login, right? Like, literally, the gift in the box was not what I wanted. I wanted the box, and the wrapper, and [laughter]...right? And all the trappings that went with it.
\n\nMIKE: That's interesting. You wanted the box.
\n\nDAVE: Mm-hmm.
\n\nMIKE: Again, this is a little bit outside of engineering, but it's related to that. You know, you think about math class. You can memorize the rules for solving a problem. And as soon as you forget any one of those or you make one little mistake, you're just completely lost. But if you can have somebody who takes the time to help you understand why you're doing what you're doing...and it takes a lot longer. It absolutely takes a lot longer, and in a classroom setting, that's hard. You know, it's a gifted teacher who can bring everybody to that level, and that's, you know, a difficult thing to do.
\n\nBut if you can do it, if you can help somebody get deep mastery of why those things are there, you know, teach the intuition and understanding, if somebody gets lost, they can backtrack. You know, you can figure out what you're doing or even come up with your own way of doing things and be creative about it. It completely changes your perception of that problem-solving. We're in a problem-solving industry. That same idea is directly applicable. If you could show somebody this is what you do and, you know, tell them to just do that, it's not very useful at all.
\n\nMATT: The journey is just as important as the destination.
\n\nJUSTIN: I think, to kind of summarize, if we were to put, like, points on a board about, you know, how do we onboard someone, so, right at the start is, like, choose an onboarding buddy who's going to be very helpful for this person in whatever. And I think that's part of leadership's responsibility, you know, whoever is in charge of onboarding this person, whether it's the tech lead, or the director, or whoever the team lead. So, they need to make that decision of who's going to be this person's onboarding buddy. And then recognize that that's going to take time, and that's real work. And you can't, like, you know, expect them to do the same level of work as they did before, perhaps, because they are, you know, if they're going to do it right, it's going to take time.
\n\nMATT: And based on the information we have about these new hires, who is going to be the best fit, not only in experience, but personality type, communication type, those things?
\n\nMIKE: That investment can go a long way. If you do your onboarding poorly, then you're going to have somebody who doesn't know what they're doing. And somebody can sit around for months and get very little done. They'd be busy, busy all of that time, and not get very much done because they don't know what they're doing.
\n\nDAVE: I can't tell if I feel seen or attacked there, Mike.
\n\n[laughter]
\n\nMATT: But that's important, right? Encouraging people to ask questions and not just sit and spin their gears, ensuring that they understand the things you're going through and leading them. You know, I could sit and write code for hours and have someone paired with me. But if I'm not ensuring that they're understanding what I'm doing, communicating my thought process of why I'm doing it, I don't feel like I'm really helping them. And they're probably not learning a whole lot during that time, right?
\n\nMIKE: One thing about our brains is they don't tend to stay connected to something they're not actively engaged with. You show me somebody who can watch somebody do a detailed technical task for a long period of time, and [chuckles] I'll show you something imaginary [laughter]. It's not the way our brains work.
\n\nDAVE: There's a really great experiment that demonstrates this, which is that if you just start reciting numbers at somebody and say, "Memorize this. You don't get to write it down. Just memorize it," we tend to be able to hold about seven numbers. Like, some people are down to five. Some people, as many as nine...can hold this in their working memory. And what we miss is that if you can tie these things together with a story...the people that memorize Pi out to, like, a million places, they have a story that ties all the numbers together, and where you are in the numbers, where you are in the story, and, to them, it's just one story.
\n\nAnd that is the essence of, like, "Oh yeah, you know, sign into this. The database is over here. The server is over there." And I'm like, okay, that's three things that aren't connected [laughs], right? And there's 23 more to go. You better start making a story out of this for me [laughs].
\n\nMIKE: You know, that says something, right? Without that story. And it also says something about communication. You know, a lot of the best communicators will dip into stories that don't directly connect to the material they're talking about. But then they'll make the connection like, oh, that's great. That was entertaining. And it's entertaining, sure, but it's a lot more than that. Without that story, you would never have learned the idea in the first place.
\n\nIt may superficially look like they're just trying to make things fun, but that's really not what...making things fun is not what really good communicators do. What really good communicators do is connect you with the material they're talking with. That could be fun, and it's going to be engaging, but the goal is different. They're not trying to force something to be entertaining. Let's make math fun. No, they actually see the fun in it. They see the story, and they want to share it.
\n\nDAVE: I had a co-worker...oh gosh, this was around Y2K. This was a while back. And we were struggling with the inheritance rules. I had some co-workers that didn't understand, like, protected versus private versus public versus, you know, friend was the thing. I blurted out the rules of C++ inheritance in terms of intimate encounters, right? Your children cannot touch your privates. Your friends can touch your privates, right?
\n\nI got sent to HR, which is fine; I deserved it. But a week later, I'm typing away at two cubicles over. I hear, "Damn it, Dave!" [laughter] And I'm like, "What?" He's like, "I know the difference between protected and private, you jerk!" and just kept typing. And I'm like, yep, that's in your brain rent-free for the rest of your life [laughs]. I've gotten better at little, you know, more tasteful stories since then. You're all going to remember it now, too.
\n\n[laughter]
\n\nMIKE: So, reinforcing the point about stories, having to have that connection and the importance of context, the importance of context.
\n\nJUSTIN: Related to that story there and onboarding new people, the best places I've seen that do onboarding is where you come in, and you're actually onboarded as a user of whatever system that you are going to be doing, and so you know how the users are using it. And you can see, you know, oh, okay, here I'm a customer service rep, and here's me logging in, and here's me helping a customer, looking up the customer name. And then, here's me looking up their lease number, and their payments, and their history, and things like that. And I can, you know, see there. And here's the customer service rep complaining about something.
\n\nAnd so, you go in, and you spend a day or two just immersing yourself in that system. And then, you come back, and you have a story in your head of how this thing actually works from a front end, and then you can dive into, oh, okay, this is how the app works. And this is what is actually happening, and this is where the data is being stored. And I understand what's going on here. And here's this third party that we're calling, and things like that. So, that right there is key, for me, to understanding, you know, see how our users are using it, and then I can see behind the scenes.
\n\nDAVE: There's a fundamental problem in computer science, and I call it the A versus B problem, which is where this system over here, you got A matching up against A, and it works. System B matches up against B, and it works. And you get a bug that comes in. Your trouble ticket is, I did this. I expected A, but I got B. And you're like, okay, should you be getting A, or should you be expecting to get B? Which is the right answer, right? It's like, oh, plus four on the zip code. This piece over here only has room for five digits in the printing label. Don't ever put a plus-four on there. That's a bug, right? Anybody else working with postal codes is going to be like, no, you always want the plus four. Why would you want to throw away data?
\n\nOne of these is right. But if they don't match, you have to know which one of the two is correct, and it's the context. Seeing a user use it is what, you know, it's like, if this is checked or unchecked, if it's checked, we always do the thing. And if it's unchecked, does that mean we can do the thing, or does it mean that we never do the thing, right? There's that context to it.
\n\nMIKE: You know, you talked about sitting in the place of customer service and using the software. I'd take that even further. Some of the most successful onboarding I've seen is when the new person is actively assigned to work with a user of the software. It's not always possible. It depends on the context. But you can have them sit with customer support and help them field calls for a couple of days, or, you know, go out in the field and use the software with the users. You know, actually using that software with real users provides a depth of understanding that I think is almost impossible to get otherwise.
\n\nDAVE: I can think of a time when I have been sent to work with the end users that...In 2006, I worked on a system for a year, and I finally got to go sit with the users. And this has happened every time I've sat with users. And I was surprised after a year that this still happened to me. I walked back into the bullpen with my co-workers the next day, and I said, "Guys, we're building the wrong thing." Just half a day with the people using it, and you realize we are going around welding shut every door that you need to access. The way that we're trying to get you in and out of the system is like crawling up and down the chimney. We have built this completely wrong. We need to put a lock on this door and make it swing easily instead of messing up your life, yeah.
\n\nMIKE: So, we've talked about a few things: having a buddy [laughs], taking the time to get context, assigning somebody to actually use the software, and, if possible, pairing them with real users. Saying that all of those are important for onboarding. How valuable do y'all think documentation is?
\n\nJUSTIN: I wouldn't want to dive into documentation to start off with. I'd want to go to those other things first. Because documentation is great. I love documentation, but without the context, I don't know if that documentation is dated. I don't know if it's, you know, even applicable for the system I'm on. And so, without that context or without asking my buddy, it's almost worse than having no documentation [laughs]. You could be looking, like I said, at outdated stuff, or you could be doing stuff like that.
\n\nBut later on, when I'm more experienced in the system, I love documentation because I have the context there, and I'm just looking for details, or maybe some other stuff when I already, you know, have a good, solid base of everything. So, yes, documentation, but I don't want to push a bunch of documentation at somebody who just started yesterday and say, "Read all this [laughs]," so...
\n\nDAVE: If it's a part of the system that is very static, very stable, and we've been using it for five years, then yeah, hand you a piece of documentation that says, "Start here. When you're done, you will have this. Here's the steps." And that's kind of fun sometimes where you hand that to them and say, "We're trying to improve this documentation. Please go through this. And as soon as you get stuck or lost, come find me, and we'll fix the documentation." That's a lot of fun.
\n\nAnd, again, there's a trick to that, which is now they're engaged looking for the problems in the documentation. And now they're paying attention to the system. Instead of "Memorize these seven things and plug them in," it's like, "Okay, I'm in step three. I don't have access to Postgres. What should I do?" right? "Oh, let me add that step."
\n\nMIKE: You know, I think we all wished we had perfect documentation. But documentation is a lot of work, both to create initially and to keep up to date. And I'm not complaining about documentation. You know, any documentation is almost necessarily out of date unless you keep it in lockstep with your changes. Unless any changes to documentation go out exactly with any changes to your software, it's going to be out of date kind of the moment it's written.
\n\nSo, it feels like there has to be another layer, either you put a huge amount of effort into your documentation, which I think is unpalatable for a lot of organizations because the work is hard; it's expensive, or you have some system outside of the documentation to communicate some of that knowledge. And that's hard. That's a tricky balancing act. Because there's probably things in the documentation that somebody is going to forget to tell you.
\n\nSo, to ask another question, I asked about documentation: how do you avoid those gaps? And we've talked about the value of partnering with somebody. What happens if you never happen to walk by that hole in the ground? You say, "Don't step in that." [laughter] How do you avoid that? What are some things you can do to avoid some of those gaps in knowledge?
\n\nJUSTIN: Document. Oh, wait [laughter]. Find it out and document it. I like what you said, though, when you have your mentor there, and you have your new onboarding checklist, you know, to get permissions for all the things and to get all your environment set up. If you're both doing it together and then you update anything that's missing or, you know, common missteps on that onboarding document or series of onboarding documents, usually, that's really helpful, and it kind of updates itself as you onboard new people. And that way, you aren't dealing with an onboarding document that was last updated in 2021.
\n\nSo, I don't know if that answers your question exactly, but that, you know, goes back to having your mentor and you going through it together and updating anything that you find is missing.
\n\nMATT: And things change, right? Something that was relevant even as recent as, let's use our company for an example, five months ago isn't relevant today, right? Because we're doing a lot of things differently. So, if we can make these things a living document and adjust as we go, and maybe we find a better way to do something that we have documented or a different way that's more efficient, then we can update it and keep that document living. And it provides a lot of value for the next person coming through the line.
\n\nMIKE: So, we've got another item in our checklist here [laughs]. Have the new person work with their mentor to update the documentation as they go so that it does become that living document as they're using it. One thing...I still think that sometimes you miss those things, the things that you didn't think to document that everybody just knows. One thing that I've seen among people who've been really successful, a lot of times, they'll say, "The time I learned the most was when I didn't have anybody else to help me, and I had to do it on my own."
\n\nAnd [chuckles] maybe they're at a job where they're the only engineer, or they took over DevOps. You know, whatever the case may be, a lot of times it's when [chuckles] somebody had to take care of things themselves, and there's nobody else to go to. You have to figure it out. And, boy, that burns [inaudible 22:22] your brain.
\n\nMATT: Trial by fire.
\n\nMIKE: But, you know, we don't want to lay everybody off once a month just to give somebody a chance to do that. That's not a good way [laughs] to run a company. So, we're not going to do that. So, I think that setting up some sort of environment that gives people an opportunity to learn and more of a sandbox is really useful. One thing I've seen for security training that was extremely helpful is we rotated weeks. And every week, somebody would add an insecurity to the application from the OWASP Top 10. And then, the rest of the team, knowing that there was that kind of vulnerability in the app, would look for it and try to exploit it.
\n\nJUSTIN: In production?
\n\nMIKE: No.
\n\nMATT: No.
\n\n[laughter]
\n\nJUSTIN: Okay.
\n\nMATT: No.
\n\n[laughter]
\n\nMIKE: We built a...We built a...
\n\nDAVE: So, they're playing. They're just not playing for keeps.
\n\nJUSTIN: Yeah. I was like --
\n\nMATT: I believe, Justin, this goes back to when you first came aboard. I remember I was doing the OWASP Top 10. Prior to that, the trainings were an application that Mike actually had hosted on his AWS instance called Insecurity. And then, we moved over to the Juice Shop when I took over. But prior to the Juice Shop, it was this Insecurity app that we did exercises on.
\n\nJUSTIN: Oh, that's really cool.
\n\nMIKE: The thing about that is when you're introducing the vulnerability, you had to understand it well enough to break the code [inaudible 23:54] to it. And sometimes that's harder than it sounds. Like, the frame will fight you [laughs]. And it's hard to get that in there. And so, you really learn to understand the guardrails and how you can break through them. And then, from the flip side, it's fun for other people to try to figure out what it is you've broken. The teams I work with doing that learn...They universally said they learned more about security working through those exercises than they did in years of trainings because that hands-on makes a huge difference.
\n\nDAVE: It makes it alive.
\n\nMATT: Yeah, I mean, try adding the SQL injection to Ruby on Rails ActiveRecord. It's not easy.
\n\n[laughter]
\n\nMIKE: It's not. It's possible, but very difficult [laughs] [inaudible 24:45]
\n\nMATT: Yeah, you have to try to make that vulnerability.
\n\nDAVE: And you can tell when somebody's up against that because they'll start saying oddly specific things like, "How do I serialize a lambda to the database?" [laughter] Yeah, yeah, whatever you need that for, stop it.
\n\n[laughter]
\n\nMATT: But, you know, something that maybe I want to touch on just for a second, we were talking about the documentation and the living document. Another thing that this does is, you know, the reason we hire people is because we want to hire smart, good people who are going to provide benefit, right? Hopefully, we're hiring people who are smarter than us and better than us at our job.
\n\nMIKE: Probably, yeah.
\n\nMATT: So, it also provides them the opportunity to give their insight on the things we do. And they may have a different viewpoint on something like patterns or generally things we do that they may have done differently, and we've never really thought about doing in a way that they have. And it opens that conversation, and it gives us an opportunity to not only help them onboard but to improve our systems as well.
\n\nMIKE: I can think of a few cases where a capable person came on, and during the onboarding, they're like, "Well, you know, your test suite is running kind of slowly. What if you..." and, you know, fill in the blank. And, like, "No, that's a good idea. Why don't you try that?" And they did. And now everything works better.
\n\nDAVE: We brought somebody on a while back. And a couple of months ago, in architecture, they were like, "Yeah, we've mostly got the database in memory now, and everything is, like, so much faster." I'm like, I'm really glad this guy's here.
\n\n[laughter]
\n\nMATT: Yeah. And they're going to feel really good about their new job, right? Like, they came on immediately adding value. That's really fulfilling, and it's going to give them a really positive outlook on the [inaudible 26:45]
\n\nJUSTIN: I'm glad you mentioned that, Matt. One of the things is to give them a small task or something that they can be successful at in a small amount of time and have them do that thing such that they know the system end to end, whether it's, like, fix a small bug, or here is a small, new feature. Those types of things you could probably do. As a tech lead, you could probably do that in an hour or two. But as a new engineer in a new team, you can give this to them and say, "Okay, here it is. Here is our process. And here's how you do everything. Work with your mentor on solving this issue. Here's something that you could be successful at. Go for it."
\n\nMATT: Yeah. Quick wins are important, right? Going back to when I started with the company, it was...I came on, and I was told, "Well, we're expecting you to provide lift within two weeks."
\n\nJUSTIN: [laughs]
\n\nMATT: I said, "Okay." And then COVID hit. [chuckles] And I got sent to work from home with no training, and it was a little rough, you know. But something that did, for me, was make me really work to provide that lift because I had a goal. And I wanted to say, "Hey, you guys need to see that I'm going to provide value, and I'm going to do it quickly." And it gave me that motivation. So, yeah, I totally agree; giving someone tasks early that they can get in and have a win that's a really big morale boost.
\n\nDAVE: I worked at a shop where the development process was you shepherded your PR all the way to production, even if you were on another team, or if you were collaborating across the building. If you submitted a PR, you had to...and that meant deploying somebody else's server, which meant that everybody's deploy process had to be pretty well documented and sort of...like, if somebody else could not deploy your service, you had to stop and improve your documentation and your process, which I think was a pretty great thing. But I sat down on day one, and my mentor said, "We need to have you deploying to production by tomorrow night." And I'm like, "Oh."
\n\nThey walk me through everything on that first day. And he's like, "Okay." And he pointed me at the...we've got a board here at Acima we call the Scooby Snack board, I think, which is basically just tiny, little things that somebody new could just pick up, fix it, and ship it, right? And it was that. They had a board of, like, tiny, little tasks that somebody could do.
\n\nThe difficulty had nothing to do with changing this one thing on the website. The difficulty was I got to figure out how to deploy this to production and make sure that I haven't taken anything out and make sure that it all still works. And yeah, being able to focus laser tight on I got to write this. I got to get it through review. I got to get, you know, all the things super, like, clarity. And anytime I got spun off into the weeds, I had that story of, I have to deploy. What is stopping me from getting back on track to that? And that's my next obstacle to solve.
\n\nMATT: Yeah. Then you have some purpose. And I don't know about you guys, but everyone in this group today has a lot of experience and years behind us, right? But to this day...
\n\nDAVE: It's kind of an old guy podcast today, isn't it?
\n\n[laughter]
\n\nMATT: To this day, when I start somewhere new, there's some nerves involved. No matter how experienced you are, there are some nerves involved. And I think helping people get those wins early alleviates those nerves and gives them some confidence, and then you can really see productivity out of people once they have some confidence.
\n\nDAVE: How do we onboard people continuously? What can we do to onboard Matt, or Mike, or Dave on the new stuff that's coming through or the way we're doing stuff next?
\n\nMATT: That's a great question. And I could have used a little bit recently [laughter]. For those listening, I have moved my role here at the company. And there are a lot of things that I'm doing now that some of that continuous onboarding really would have helped.
\n\nMIKE: Let me answer that question with a question. Would we expect the process to be any different than it would be for a new hire?
\n\nDAVE: I think we do because if we bring you on board to a new thing, we don't sit you down and walk you through all the setup of everything and talk you through, like, you know, "Here's the lunchroom, here's..." it's more like, "There's the database; there's the cluster; there's the deploy. Let me know if you need anything." And, generally, if we're seeing you're...and not even senior. A lot of people that have been, you know, done this more than once or twice know what it's like to be abandoned in the middle of a desert and go, "Okay, let's start walking." You know, a lot of times, we just drop you into a target-rich environment and say, "Good luck."
\n\nMIKE: You say a lot of times that happens. And just because somebody can doesn't mean that that's necessarily the best way [inaudible 31:37] about continuous improvement, and not that I've thought about this. I'm thinking out loud here based on the question. What if everybody had a dedicated mentor that when they want to give them a, you know if you wanted to add a question, you knew that you had that person who was there to help you and who is going to give you opportunities on a regular basis to go stretch and do something you hadn't done before. Maybe spend some time pairing with you, or maybe you have periodic times when you go, and you work out on the floor, you know, you go and actually...software. All these things we've talked about, I don't see any reason why they would not provide value ten years in.
\n\nMATT: I really, really like that idea. And sorry, Mike, you got stuck with me because I just kind of use you for that all the time.
\n\n[laughter]
\n\nMIKE: Well, good [laughs].
\n\nMATT: Yeah, you know, I was lucky enough to end up on your team. And now that I have ended up in management and you are a director, I lean on you all the time. And I greatly appreciate your support in that. But having someone that you can go to and just ask those questions and will walk you through the things that you've never done it's invaluable.
\n\nDAVE: I'm kind of in scan mode. I'm like, how best to refine this? Yeah, I'm just thinking about, like, what I'm going to do on Monday, right? It's like, who do I need to be mentoring? Who do I need to mentor me on some things? Yeah.
\n\nMIKE: That's exactly what you got me thinking as well. Like, what can I be doing in my role today to make that effective for the people I'm working with? Maybe I can find somebody to latch onto and say, "Hey [chuckles]. Will you be my buddy and help me out here?"
\n\nDAVE: Yeah. And kind of related to this, sometimes it's like, okay, you decide this is what we're going to do. And then, you kind of have to trust the process a little bit, right? It's like we used to do...here at Acima, we used to do skills clinic every single day for like an hour. And it was fantastic. And the skills on the team went just through the roof, and then, you know, COVID hit. And business priorities and things got, you know, rougher, and attendance in skills clinic is way, way down.
\n\nI was talking with Tad. He's running them right now. I've had lunch with him today, and I was talking with him about that, and I'm like, "You know what? I have not been trusting the skills clinic process, and I have not been going to skills clinic. I need to start going to skills clinic just for the process of taking time to sharpen and being able to share with other people while sharpening." It's like, "Oh, hey, you know, we're doing SQL right now. You can do this with a sub-query. Have you tried doing it with a window function?" And, you know, people around the table going, "You can do that?" "Let me show you something." Yeah.
\n\nMATT: Well, and regardless of how many years of experience we have, everybody has something to offer, and everybody sees things from a little bit different perspective. So, I've learned so many things from what we have labeled as, like, juniors because they're thinking about things differently than I do, you know. I've done the same things for so many years that sometimes you get a little bit tunnel-visioned, and you don't look at things from a different viewpoint. And they really help along those lines and open up your eyes really, right?
\n\nJUSTIN: Help keep your skills fresh.
\n\nMATT: Yeah, absolutely.
\n\nDAVE: And you can be with somebody who's very, very junior, and they are probably thinking, there's nothing I can teach this guy. But what they don't know is that you're sat there going, if I don't learn anything from you, it's because I've failed as a student. I'm going to watch you until I learn something. And, invariably, I learn something amazing when I do that.
\n\nI worked with a girl who, halfway through the discussion, I found out she was a lawyer. She was a junior programmer. She had passed the bar in Colorado. And I'm like, "Why are you in here and not practicing law?" She's like, "Because I hate law. I don't want to do law. I want to be a programmer." And I'm like, "Okay." And sure enough, that afternoon, we're typing along, and something came by. It was like TCPA or something like that, and I'm like, "A or B?" And she was like, "It's B. It's B. A is against the law. Do B."
\n\n[laughter]
\n\nDAVE: I'm like, "Oh, okay."
\n\n[laughter]
\n\nMATT: Yeah. We had a contractor who was also practicing, the attorney, in a different country. But...
\n\nDAVE: Yeah, somebody who shows up with that, you know, they can think.
\n\nMATT: Yep. Again, everybody has something to offer, and we all have something to learn.
\n\nJUSTIN: So, I got a couple of really quick, rapid-fire questions. One that I've noticed was really good was as a, you know, a person leader, the manager is, like, having regular check-ins with your new employee, like, at the start, especially. Those would probably be, you know, weekly, that sort of thing at least. And then, of course, like, a big lunch meeting to introduce everybody at a restaurant, or something like that, celebrate the onboarding, but also, you know, weekly check-ins. And then, what are you guys' thoughts on a 30, 60, 90-day plan, like creating one for your new employees? Is that something that works for engineers, or is that something that is mainly something that exists outside the engineering world?
\n\nDAVE: I've only ever seen it done once, and when it was done, it was every bit as awkward as we all thought it would be. And it was profoundly effective, and I have missed it ever since.
\n\n[laughter]
\n\nJUSTIN: Wow. That did not go in the direction I thought it would go. I was like, [vocalization].
\n\nDAVE: Yap. It was with the first time I ever saw a manager who felt that being a manager was a full-time job and required him to study and learn management. And so, he was literally learning things like, when you have your one-on-one meeting, you have to quickly triage the meeting into, are they looking for training? Are they looking to just check in? Or are they melting down, and they need to vent? Because you have to handle those very, very differently. And if you try to go and fix and train when they're venting, it's going to go horribly. I'm like, I never had thought about that. And this particular person would come and say, "Hey, we need to go do our one-on-one."
\n\nAnd it was just...I'm like, this is awkward. This is dorky. "Okay, Carl, fine." And they'd get up...and we'd go to lunch, and it would start awkward. And then, five minutes in, we're just chatting, shooting the breeze. And we're talking architecture and where does the team go. And I grew a lot. And this was 10-12 years ago. It was kind of middle of my career. And my skills leapfrogged every single month.
\n\nThat was the first place where I put on, as my personal goals, to lose weight or to be able to run a mile under a certain time. And Carl was very, very proud of me when I put that on because he basically...I said, "If I do good cardio, I'm going to think more clearly, and I'm going to be more effective as a programmer." And he's like, "I think that's a fantastic goal. Put it down. Let me know what your time is in 30 days."
\n\nMATT: Interesting. I like that.
\n\nMIKE: I think we have rightly done so, talked about things that work well. One final question I want to ask is, is there anything that poisons the process? Is there anything that makes it just work terribly? To maybe illustrate the opposite, right? You know, as to what you can do well.
\n\nMATT: Yes, not following through. That's key, right? As people get busy, people get sidetracked, things like that, I think it's extremely important to follow through on the things that you promise to deliver, and not only is that relevant for onboarding. I think it's relevant just in business, in life, et cetera. But, you know, let's say I'm onboarding someone, and I say, "Okay, next week, I'm going to spend two days with you going through x," and I get sidetracked. I don't follow through. That's a really big failure on my part and, letting them down and not giving them the room to succeed. So, I --
\n\nDAVE: And it's critical. It's critical at that time, too, right?
\n\nMATT: Yeah.
\n\nDAVE: Because that one failure is 100% of their interactions with you to date and that set the direction that they're going to expect everything from them. You could never miss again, and they'll always wonder, is this the time that he's not going to follow through?
\n\nMATT: Yep. You paint that picture.
\n\nJUSTIN: One thing I've seen is when they've chosen the wrong person to be the onboarding buddy. And if they choose someone who is bitter about their current position or is not optimistic, it kind of can make that new person follow that persuasion, which is probably not what you want. So, --
\n\nDAVE: It's important to distinguish between bitterness and pessimistic, I think, maybe. Because I've worked with a programmer who just he was very much, like, leave me alone, don't, you know, da da da da. And the onboarding was basically...Our boss, I remember on day one, the very first thing she said was, "That's Terrence's office. Stay off his radar. He likes to fire new guys." I'm like, "Whoa, okay!"
\n\nJUSTIN: [laughs]
\n\nDAVE: And it was a government contractor. You could play that kind of politics and kind of stuff. And that was really, really good advice. And I didn't follow it, and exactly what she told me would happen to me happened to me at the next layoff [laughter]. It didn't make me bitter. It didn't affect my attitude. It wasn't office politics. It was office sociology. It was just, you know, be aware. That's a live wire. If you plug it into the power system, it'll run the whole city, but if you lick it, it's going to ruin your day. And so...
\n\nJUSTIN: [laughs]
\n\nDAVE: And she wasn't bitter. She loved the company. She loved her job. But she was very, very realistic about, like, that's awesome, and that's garbage and, you know --
\n\nMATT: Pragmatist.
\n\nDAVE: Pragmatic. Pragmatism. Yeah, that's exactly it. If it works, it's true. That's pragmatism. If it works, it's true.
\n\n[laughter]
\n\nMATT: But yeah, we definitely want to avoid people poisoning the well, right? Because it does, it carries over, and it kind of just...it spreads as well.
\n\nMIKE: We've talked before about psychological safety. You're bringing somebody in. It's not just code. And this is a critical thing. Software engineering, even somebody who's just starting and they're going to be writing a lot of code, they likely will not spend most of their day writing code, at least not every day. Software engineering is a lot of things that aren't code. It is a group endeavor. And you cannot build large projects effectively in isolation. It doesn't work that way. So, you're not just getting somebody to understand a codebase. You're helping somebody understand and build a culture. And you can't forget that it's more than one thing you're building.
\n\nDAVE: And I think I've mentioned this before: my favorite epiphany that I took away from skills clinic is that we think of development as a process where the developer is in the box, and we take a problem, and we put a problem in the box, and the solution comes out of the box. And that's not a programming career at all. The box is where the effort takes place, and we take a programmer at a problem and we put them in the box. And what you get out is a solution and a smarter programmer.
\n\nAnd if you focus on investing in that programmer, they're going to grow, and they're going to get smarter. And if you focus only on just product, product, product, product, product, some people will thrive, and some people they just miss...and it's just bad luck. It's not that they're not, you know, good or hardworking. It's that they got so focused on optimizing the process that they end up...it's like not stopping to sharpen the saw, right? You get so busy creating the output that you never increase your ability to create output.
\n\nMATT: I wanted to make a Beyond Thunderdome reference there, Dave. Two men enter, one man leaves.
\n\n[laughter]
\n\nDAVE: Right. That's right. Two problems enter, one solution leaves. I like it. I like it.
\n\nMIKE: To come back to a story, several years ago, I was riding bikes with my kids. And my oldest son was pulling somebody [laughs], one of my other kids. And he was back behind. And he was really having a hard time keeping up, which is unusual for him because of who he is [laughs]; I'll say that. He usually does not have a hard time keeping up. I usually have a hard time keeping up with him.
\n\nSo [laughs], he was just dragging, and he said, "Man, maybe I'm tired today." But he was just trying to muscle through it, and muscle through it, and muscle through it, and muscle through it." Finally, he said, "Can we take a break?" And he looked, and the bike he was pulling, you know, the trailer he was pulling, the tire was completely flat. So, he'd been, like, dragging a plow [laughs] through and was riding [inaudible 44:31] for miles [laughs].
\n\nDAVE: Just pulling [inaudible 44:33] the whole time.
\n\nMIKE: Yeah. If you don't take that time to look and make sure your tools are in good order and keep things going, you maybe can muscle through it for a while, but it's not going to work the long term.
\n\nDAVE: Tying it back to earlier, that's all about the hunting badgers, right? It's like the great thing that can come out of that is not, oh, I needed to fix the tire. The takeaway is sometimes I should stop and check my equipment. And that's the [laughter] aha moment of it. And that's the difference between having a good job and making a whole career, right? It's like that. You'll come back to that.
\n\nMATT: Instead of fixing the flat, prevent the flat.
\n\nDAVE: Or just be aware that --
\n\nMIKE: Be aware.
\n\nDAVE: You know, check your equipment, yeah.
\n\nMIKE: Sometimes flats happen [laughs], and you got to be aware of that.
\n\nJUSTIN: I think from a security point, the guy that thwarted the recent attack that was going to be on one of the base systems in Linux was checking his equipment because, all of a sudden, part of it was, like, going slower, and it was just a fraction of a second slower or something like that. But he went in and, like, discovered the bad code because he was checking his equipment.
\n\nDAVE: I've never believed so strongly in the a billion eyes makes all bugs shallow [laughter] from Linus Torvalds from the '90s. I'm like, okay, I believe you now, Linus, so...
\n\nJUSTIN: [laughs]
\n\nMIKE: Any other final words?
\n\nDAVE: Be good to each other. Do code reviews.
\n\nMATT: Yeah, right. [laughter] Our interactions are always a pleasure.
\n\nJUSTIN: Gentlemen, it has been a pleasure. Yeah, thank you.
\n\nMATT: Yes.
","summary":"The panel delves into the challenges and strategies of onboarding new employees to discuss the importance of communication, mentorship, and understanding context. Mike shares a story from his construction days in New Orleans, where he learned the value of being paired with an experienced team member. This buddy system helped him overcome communication barriers and adapt more quickly to his new environment.\r\n\r\nEffective onboarding involves more than just providing documentation. While documentation is valuable, it must be up-to-date and supplemented with hands-on guidance and practical experience. The panel advocates for giving new employees context about their tasks and the organization. This can include having them use the software as end-users or working directly with customers to understand the system and its impact better. Regular check-ins and skills clinics are also recommended to help employees stay updated and improve their skills.\r\n\r\nAdditionally, the podcast highlights the importance of continuous learning and mentorship for all employees, not just new hires. Regular mentor-mentee interactions and collaborative updates to documentation ensure that onboarding remains practical and relevant. Panelists note the pitfalls to avoid, such as not following through on commitments and assigning unsuitable onboarding buddies. Ensuring psychological safety and fostering a supportive culture are crucial to a successful onboarding process.","date_published":"2024-05-29T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/3b5f9d7b-fa63-40de-9a00-4d3a450c23a6.mp3","mime_type":"audio/mpeg","size_in_bytes":29601068,"duration_in_seconds":2779}]},{"id":"52150379-4e98-4bd3-9254-0550ed96fcf3","title":"Episode 46: Coding Myths","url":"https://acima-development.fireside.fm/46","content_text":"On this episodes, the panelists dive into common myths surrounding software development. Kicking off with a reference to Fred Brooks' \"The Mythical Man-Month,\" the conversation challenges the notion that adding more developers to a lagging project will speed up its completion. The discussion quickly expands to explore contexts where adding skilled, senior developers might indeed be beneficial, drawing analogies with emergency services during crises where more hands on deck can mean saving more lives.\n\nAs the episode progresses, the group delves deeper into the complexities of software development projects compared to other types of engineering and construction tasks. They discuss the unique challenges of software development, such as the dependencies and the need for sequential progress in certain areas, which can create bottlenecks regardless of the number of developers. This leads to a broader conversation about the necessity of strategic planning, the value of experience, and the pitfalls of assuming that increased manpower translates directly to increased productivity.\n\nThe dialogue culminates in a reflective discussion on the philosophical and practical aspects of software development beyond mere coding. The group touches upon the ongoing nature of software projects, the critical role of stress management, and the adaptability required in the tech industry. They highlight that, unlike more tangible engineering projects, software development is often about continual iteration and improvement rather than reaching a definitive endpoint. This conversation underscores the blend of technical skill, strategic thinking, and emotional resilience necessary to navigate the evolving landscapes of modern software development.\n\nTranscript:\n\nTAD: Hello. Welcome to another episode of the Acima Development Podcast. I'm Tad, and I'm going to be hosting this episode today. I'm joined by Will, Justin, Mike, and Ramses. The topic we're going to be discussing today is Common Myths About Software Development. And when I heard this, I thought of one of the classic myths. \n\nThere's actually a book called The Mythical Man-Month by Fred Brooks, and he talks about how adding extra developers to a late project isn't going to make that project go any faster. Or one of the interesting examples he gives, I think it's from that book, too, is you can't have nine women produce a baby in a month. You know, human development process, nine months, there are no shortcuts. Have you ever worked on a project where they thought, oh, we'll add more developers to this project, and it's actually worked out? \n\nMIKE: There's a very specific context where I've seen adding developers to a project actually helps, and that's when they are developers who are already very experienced in the industry and deeply familiar with the code at play.\n\nWILL: Yeah, we write it small, right? Like, your team lead or your engineering manager, you know, your senior engineers they kind of fill that role, right? And they sort of, like, parachute in firefighter. If things aren't going well, you need to deploy special forces to, like, help get this thing over the hump. Yeah, I think that's kind of standard, right? And, like, you know, you could deploy as many senior resources as you have available and familiar, you know, which is usually not as many as you'd like. \n\nMIKE: You had one phrase in there: as many as you have. Those three words are doing a lot of work [laughs]. Because if you've got an army, you have very few, like, Navy SEALs, right [laughs]? The elite forces are a small subset of your total workforce. \n\nJUSTIN: It's also worth noting that it's very expensive, both in time and treasure. \n\nMIKE: Ah, yes. \n\nJUSTIN: But going back to your original point, Tad, I think it's like, it is something that is not the norm. Like, you just can't hire contractors to come and solve your problem.\n\nTAD: It's a little counterintuitive, though, because in a lot of cases, adding more resources to something does increase the productivity, right? \n\nJUSTIN: I don't know. Like, can you cite some examples?\n\nWILL: Well, I mean, if I had an emergency room, right? I had an emergency room, holy cow, I'm so backed up. There was a train crash, and I have a lot of, like, patients coming in. I could bring in doctors, you know, I could bring them in or on call. And if I had to the degree that the facility could accommodate them with operating rooms and stuff like that, you know, I could bring in ER doctors, you know. \n\nTAD: More nurses, right? \n\nWILL: Fairly --\n\nTAD: And you should probably increase the throughput in your ER if you did that.\n\nWILL: Yeah, fairly linearly. And you could treat more people, right? And that's a high-skill profession, right? \n\nMIKE: Exactly. Exception proves the rule because you're talking about one of the most notoriously highly paid professions out there [laughs] because it does take that deep expertise. \n\nJUSTIN: So, another example that I'm familiar with is I worked in construction for a while, and, you know, this was back when I was in college and such. And you're working on a big project, and you're building a large building. Like, in this specific example, we were building a library, like a college library. And you can paralyze some things, but other things they have to be done before you can work on other things. And so, there's these natural choke points that you literally can't throw more people at or resources at because, like, the concrete has to set, or the dirt has to be, you know, prepared, and packed, and everything. \n\nWILL: Exactly, yeah, yeah.\n\nJUSTIN: And so, it's the same sort of thing when you're developing software. You have to decide on architecture. You have to decide on, you know, the third-party APIs you're calling. You got these things that you have to do, and you all have to follow the same pattern, hopefully, as you do the various things that you need the new thing to do. And if you have everybody doing different things, you might finish it, and it may be functional, but it's not going to be fun to maintain.\n\nWILL: Yeah, and, I mean, I think it goes back to like, sort of, like, running projects. I mean, I think there's really deep parallels between, like, sort of, like, you know, sort of sequential and parallel programming. It's like, you know, multi-cores, right? We've all got eight cores on our desktop. If you want to keep those cores hot, all of them hot, like, that is ferociously difficult programming, right? So, like, to create, I take a process and parallelize it. That's a fantastically difficult programming challenge. \n\nAnd I think analogous to that is okay; I've got eight people on my team. We all have to get this thing done. You know, how do I keep all these keyboards hot at the same time to, like, not choke point out, right? Because it's exactly as you say, there are natural choke points. And, like, you know, do you set up scaffolding? Do you set up, like, a fake API server so people can do the front end while the back end is still cooking? You know what I mean? All of these things. And that's a very difficult engineering challenge to, like, maximize the productivity of a squad with these natural in-built choke points. It's tough to do, really tough. \n\nMIKE: Well, and that's a really good...thinking about getting parallelized work on your processor, some of that algorithm is to guess, right? To make a best decision and have it start doing some work that you might have to throw away. To get that parallel, that level of parallel work, you're probably doing a lot of throwaway work. \n\nThat is part of the price of trying to get that parallelism is that sometimes you have to go down, you know, rabbit holes that you just have to completely drop. And, you know, that may be true even when it's serial load, but even more so when it's parallel. If you don't know which way you're going to go, you have to do both. And, again, there's cost that comes from that. And if you want to massively parallelize, you're probably going to be doing a lot of throwaway work. \n\nWILL: Absolutely, absolutely. I mean, it's a fact, an absolute fact that parallelizing, multi-threading a process is always less efficient, you know what I mean? If for no other reason than the job-switching infrastructure, you know what I mean? If you're real dorky, you could spend a lot of time on that. But, like, you got to do stuff every time that thread switches context. Every single time. You know, say nothing of deadlocks and all that stuff, so, you know, yeah. Absolutely. \n\nBut I do actually think developers are too afraid of scaffolding that's intended. Going back to construction again, right? You're building infrastructure with the explicit end goal of tearing it all out. You know, it gives somebody a platform to work on while the stairs don't exist. I think embracing that with both hands winds up being a pretty big net win, in my opinion. \n\nMIKE: That's an interesting observation there. You say you deliberately build something you know you're going to throw out because it expedites the other work getting done. \n\nTAD: Because it's pretty disheartening to throw code away. As a developer, you take an emotional hit when you've been working on something for two weeks, and they say, \"Ah, we're going to go in a different direction.\" You're like, \"Oh, sad [laughs]. Well, into the trash goes all my efforts.\" \n\nWILL: Yeah, absolutely.\n\nEDDY: And it hurts more when you have it tested. Like, when [laughter] you have all your tests [inaudible 07:55] out, and it turns out you don't need it anymore, and it's like, ah. \n\nMIKE: There's a mindset thing here, though, of what value we're trying to provide to the business. We're not trying to provide code. We're trying to solve problems. And [laughs] if we approach it from that perspective, we say, \"Yeah, this was a step in working towards solving that problem.\" You know, I think we have to be kind of relentless at ourselves that way. The code is not the end product here. We're talking about myths. Our job is to code? Boy, that is not our job. \n\nTAD: Well, it's a component of our job, right? \n\nMIKE: It is. \n\nTAD: Well, maybe we should flesh that out a little bit. What are the other aspects of software development other than code? \n\nMATT: Number one, communication.\n\nTAD: Right, because you're talking about what you're going to build before you ever write a single line of code, usually. \n\nEDDY: Stress management. \n\nMIKE: Think about big construction like a bridge. You would not consider hiring an engineering firm that wouldn't take a year planning before they ever put a shovel into the ground, right [laughs]? Because it's recognized that for big projects, planning is a big part of the work. You've got to coordinate. You've got to figure out what you're doing. You've got to figure, you know, you've got to do surveying [laughs] to figure out what's going on. \n\nYou may not have that if you're doing small-scale construction, but absolutely for the big stuff. And even for small scale, I mean, you're going to have a blueprint, hopefully [laughs]. Even if you're building a shed, you probably have a drawing, right? That is work. There is a great deal of work that goes into that construction project that is not the hands-on laying down the materials.\n\nMATT: Then it becomes like putting Legos together, right? If you plan everything well, you know the pieces that need to be put together, and then you just need to put them together. \n\nWILL: Yeah, but, I mean, that's the standard. That's the standard. That's your waterfall model, right? That's waterfall development, which, I don't know, I mean, like, I'm pretty partisan, you know, in terms of I like smaller pieces of work, even if the overall strategy is like, I want to get this big thing done, you know what I mean? Like, I like small pieces of work because I just, you know, and we touched on it, I think, the last session. \n\nLike, I am deeply...I'm not skeptical or cautious of overestimating how smart I am and how good my strategy is and stuff like that. With construction, if I'm building a dam, that's where it is, you know? Like, there's a lot of stuff where it's like, you can't go back, or it's prohibitively difficult to go back. But with software, you do have great flexibility for most projects. \n\nMATT: Yeah. You've called out a good point. I think remaining agile is super important in today's software development world, right? It's necessary. Preloading the planning, yeah, sounds very waterfall-ish. If you can do that, maybe it's just the time before it hits engineering that happens, you know, and by the time it gets to engineering, then it's broken down to smaller problems. And you break it down into simple stories, and you can work from there. That's, I mean, to me, that's agile programming. \n\nTAD: Is there a myth, though, that programming is predictable? Because what's that quote? You know, everyone has a plan until they get punched in the mouth [laughter]. I've never worked on a software project that has gone exactly according to plan. \n\nJUSTIN: If it's a very simple well-known use case, you can do it very quickly. So, like, you know, I want to set up a blog, you know, have comments and everything, and that's, like, every single tech demo ever. So, you got every single language that you could do it in, in datastore and such. I was thinking of a really good example of something that is well-defined, and that can be put together in the real world. \n\nAnd there was, like, a news story about the U.S. Navy putting together a port in Gaza to unload supplies for the refugees or the people who live there. And they basically could put together this pre-assembled port that the Navy uses on any combat situation, and they could put it together very rapidly and people who know exactly what to do. And all of a sudden, you have this port where huge ships can unload supplies on. \n\nAnd it's just an example of, hey, if you have a well-defined problem and you have the tools to solve it, you can do very big things very fast. But if you go off that path, then you start having to, like, call in the experts and decide, okay, now that we're going off this path, what should I do in such a way that I'm building something that will last and that is durable? So...\n\nWILL: Right. Well, I mean, and that's the nature of software sort of consuming itself in that, like, when you have that sort of, like, pre-built port roadmap, that's a software product, you know what I mean? Like, when it comes to software, like, when you have things defined to that degree, then it's just, like, push a button, you know what I mean? Like Shopify, right? If I want an e-commerce store, Shopify can get me up in an hour, you know, and they do a pretty good job at it. And so, it becomes, well, what else do you want to do? And fortunately enough for us, they always want more, just a little more. \n\n[laughter]\n\nMATT: And if you want to integrate with Shopify, that's another story.\n\nWILL: Sure. Absolutely. But, like, if you wanted to integrate with Shopify, well, that's something, you know, new that Shopify doesn't do. And then, we're into custom software land, and I'm making my [inaudible 13:37] payment this month. \n\nTAD: That does touch on one of the myths I was thinking about earlier today that a lot of times we parallel software development with things like building a dam, or construction, or things like that, and those things get finished, right? They complete the project, and then they walk away and move on to another project. And software, just because it got released, doesn't mean that you're done. \n\nWILL: Oh yeah.\n\nMATT: Never done. \n\nWILL: Yeah, yeah. I think that's a myth. \n\nEDDY: But when you --\n\nWILL: So, the software is released, right? It's done [laughter]. Like, it's –- \n\nMATT: [crosstalk 14:16] that you're finished, right? \n\nEDDY: Sure, but you got to have people to go back and maintain whatever it is you built, whether it's software, whether it's a building, a car; it doesn't matter. There is a level of maintenance that still is required. \n\nTAD: Even saying built makes it sound completed or finished. \n\nMIKE: Yeah, and to take that further, some software products that we use were created for some utterly different purpose. Didn't Slack come out of, like, an internal messaging video game or something?\n\nWILL: Some, like, in-game chat or something. Or was it just inside the company? \n\nMIKE: I think it was just inside the company. So, they went to build a video game, and they ended up building a business messaging platform. Like, when we say build and release, like, yeah, I went to build a video game, and I built business software. And if you were going to build a bridge, you say, \"I went to build a bridge, but I actually built a skyscraper with an airport on top.\" It doesn't work that way, but we have to do that all the time.\n\nThink about that planning that was brought up before. Yeah, that planning, that cost still has to happen. But recognizing that we have to do these iterations, we still do the planning, but we do it on a smaller loop. We don't spend two years doing it upfront because we know that work is going to be thrown away, right? But we still have to do the work. It's just done in a smaller loop. So, you're spreading it out over the two years rather than doing it upfront. \n\nYou still have to have that feedback, and there's still the work involved. There's still the job of communicating, figuring out where we are now and where we go next, and that never goes away. Whether it's upfront or whether it's later, it's still there. And if you try to pretend it's not there, you'll get in trouble quick, I don't know.\n\nAnd that brings me to another myth. I pointed...it's xkcd number 2030, two zero, three zero. I think about this all the time. It's about voting software, which is kind of irrelevant. There's a line from it where the character says, \"I don't know quite how to put this, but our entire field is bad at what we do. And if you rely on us [laughter], everyone will die.\" And if there's one myth I see about software, you expect that people just know what they're doing. No, we don't [chuckles]. We don't know what we're doing. We don't even know what we're building. \n\nWe're building a video game that's going to end up business software, right? And that's not even necessarily a bad thing. We're building something out, and then we'll have something of value and see if we can use it. You know, it's this weird product that's kind of, like, other things and kind of unlike, I say, other things in that it's flexible, and sometimes it meets different needs. And it means that it's kind of hard to talk about, kind of hard to deal with. And we make a lot of foolish mistakes.\n\nI've seen this with new developers, particularly people who change career later in life. They come in and they think that we all know exactly what we're doing, and it takes a while to be disillusioned. You got to kind of break that early and say, \"It may look like we know what we're doing, but a lot of our job, maybe not most, but a good portion of our job is trying to figure out what we're doing. We're researching it as we go. We don't know how to use the tools. We don't even know what tools we're using, and we don't understand the requirements. So, a big portion of our job is figuring all that stuff out so that we can get something that works out in the end.\" \n\nTAD: And a lot of times, you can't know what is needed, and what you need to do, and what the requirements are until you actually jump in and start poking around and doing the coding, doing the research, doing the things, getting both hands into the project. And you're like, oh, now I'm starting to see what shape this needs to take. \n\nWILL: I mean, that ties into something that Eddy mentioned in passing, and it's a myth that I think...let me see how to put it. So, what Eddy was saying was, like, stress management is, like, most of what we do. And I think the myth of...and, I mean, I agree with that, and I think I'd maybe, like, broaden it out to say, like, I think people think of software development as this intellectual exercise. And there are sort of fairly specialized slivers of it that can be that. But by and large, you have to be smart enough and willing to sort of, like, bulldoze your way through thinking about the problems, thinking about the requirements, thinking about the legacy source code and how it works, thinking about, like, you know, how you do the stuff.\n\nI mean, if you even look at, like, sort of, like, these programming puzzles that some people like for interviews, right? LeetCode medium, right? It's far in excess of anything that we actually have to do on an intellectual problem-solving level. What we need to do is maintain, like, a sort of, like, emotional equilibrium and focus on this fairly mundane, ditch digging, systems integration, team collaboration, requirement, negotiation, source of problems. Like, that's what will make you...\n\nLike, if you're, you know, slightly above average intelligence but you have exceptional drive and emotional equilibrium, you know what I mean? Then you're going to be a very successful programmer. But, like, if you have exceptional intelligence and, like, you're a little bit squirrely in terms of, like, just grinding through, like, the necessarily frustrating tedium of, like, professional software development within a business organization, you're going to have a very difficult time, you know what I mean? \n\nTAD: Yeah, and I think there's a myth that all software is kind of the same and that the skills needed are kind of the same. For example, I hear a lot of people ask, \"Oh, are you really good at math? You really need to be good at math for software development\". And then, I have to say something like, \"Well, yes, if you're writing software for a nuclear collider, then you're going to need a lot of math. But if you're a front-end developer wanting to make some really cool interactive thing, maybe you need to know a little bit more design, and you don't really need that much math.\" Or the example earlier, set up a blog. I don't think you need any math to set up a blog probably, right? But those are all software development.\n\nMATT: Yeah. And maybe this is just me, but I think the people who are just naturally good at math make good software engineers, just that mindset and the way they do things. They may not make the best front-end people, but there's a place for them, right? I think a myth also could be that, hey, I should just switch over to software engineering because the pay is great. I've seen a lot of people make that mistake. It's not for everybody. \n\nWILL: They're having their day right now. I think there's a lot of people who came in for the bag, you know what I mean? And now we're in tech winter and, like, those doctor money FAANG jobs are a little short on the ground. And so, it's just like, \"Would you only do this for a paltry $120,000 a year like a peasant?\"\n\nMATT: [laughs].\n\nWILL: Like, \"Whoa, whoa, whoa, whoa. I'm going to go back to finance,\" or whatever, right? And those kind of people. And then, you know, you have to wake up every day and want to do it, you know what I mean? I mean, just because, like...I'm pretty good at programming, but every project, you know, like, I got to wrestle the pig every time. It's a brand-new pig, and you're going to have to get in the mud every time. Every time. It doesn't get easier. You just get, I don't know, stronger, you know? \n\nI was having a conversation with somebody who was talking about like, you know, like, needing to hire somebody and the difficulties associated with hiring people and how you'll have these people who, they'll go in, and they'll crush their interview. Like, they'll do really good on these algorithmic problems, you know. And then, you'll take them into the actual workplace where they have to go out and, like, you know, do the actual nitty-gritty nuts and bolts jobs. And they'll struggle or, like, they'll do good for a while. And then, sort of like the morale will fall off, and they'll struggle. And, you know, and, like, you'll have smart people who just can't maintain the focus of, like, staying after it, you know. And then, they will be bad because it's a nonstop grind and, like, yeah, it's tough. \n\nTAD: I've heard it compared to a treadmill.\n\nMATT: That's one of the reasons, Will --\n\nTAD: If you enjoy the exercise, then a treadmill is not bad. But if you're constantly learning and you're constantly working on things, maybe you're frustrated some of the days, right? Not everyone enjoys exercising on a treadmill. \n\nMATT: That's one of the reasons I don't ask the mapping of matrices and things like that in interviews. I just don't. I don't ask really computer sciencey questions because that isn't the real world most of the time. \n\nEDDY: Okay, but the real question is if someone came up to you from your family and said, \"Can you fix my computer?\" Can you? Can you fix that computer? \n\nMATT: Ugh. I hate that. That is the worst question ever, Eddy. \n\nEDDY: [laughs]\n\nTAD: Yes, that's why I have a master's degree. \n\nEDDY: [laughs]\n\nMATT: Sometimes. I mean, you know, sure, we know that stuff, but it's not what we do. \n\nTAD: Yeah. I mean, I can Google as well as the next person. \n\nWILL: I can Google much, much, much better than the next person. \n\nTAD: Actually, that's true.\n\nMATT: Which is what we spend a lot of our time doing, right? \n\nMIKE: That's one of the most critical development skills is Googling.\n\nTAD: Finding the right information, right? \n\nMIKE: If you think that managing hardware and setting up something with, like, the TV is what we're good at, then you should see any engineering meeting trying to figure out the presentation, like, the hardware in the meeting room [laughs], just trying to get a meeting going. It never works. \n\nMATT: Let's not even get started on spreadsheets. \n\nWILL: I'm terrible at spreadsheets. I don't know how to do them. Like, as soon as...whenever I've had a spreadsheet, like, challenge, like, I Google it. I learn everything I need to know for the next, like, 15 minutes of work, and then immediately cash dump it. I'm just like, pfft, flush. That's out. I'm out.\n\nMATT: I do the same thing. \n\nWILL: Pivot table, whatever. I know the word pivot table is usually the answer to my problem.\n\nTAD: [laughs]\n\nWILL: And then, if you put a gun to my head and ask me to write up a pivot table in Excel, you better have a bucket and a mop. \n\nMIKE: You know, you said something about we're focusing on the, you know, the grind and the treadmill. I read a quote from a bikepacking racer. I don't remember which guy it was, but I read it recently. And he said that that kind of racing, like endurance racing, and it could also apply to marathons or ultra runners, that kind of thing, he said that it's mostly about fatigue management. And you think, oh, you know, it's about building strength. And he's like, \"No, it's, like, about eating the right food and managing your sleep and not pushing yourself too hard.\"\n\nNone of those are, like, things that you might necessarily think about have to do with racing. Like, eating? Racing? What? No, it's about managing your body and your equipment so that it can keep going. And that sustainability, you know, trying to think about that metaphor, that sustainability really is, like, a central aspect of our craft. And you can get off, right? You can get unsustainable, and that puts you in a bad spot.\n\nMATT: You end up in burnout. Be good at compartmentalizing, right? I know you and I have talked about that before, Mike. \n\nWILL: It's legitimately tough to do. I think there's a lot of places that are in...I will call them...I mean, honestly, I'd say, like, go at doom loop, you know what I mean? And I was talking about this with Mike a little bit, like, before we got on. It's one of the things that I've been seeing because, like, you know, we're in tech winter now, right? So, things are rough. You know, layoffs are happening, you know what I mean? Like, teams are squeezed pretty tight. I think it's across the industry. Even if you made it, even if you're still working, like, you still have, like, the reaper's hand on your shoulder being like, \"How are the tickets going?\"\n\n[laughter]\n\nAnd so, you have these situations where, like, you know, you have a business downturn. You have business pressure. And then, they'll have layoffs, you know what I mean? So, like, that impacts morale. You lose head count. Maybe you don't have nine women to make the baby in a month. Maybe you only have eight. And then, that impacts productivity, and then...you know what I mean? \n\nAnd a lot of it really is sort of, like, it impacts people's emotional equilibrium, their feelings about their work, you know what I mean? Like, I think it's very understated, you know because it all exists in your brain. And without that focus, that willingness to focus, that willingness to, like, really concentrate, things become extremely tenuous. And you get into the burnout mode, you know.\n\nBut you can't stop peddling because, you know, you got business pressure. And, like, you got to make your deliverables. You got to make...you have to make money so that the business can give it to you. And you find yourself with these doom loops, these ugly, ugly, ugly spirals. And I see a lot of that in a lot of places when I talk to folks in the business right now. \n\nMIKE: Which comes back to the same thing, that tenacity [laughs] and fatigue management is going to be the thing that gets you through that winter. My grandfather lived through World War II in Norway. And his family survived through the winter on a barrel of pickled herring [laughter]. [inaudible 27:54] through the winter on a barrel of pickled herring [laughs] is how you get through the winter. Recognizing that it may not always be very nice. There probably will be spring on the other end. \n\nWILL: Oh yeah, and it always will be. Nobody's throwing their computers at the dumpster. I don't see it. It's like people would just be like, \"Ah, the internet. We're over it. We're done [laughter],\" right? \n\nMATT: At least in my experience, there's always a light at the end of the tunnel. You're going to experience burnout. It happens to everyone. Like Mike's grandfather, you just power through it, and you do what you have to do to survive. And, eventually, you know, this can be the greatest job in the world. It can also be the hardest job in the world. And you're going to experience both of those. \n\nWILL: It depends on the day [laughs]. It depends on the day. Sometimes, it depends on the hour. I mean, I will say that, like, that grind...I don't remember where I heard this, but, like, tenure of a software developer is they usually make it, on average, to about 36. That's not a lot better than playing in the NBA.\n\n[laughter]\n\nMIKE: Well, that's interesting.\n\nMATT: That is very interesting.\n\nWILL: And I believe that number could be out of date, at the very least. I remember it very clearly that I definitely read that, and it could be, you know, maybe a shaky study. But, I mean, I remember the number because it struck me so viscerally. I'm like, oh my God. Like, if you look at somebody like, I don't know, like me, I'm 44, right? If I was a physician, an MD, I'd be, like, just entering into my best years, entering it. It's like, well, you know, he's still a little green, but he's starting to get his feet under him. You know, I think he's ready to go. \n\nBut, like, as a software developer, it's just like, you know, people looking at you like Old Yeller, you know what I mean? [laughter] Where it's like, you're walking into the office with a limp, you know what I mean? Like, let's take you back behind the shed. \n\nMATT: Well, just with this group here, we're doing pretty good with those odds, right? \n\nMIKE: Yeah [laughs]. I'm thinking people I've known who have gotten past that or maybe the people who did have the ability to keep going. I've worked with some experienced people. I do work with some experienced people that I find their experience to be indispensable. I don't know how they could do their job, or I could do my job without being able to rely on those years of experience that they wouldn't have had at 36. \n\nWILL: I've found that older developers tend to be pretty bimodal, you know what I mean? Like, there's not a lot of, like, developers, you know, like, north of 40 that are in the middle. Like, it's not really a bell curve. It's kind of like you're either -- \n\nMIKE: [laughs]\n\nWILL: Awful or you're fantastic. I'm trying really hard to head towards the light because I have met some awful ones, some truly, truly bad ones where it's just like, you gave up several years ago.\n\nMIKE: So, that can happen when you step off the treadmill for a while [laughs]. \n\nTAD: It's something that you got to keep working on all the time because technology keeps advancing, and you got to keep up with the advancements, right? Not necessarily all of it everywhere, but at least the stuff that's relevant to what you're working on.\n\nMATT: We're all going to be prompt engineers before you know it.\n\nWILL: All ready. All day. \n\nMIKE: [laughs]\n\nWILL: I think that's where things are going. I think that AI tools I think they are going to be a fantastic force multiplier, but they're not taking anybody's...well, I wanted to say they're not going to take anybody's jobs, right? But, like, if they double your productivity, you know, the head count's going to go down by 20% probably.\n\nMIKE: There was an agricultural revolution back, what, in the 1800s? And that doesn't mean we don't have farmers. We still have farmers. But they generally operate at a much larger scale, and they're a much smaller percentage of the population. And interestingly, new fields of labor opened up because everybody wasn't farming anymore. I don't think our jobs are going away. Like, there's still people developing software.\n\nAnd it took a while, you know, but agriculture still exists. It's an important industry. And, you know, there are farmers. Farmers exist, but the way they operate is different. And there's new industries that didn't exist, like I was saying. You know, they've enabled different ways of working. And so, a lot of people who would have been farmers are now doing stuff that's adjacent to that or maybe totally different to that because it's enabled by the farmers being more effective. \n\nI think we'll have similar kinds of transitions that are a little hard to think about. You couldn't have explained a software developer to a farmer back in 1830. Conceptually, that work didn't really exist, and we couldn't even conceive of it. But I think that we'll have that similar sort of transition where, yeah, there'll still be people developing software, but it'll be a different format. And the jobs people have it might not be prompt engineer. It's going to be something that is going to be kind of incomprehensible, I imagine, to us right now. But it would make sense if you saw the evolution over time.\n\nTAD: But I think it's kind of a different beast, right? Because I don't know of any organization that's like, \"Oh, you guys have doubled your productivity? Oh, well, we're going to keep the same number of feature requirements that we had,\" right? They're like, \"Oh, you've doubled your productivity? Sweet. We can, like, have twice as many features as we wanted before,\" right?\n\nWell, I haven't experienced it yet where they've run out of ideas or new software projects or things like that, where they're just like, \"Oh, well, we're kind of running low on places to spread our software or new places...\" you know, it's like...because I imagine, like, even if we suddenly, like, 10x our productivity overnight, they'd be like, \"Oh, sweet, we're going to move into, like, more countries than we were planning,\" or \"We're going to have more features per year than we were planning.\"\n\nWILL: And I'd also say, like, even more so that because of the nonlinear increase in complexity as software scales, right? \n\nTAD: Yeah. \n\nWILL: Let's say everybody doubles developer productivity, which is, like, a pretty bold statement, but, like, attainable, attainable. But that's probably the top edge of attainable, in my view, with, like, the AI, like, stuff. That's, like, 20% more features because, like, it isn't linear, you know what I mean? 20% more features. Because if you have 20% more stuff, like, I mean, so, within Acima, I mean, think about, like, it would be maybe one other big initiative, you know what I mean? You know what I mean? Like, you'd add one more team feature thing, right? I don't know how many teams you guys have now. \n\nMIKE: I think you're onto something really important there. We talked about the planning and the non-coding aspects of the job. The AI stuff really helps mostly with the coding aspect, right? Does it help with getting requirements from stakeholders? Probably not. If 50% of the job is coding and you completely eliminate that [inaudible 34:59]\n\nWILL: And the style, right? \n\nMIKE: 100% productivity will increase in coding, right? Like, it all goes away. You only get to work on twice as many things -- \n\nWILL: Absolutely, absolutely. So, you know, honestly, like, I've been really having a tremendous amount of fun with it just because, like, generally speaking, I know what I want done, and I can express it in a reasonably concise, understandable way. I just might not know, like, all its syntax, you know. And so, like, that has just been, like, cleared from my past. It is an absolute delight, as far as I'm concerned, because a lot of the, like, I just [inaudible 35:37] BS ticki tack jobs are just, like, I have an assistant, you know, with a broom, you know what I mean? Like, I could build a house, and I have a helper handing me boards and, like, doing the sweep up for me. I'm like, ah, this is...yes, all day. I love it.\n\nTAD: Yeah. I think that's a great place to kind of stop. So, thank you, everybody, for participating. Thank you for all of your comments. ","content_html":"On this episodes, the panelists dive into common myths surrounding software development. Kicking off with a reference to Fred Brooks' "The Mythical Man-Month," the conversation challenges the notion that adding more developers to a lagging project will speed up its completion. The discussion quickly expands to explore contexts where adding skilled, senior developers might indeed be beneficial, drawing analogies with emergency services during crises where more hands on deck can mean saving more lives.
\n\nAs the episode progresses, the group delves deeper into the complexities of software development projects compared to other types of engineering and construction tasks. They discuss the unique challenges of software development, such as the dependencies and the need for sequential progress in certain areas, which can create bottlenecks regardless of the number of developers. This leads to a broader conversation about the necessity of strategic planning, the value of experience, and the pitfalls of assuming that increased manpower translates directly to increased productivity.
\n\nThe dialogue culminates in a reflective discussion on the philosophical and practical aspects of software development beyond mere coding. The group touches upon the ongoing nature of software projects, the critical role of stress management, and the adaptability required in the tech industry. They highlight that, unlike more tangible engineering projects, software development is often about continual iteration and improvement rather than reaching a definitive endpoint. This conversation underscores the blend of technical skill, strategic thinking, and emotional resilience necessary to navigate the evolving landscapes of modern software development.
\n\nTranscript:
\n\nTAD: Hello. Welcome to another episode of the Acima Development Podcast. I'm Tad, and I'm going to be hosting this episode today. I'm joined by Will, Justin, Mike, and Ramses. The topic we're going to be discussing today is Common Myths About Software Development. And when I heard this, I thought of one of the classic myths.
\n\nThere's actually a book called The Mythical Man-Month by Fred Brooks, and he talks about how adding extra developers to a late project isn't going to make that project go any faster. Or one of the interesting examples he gives, I think it's from that book, too, is you can't have nine women produce a baby in a month. You know, human development process, nine months, there are no shortcuts. Have you ever worked on a project where they thought, oh, we'll add more developers to this project, and it's actually worked out?
\n\nMIKE: There's a very specific context where I've seen adding developers to a project actually helps, and that's when they are developers who are already very experienced in the industry and deeply familiar with the code at play.
\n\nWILL: Yeah, we write it small, right? Like, your team lead or your engineering manager, you know, your senior engineers they kind of fill that role, right? And they sort of, like, parachute in firefighter. If things aren't going well, you need to deploy special forces to, like, help get this thing over the hump. Yeah, I think that's kind of standard, right? And, like, you know, you could deploy as many senior resources as you have available and familiar, you know, which is usually not as many as you'd like.
\n\nMIKE: You had one phrase in there: as many as you have. Those three words are doing a lot of work [laughs]. Because if you've got an army, you have very few, like, Navy SEALs, right [laughs]? The elite forces are a small subset of your total workforce.
\n\nJUSTIN: It's also worth noting that it's very expensive, both in time and treasure.
\n\nMIKE: Ah, yes.
\n\nJUSTIN: But going back to your original point, Tad, I think it's like, it is something that is not the norm. Like, you just can't hire contractors to come and solve your problem.
\n\nTAD: It's a little counterintuitive, though, because in a lot of cases, adding more resources to something does increase the productivity, right?
\n\nJUSTIN: I don't know. Like, can you cite some examples?
\n\nWILL: Well, I mean, if I had an emergency room, right? I had an emergency room, holy cow, I'm so backed up. There was a train crash, and I have a lot of, like, patients coming in. I could bring in doctors, you know, I could bring them in or on call. And if I had to the degree that the facility could accommodate them with operating rooms and stuff like that, you know, I could bring in ER doctors, you know.
\n\nTAD: More nurses, right?
\n\nWILL: Fairly --
\n\nTAD: And you should probably increase the throughput in your ER if you did that.
\n\nWILL: Yeah, fairly linearly. And you could treat more people, right? And that's a high-skill profession, right?
\n\nMIKE: Exactly. Exception proves the rule because you're talking about one of the most notoriously highly paid professions out there [laughs] because it does take that deep expertise.
\n\nJUSTIN: So, another example that I'm familiar with is I worked in construction for a while, and, you know, this was back when I was in college and such. And you're working on a big project, and you're building a large building. Like, in this specific example, we were building a library, like a college library. And you can paralyze some things, but other things they have to be done before you can work on other things. And so, there's these natural choke points that you literally can't throw more people at or resources at because, like, the concrete has to set, or the dirt has to be, you know, prepared, and packed, and everything.
\n\nWILL: Exactly, yeah, yeah.
\n\nJUSTIN: And so, it's the same sort of thing when you're developing software. You have to decide on architecture. You have to decide on, you know, the third-party APIs you're calling. You got these things that you have to do, and you all have to follow the same pattern, hopefully, as you do the various things that you need the new thing to do. And if you have everybody doing different things, you might finish it, and it may be functional, but it's not going to be fun to maintain.
\n\nWILL: Yeah, and, I mean, I think it goes back to like, sort of, like, running projects. I mean, I think there's really deep parallels between, like, sort of, like, you know, sort of sequential and parallel programming. It's like, you know, multi-cores, right? We've all got eight cores on our desktop. If you want to keep those cores hot, all of them hot, like, that is ferociously difficult programming, right? So, like, to create, I take a process and parallelize it. That's a fantastically difficult programming challenge.
\n\nAnd I think analogous to that is okay; I've got eight people on my team. We all have to get this thing done. You know, how do I keep all these keyboards hot at the same time to, like, not choke point out, right? Because it's exactly as you say, there are natural choke points. And, like, you know, do you set up scaffolding? Do you set up, like, a fake API server so people can do the front end while the back end is still cooking? You know what I mean? All of these things. And that's a very difficult engineering challenge to, like, maximize the productivity of a squad with these natural in-built choke points. It's tough to do, really tough.
\n\nMIKE: Well, and that's a really good...thinking about getting parallelized work on your processor, some of that algorithm is to guess, right? To make a best decision and have it start doing some work that you might have to throw away. To get that parallel, that level of parallel work, you're probably doing a lot of throwaway work.
\n\nThat is part of the price of trying to get that parallelism is that sometimes you have to go down, you know, rabbit holes that you just have to completely drop. And, you know, that may be true even when it's serial load, but even more so when it's parallel. If you don't know which way you're going to go, you have to do both. And, again, there's cost that comes from that. And if you want to massively parallelize, you're probably going to be doing a lot of throwaway work.
\n\nWILL: Absolutely, absolutely. I mean, it's a fact, an absolute fact that parallelizing, multi-threading a process is always less efficient, you know what I mean? If for no other reason than the job-switching infrastructure, you know what I mean? If you're real dorky, you could spend a lot of time on that. But, like, you got to do stuff every time that thread switches context. Every single time. You know, say nothing of deadlocks and all that stuff, so, you know, yeah. Absolutely.
\n\nBut I do actually think developers are too afraid of scaffolding that's intended. Going back to construction again, right? You're building infrastructure with the explicit end goal of tearing it all out. You know, it gives somebody a platform to work on while the stairs don't exist. I think embracing that with both hands winds up being a pretty big net win, in my opinion.
\n\nMIKE: That's an interesting observation there. You say you deliberately build something you know you're going to throw out because it expedites the other work getting done.
\n\nTAD: Because it's pretty disheartening to throw code away. As a developer, you take an emotional hit when you've been working on something for two weeks, and they say, "Ah, we're going to go in a different direction." You're like, "Oh, sad [laughs]. Well, into the trash goes all my efforts."
\n\nWILL: Yeah, absolutely.
\n\nEDDY: And it hurts more when you have it tested. Like, when [laughter] you have all your tests [inaudible 07:55] out, and it turns out you don't need it anymore, and it's like, ah.
\n\nMIKE: There's a mindset thing here, though, of what value we're trying to provide to the business. We're not trying to provide code. We're trying to solve problems. And [laughs] if we approach it from that perspective, we say, "Yeah, this was a step in working towards solving that problem." You know, I think we have to be kind of relentless at ourselves that way. The code is not the end product here. We're talking about myths. Our job is to code? Boy, that is not our job.
\n\nTAD: Well, it's a component of our job, right?
\n\nMIKE: It is.
\n\nTAD: Well, maybe we should flesh that out a little bit. What are the other aspects of software development other than code?
\n\nMATT: Number one, communication.
\n\nTAD: Right, because you're talking about what you're going to build before you ever write a single line of code, usually.
\n\nEDDY: Stress management.
\n\nMIKE: Think about big construction like a bridge. You would not consider hiring an engineering firm that wouldn't take a year planning before they ever put a shovel into the ground, right [laughs]? Because it's recognized that for big projects, planning is a big part of the work. You've got to coordinate. You've got to figure out what you're doing. You've got to figure, you know, you've got to do surveying [laughs] to figure out what's going on.
\n\nYou may not have that if you're doing small-scale construction, but absolutely for the big stuff. And even for small scale, I mean, you're going to have a blueprint, hopefully [laughs]. Even if you're building a shed, you probably have a drawing, right? That is work. There is a great deal of work that goes into that construction project that is not the hands-on laying down the materials.
\n\nMATT: Then it becomes like putting Legos together, right? If you plan everything well, you know the pieces that need to be put together, and then you just need to put them together.
\n\nWILL: Yeah, but, I mean, that's the standard. That's the standard. That's your waterfall model, right? That's waterfall development, which, I don't know, I mean, like, I'm pretty partisan, you know, in terms of I like smaller pieces of work, even if the overall strategy is like, I want to get this big thing done, you know what I mean? Like, I like small pieces of work because I just, you know, and we touched on it, I think, the last session.
\n\nLike, I am deeply...I'm not skeptical or cautious of overestimating how smart I am and how good my strategy is and stuff like that. With construction, if I'm building a dam, that's where it is, you know? Like, there's a lot of stuff where it's like, you can't go back, or it's prohibitively difficult to go back. But with software, you do have great flexibility for most projects.
\n\nMATT: Yeah. You've called out a good point. I think remaining agile is super important in today's software development world, right? It's necessary. Preloading the planning, yeah, sounds very waterfall-ish. If you can do that, maybe it's just the time before it hits engineering that happens, you know, and by the time it gets to engineering, then it's broken down to smaller problems. And you break it down into simple stories, and you can work from there. That's, I mean, to me, that's agile programming.
\n\nTAD: Is there a myth, though, that programming is predictable? Because what's that quote? You know, everyone has a plan until they get punched in the mouth [laughter]. I've never worked on a software project that has gone exactly according to plan.
\n\nJUSTIN: If it's a very simple well-known use case, you can do it very quickly. So, like, you know, I want to set up a blog, you know, have comments and everything, and that's, like, every single tech demo ever. So, you got every single language that you could do it in, in datastore and such. I was thinking of a really good example of something that is well-defined, and that can be put together in the real world.
\n\nAnd there was, like, a news story about the U.S. Navy putting together a port in Gaza to unload supplies for the refugees or the people who live there. And they basically could put together this pre-assembled port that the Navy uses on any combat situation, and they could put it together very rapidly and people who know exactly what to do. And all of a sudden, you have this port where huge ships can unload supplies on.
\n\nAnd it's just an example of, hey, if you have a well-defined problem and you have the tools to solve it, you can do very big things very fast. But if you go off that path, then you start having to, like, call in the experts and decide, okay, now that we're going off this path, what should I do in such a way that I'm building something that will last and that is durable? So...
\n\nWILL: Right. Well, I mean, and that's the nature of software sort of consuming itself in that, like, when you have that sort of, like, pre-built port roadmap, that's a software product, you know what I mean? Like, when it comes to software, like, when you have things defined to that degree, then it's just, like, push a button, you know what I mean? Like Shopify, right? If I want an e-commerce store, Shopify can get me up in an hour, you know, and they do a pretty good job at it. And so, it becomes, well, what else do you want to do? And fortunately enough for us, they always want more, just a little more.
\n\n[laughter]
\n\nMATT: And if you want to integrate with Shopify, that's another story.
\n\nWILL: Sure. Absolutely. But, like, if you wanted to integrate with Shopify, well, that's something, you know, new that Shopify doesn't do. And then, we're into custom software land, and I'm making my [inaudible 13:37] payment this month.
\n\nTAD: That does touch on one of the myths I was thinking about earlier today that a lot of times we parallel software development with things like building a dam, or construction, or things like that, and those things get finished, right? They complete the project, and then they walk away and move on to another project. And software, just because it got released, doesn't mean that you're done.
\n\nWILL: Oh yeah.
\n\nMATT: Never done.
\n\nWILL: Yeah, yeah. I think that's a myth.
\n\nEDDY: But when you --
\n\nWILL: So, the software is released, right? It's done [laughter]. Like, it's –-
\n\nMATT: [crosstalk 14:16] that you're finished, right?
\n\nEDDY: Sure, but you got to have people to go back and maintain whatever it is you built, whether it's software, whether it's a building, a car; it doesn't matter. There is a level of maintenance that still is required.
\n\nTAD: Even saying built makes it sound completed or finished.
\n\nMIKE: Yeah, and to take that further, some software products that we use were created for some utterly different purpose. Didn't Slack come out of, like, an internal messaging video game or something?
\n\nWILL: Some, like, in-game chat or something. Or was it just inside the company?
\n\nMIKE: I think it was just inside the company. So, they went to build a video game, and they ended up building a business messaging platform. Like, when we say build and release, like, yeah, I went to build a video game, and I built business software. And if you were going to build a bridge, you say, "I went to build a bridge, but I actually built a skyscraper with an airport on top." It doesn't work that way, but we have to do that all the time.
\n\nThink about that planning that was brought up before. Yeah, that planning, that cost still has to happen. But recognizing that we have to do these iterations, we still do the planning, but we do it on a smaller loop. We don't spend two years doing it upfront because we know that work is going to be thrown away, right? But we still have to do the work. It's just done in a smaller loop. So, you're spreading it out over the two years rather than doing it upfront.
\n\nYou still have to have that feedback, and there's still the work involved. There's still the job of communicating, figuring out where we are now and where we go next, and that never goes away. Whether it's upfront or whether it's later, it's still there. And if you try to pretend it's not there, you'll get in trouble quick, I don't know.
\n\nAnd that brings me to another myth. I pointed...it's xkcd number 2030, two zero, three zero. I think about this all the time. It's about voting software, which is kind of irrelevant. There's a line from it where the character says, "I don't know quite how to put this, but our entire field is bad at what we do. And if you rely on us [laughter], everyone will die." And if there's one myth I see about software, you expect that people just know what they're doing. No, we don't [chuckles]. We don't know what we're doing. We don't even know what we're building.
\n\nWe're building a video game that's going to end up business software, right? And that's not even necessarily a bad thing. We're building something out, and then we'll have something of value and see if we can use it. You know, it's this weird product that's kind of, like, other things and kind of unlike, I say, other things in that it's flexible, and sometimes it meets different needs. And it means that it's kind of hard to talk about, kind of hard to deal with. And we make a lot of foolish mistakes.
\n\nI've seen this with new developers, particularly people who change career later in life. They come in and they think that we all know exactly what we're doing, and it takes a while to be disillusioned. You got to kind of break that early and say, "It may look like we know what we're doing, but a lot of our job, maybe not most, but a good portion of our job is trying to figure out what we're doing. We're researching it as we go. We don't know how to use the tools. We don't even know what tools we're using, and we don't understand the requirements. So, a big portion of our job is figuring all that stuff out so that we can get something that works out in the end."
\n\nTAD: And a lot of times, you can't know what is needed, and what you need to do, and what the requirements are until you actually jump in and start poking around and doing the coding, doing the research, doing the things, getting both hands into the project. And you're like, oh, now I'm starting to see what shape this needs to take.
\n\nWILL: I mean, that ties into something that Eddy mentioned in passing, and it's a myth that I think...let me see how to put it. So, what Eddy was saying was, like, stress management is, like, most of what we do. And I think the myth of...and, I mean, I agree with that, and I think I'd maybe, like, broaden it out to say, like, I think people think of software development as this intellectual exercise. And there are sort of fairly specialized slivers of it that can be that. But by and large, you have to be smart enough and willing to sort of, like, bulldoze your way through thinking about the problems, thinking about the requirements, thinking about the legacy source code and how it works, thinking about, like, you know, how you do the stuff.
\n\nI mean, if you even look at, like, sort of, like, these programming puzzles that some people like for interviews, right? LeetCode medium, right? It's far in excess of anything that we actually have to do on an intellectual problem-solving level. What we need to do is maintain, like, a sort of, like, emotional equilibrium and focus on this fairly mundane, ditch digging, systems integration, team collaboration, requirement, negotiation, source of problems. Like, that's what will make you...
\n\nLike, if you're, you know, slightly above average intelligence but you have exceptional drive and emotional equilibrium, you know what I mean? Then you're going to be a very successful programmer. But, like, if you have exceptional intelligence and, like, you're a little bit squirrely in terms of, like, just grinding through, like, the necessarily frustrating tedium of, like, professional software development within a business organization, you're going to have a very difficult time, you know what I mean?
\n\nTAD: Yeah, and I think there's a myth that all software is kind of the same and that the skills needed are kind of the same. For example, I hear a lot of people ask, "Oh, are you really good at math? You really need to be good at math for software development". And then, I have to say something like, "Well, yes, if you're writing software for a nuclear collider, then you're going to need a lot of math. But if you're a front-end developer wanting to make some really cool interactive thing, maybe you need to know a little bit more design, and you don't really need that much math." Or the example earlier, set up a blog. I don't think you need any math to set up a blog probably, right? But those are all software development.
\n\nMATT: Yeah. And maybe this is just me, but I think the people who are just naturally good at math make good software engineers, just that mindset and the way they do things. They may not make the best front-end people, but there's a place for them, right? I think a myth also could be that, hey, I should just switch over to software engineering because the pay is great. I've seen a lot of people make that mistake. It's not for everybody.
\n\nWILL: They're having their day right now. I think there's a lot of people who came in for the bag, you know what I mean? And now we're in tech winter and, like, those doctor money FAANG jobs are a little short on the ground. And so, it's just like, "Would you only do this for a paltry $120,000 a year like a peasant?"
\n\nMATT: [laughs].
\n\nWILL: Like, "Whoa, whoa, whoa, whoa. I'm going to go back to finance," or whatever, right? And those kind of people. And then, you know, you have to wake up every day and want to do it, you know what I mean? I mean, just because, like...I'm pretty good at programming, but every project, you know, like, I got to wrestle the pig every time. It's a brand-new pig, and you're going to have to get in the mud every time. Every time. It doesn't get easier. You just get, I don't know, stronger, you know?
\n\nI was having a conversation with somebody who was talking about like, you know, like, needing to hire somebody and the difficulties associated with hiring people and how you'll have these people who, they'll go in, and they'll crush their interview. Like, they'll do really good on these algorithmic problems, you know. And then, you'll take them into the actual workplace where they have to go out and, like, you know, do the actual nitty-gritty nuts and bolts jobs. And they'll struggle or, like, they'll do good for a while. And then, sort of like the morale will fall off, and they'll struggle. And, you know, and, like, you'll have smart people who just can't maintain the focus of, like, staying after it, you know. And then, they will be bad because it's a nonstop grind and, like, yeah, it's tough.
\n\nTAD: I've heard it compared to a treadmill.
\n\nMATT: That's one of the reasons, Will --
\n\nTAD: If you enjoy the exercise, then a treadmill is not bad. But if you're constantly learning and you're constantly working on things, maybe you're frustrated some of the days, right? Not everyone enjoys exercising on a treadmill.
\n\nMATT: That's one of the reasons I don't ask the mapping of matrices and things like that in interviews. I just don't. I don't ask really computer sciencey questions because that isn't the real world most of the time.
\n\nEDDY: Okay, but the real question is if someone came up to you from your family and said, "Can you fix my computer?" Can you? Can you fix that computer?
\n\nMATT: Ugh. I hate that. That is the worst question ever, Eddy.
\n\nEDDY: [laughs]
\n\nTAD: Yes, that's why I have a master's degree.
\n\nEDDY: [laughs]
\n\nMATT: Sometimes. I mean, you know, sure, we know that stuff, but it's not what we do.
\n\nTAD: Yeah. I mean, I can Google as well as the next person.
\n\nWILL: I can Google much, much, much better than the next person.
\n\nTAD: Actually, that's true.
\n\nMATT: Which is what we spend a lot of our time doing, right?
\n\nMIKE: That's one of the most critical development skills is Googling.
\n\nTAD: Finding the right information, right?
\n\nMIKE: If you think that managing hardware and setting up something with, like, the TV is what we're good at, then you should see any engineering meeting trying to figure out the presentation, like, the hardware in the meeting room [laughs], just trying to get a meeting going. It never works.
\n\nMATT: Let's not even get started on spreadsheets.
\n\nWILL: I'm terrible at spreadsheets. I don't know how to do them. Like, as soon as...whenever I've had a spreadsheet, like, challenge, like, I Google it. I learn everything I need to know for the next, like, 15 minutes of work, and then immediately cash dump it. I'm just like, pfft, flush. That's out. I'm out.
\n\nMATT: I do the same thing.
\n\nWILL: Pivot table, whatever. I know the word pivot table is usually the answer to my problem.
\n\nTAD: [laughs]
\n\nWILL: And then, if you put a gun to my head and ask me to write up a pivot table in Excel, you better have a bucket and a mop.
\n\nMIKE: You know, you said something about we're focusing on the, you know, the grind and the treadmill. I read a quote from a bikepacking racer. I don't remember which guy it was, but I read it recently. And he said that that kind of racing, like endurance racing, and it could also apply to marathons or ultra runners, that kind of thing, he said that it's mostly about fatigue management. And you think, oh, you know, it's about building strength. And he's like, "No, it's, like, about eating the right food and managing your sleep and not pushing yourself too hard."
\n\nNone of those are, like, things that you might necessarily think about have to do with racing. Like, eating? Racing? What? No, it's about managing your body and your equipment so that it can keep going. And that sustainability, you know, trying to think about that metaphor, that sustainability really is, like, a central aspect of our craft. And you can get off, right? You can get unsustainable, and that puts you in a bad spot.
\n\nMATT: You end up in burnout. Be good at compartmentalizing, right? I know you and I have talked about that before, Mike.
\n\nWILL: It's legitimately tough to do. I think there's a lot of places that are in...I will call them...I mean, honestly, I'd say, like, go at doom loop, you know what I mean? And I was talking about this with Mike a little bit, like, before we got on. It's one of the things that I've been seeing because, like, you know, we're in tech winter now, right? So, things are rough. You know, layoffs are happening, you know what I mean? Like, teams are squeezed pretty tight. I think it's across the industry. Even if you made it, even if you're still working, like, you still have, like, the reaper's hand on your shoulder being like, "How are the tickets going?"
\n\n[laughter]
\n\nAnd so, you have these situations where, like, you know, you have a business downturn. You have business pressure. And then, they'll have layoffs, you know what I mean? So, like, that impacts morale. You lose head count. Maybe you don't have nine women to make the baby in a month. Maybe you only have eight. And then, that impacts productivity, and then...you know what I mean?
\n\nAnd a lot of it really is sort of, like, it impacts people's emotional equilibrium, their feelings about their work, you know what I mean? Like, I think it's very understated, you know because it all exists in your brain. And without that focus, that willingness to focus, that willingness to, like, really concentrate, things become extremely tenuous. And you get into the burnout mode, you know.
\n\nBut you can't stop peddling because, you know, you got business pressure. And, like, you got to make your deliverables. You got to make...you have to make money so that the business can give it to you. And you find yourself with these doom loops, these ugly, ugly, ugly spirals. And I see a lot of that in a lot of places when I talk to folks in the business right now.
\n\nMIKE: Which comes back to the same thing, that tenacity [laughs] and fatigue management is going to be the thing that gets you through that winter. My grandfather lived through World War II in Norway. And his family survived through the winter on a barrel of pickled herring [laughter]. [inaudible 27:54] through the winter on a barrel of pickled herring [laughs] is how you get through the winter. Recognizing that it may not always be very nice. There probably will be spring on the other end.
\n\nWILL: Oh yeah, and it always will be. Nobody's throwing their computers at the dumpster. I don't see it. It's like people would just be like, "Ah, the internet. We're over it. We're done [laughter]," right?
\n\nMATT: At least in my experience, there's always a light at the end of the tunnel. You're going to experience burnout. It happens to everyone. Like Mike's grandfather, you just power through it, and you do what you have to do to survive. And, eventually, you know, this can be the greatest job in the world. It can also be the hardest job in the world. And you're going to experience both of those.
\n\nWILL: It depends on the day [laughs]. It depends on the day. Sometimes, it depends on the hour. I mean, I will say that, like, that grind...I don't remember where I heard this, but, like, tenure of a software developer is they usually make it, on average, to about 36. That's not a lot better than playing in the NBA.
\n\n[laughter]
\n\nMIKE: Well, that's interesting.
\n\nMATT: That is very interesting.
\n\nWILL: And I believe that number could be out of date, at the very least. I remember it very clearly that I definitely read that, and it could be, you know, maybe a shaky study. But, I mean, I remember the number because it struck me so viscerally. I'm like, oh my God. Like, if you look at somebody like, I don't know, like me, I'm 44, right? If I was a physician, an MD, I'd be, like, just entering into my best years, entering it. It's like, well, you know, he's still a little green, but he's starting to get his feet under him. You know, I think he's ready to go.
\n\nBut, like, as a software developer, it's just like, you know, people looking at you like Old Yeller, you know what I mean? [laughter] Where it's like, you're walking into the office with a limp, you know what I mean? Like, let's take you back behind the shed.
\n\nMATT: Well, just with this group here, we're doing pretty good with those odds, right?
\n\nMIKE: Yeah [laughs]. I'm thinking people I've known who have gotten past that or maybe the people who did have the ability to keep going. I've worked with some experienced people. I do work with some experienced people that I find their experience to be indispensable. I don't know how they could do their job, or I could do my job without being able to rely on those years of experience that they wouldn't have had at 36.
\n\nWILL: I've found that older developers tend to be pretty bimodal, you know what I mean? Like, there's not a lot of, like, developers, you know, like, north of 40 that are in the middle. Like, it's not really a bell curve. It's kind of like you're either --
\n\nMIKE: [laughs]
\n\nWILL: Awful or you're fantastic. I'm trying really hard to head towards the light because I have met some awful ones, some truly, truly bad ones where it's just like, you gave up several years ago.
\n\nMIKE: So, that can happen when you step off the treadmill for a while [laughs].
\n\nTAD: It's something that you got to keep working on all the time because technology keeps advancing, and you got to keep up with the advancements, right? Not necessarily all of it everywhere, but at least the stuff that's relevant to what you're working on.
\n\nMATT: We're all going to be prompt engineers before you know it.
\n\nWILL: All ready. All day.
\n\nMIKE: [laughs]
\n\nWILL: I think that's where things are going. I think that AI tools I think they are going to be a fantastic force multiplier, but they're not taking anybody's...well, I wanted to say they're not going to take anybody's jobs, right? But, like, if they double your productivity, you know, the head count's going to go down by 20% probably.
\n\nMIKE: There was an agricultural revolution back, what, in the 1800s? And that doesn't mean we don't have farmers. We still have farmers. But they generally operate at a much larger scale, and they're a much smaller percentage of the population. And interestingly, new fields of labor opened up because everybody wasn't farming anymore. I don't think our jobs are going away. Like, there's still people developing software.
\n\nAnd it took a while, you know, but agriculture still exists. It's an important industry. And, you know, there are farmers. Farmers exist, but the way they operate is different. And there's new industries that didn't exist, like I was saying. You know, they've enabled different ways of working. And so, a lot of people who would have been farmers are now doing stuff that's adjacent to that or maybe totally different to that because it's enabled by the farmers being more effective.
\n\nI think we'll have similar kinds of transitions that are a little hard to think about. You couldn't have explained a software developer to a farmer back in 1830. Conceptually, that work didn't really exist, and we couldn't even conceive of it. But I think that we'll have that similar sort of transition where, yeah, there'll still be people developing software, but it'll be a different format. And the jobs people have it might not be prompt engineer. It's going to be something that is going to be kind of incomprehensible, I imagine, to us right now. But it would make sense if you saw the evolution over time.
\n\nTAD: But I think it's kind of a different beast, right? Because I don't know of any organization that's like, "Oh, you guys have doubled your productivity? Oh, well, we're going to keep the same number of feature requirements that we had," right? They're like, "Oh, you've doubled your productivity? Sweet. We can, like, have twice as many features as we wanted before," right?
\n\nWell, I haven't experienced it yet where they've run out of ideas or new software projects or things like that, where they're just like, "Oh, well, we're kind of running low on places to spread our software or new places..." you know, it's like...because I imagine, like, even if we suddenly, like, 10x our productivity overnight, they'd be like, "Oh, sweet, we're going to move into, like, more countries than we were planning," or "We're going to have more features per year than we were planning."
\n\nWILL: And I'd also say, like, even more so that because of the nonlinear increase in complexity as software scales, right?
\n\nTAD: Yeah.
\n\nWILL: Let's say everybody doubles developer productivity, which is, like, a pretty bold statement, but, like, attainable, attainable. But that's probably the top edge of attainable, in my view, with, like, the AI, like, stuff. That's, like, 20% more features because, like, it isn't linear, you know what I mean? 20% more features. Because if you have 20% more stuff, like, I mean, so, within Acima, I mean, think about, like, it would be maybe one other big initiative, you know what I mean? You know what I mean? Like, you'd add one more team feature thing, right? I don't know how many teams you guys have now.
\n\nMIKE: I think you're onto something really important there. We talked about the planning and the non-coding aspects of the job. The AI stuff really helps mostly with the coding aspect, right? Does it help with getting requirements from stakeholders? Probably not. If 50% of the job is coding and you completely eliminate that [inaudible 34:59]
\n\nWILL: And the style, right?
\n\nMIKE: 100% productivity will increase in coding, right? Like, it all goes away. You only get to work on twice as many things --
\n\nWILL: Absolutely, absolutely. So, you know, honestly, like, I've been really having a tremendous amount of fun with it just because, like, generally speaking, I know what I want done, and I can express it in a reasonably concise, understandable way. I just might not know, like, all its syntax, you know. And so, like, that has just been, like, cleared from my past. It is an absolute delight, as far as I'm concerned, because a lot of the, like, I just [inaudible 35:37] BS ticki tack jobs are just, like, I have an assistant, you know, with a broom, you know what I mean? Like, I could build a house, and I have a helper handing me boards and, like, doing the sweep up for me. I'm like, ah, this is...yes, all day. I love it.
\n\nTAD: Yeah. I think that's a great place to kind of stop. So, thank you, everybody, for participating. Thank you for all of your comments.
","summary":"","date_published":"2024-05-22T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/52150379-4e98-4bd3-9254-0550ed96fcf3.mp3","mime_type":"audio/mpeg","size_in_bytes":21917036,"duration_in_seconds":2173}]},{"id":"751b7993-803b-4e25-bff3-bb1a0e9ace97","title":"Episode 45: Promoting Innovation and Collaboration","url":"https://acima-development.fireside.fm/45","content_text":"The panelists discuss innovation and collaboration, particularly in engineering and beyond. Mike kicks off with a personal anecdote about his musical education, highlighting the limitations of conventional music lessons that focus heavily on theory and reading music, rather than fostering creativity and improvisation. This experience ties into his broader theme of innovation, suggesting that traditional educational methods might stifle creativity, which is essential for genuine innovation.\n\nThe conversation shifts to practical applications of fostering innovation within organizations. Mike uses the analogy of his own gardening experience, where allowing a garden to overgrow led to unexpected and beautiful variations in his plants. This metaphor extends to the workplace, where Mike argues that allowing some processes to be unstructured can lead to innovative outcomes. He stresses the importance of making space for collaboration and letting ideas \"go to seed,\" which can spur development and bring forth new, valuable changes that wouldn't occur in overly controlled environments.\n\nAs the discussion unfolds, Will and other guests explore different aspects of innovation in the workplace, including the potential pitfalls of too much freedom or too much control. They debate the merits and drawbacks of Google's famed 20% time, where employees are allowed to spend one-fifth of their work hours on projects they're passionate about. This leads to a broader reflection on how companies can balance structured and unstructured time to foster an environment where innovation thrives without sacrificing operational efficiency. The episode concludes with a consensus that while not all innovative efforts will succeed, the potential for groundbreaking ideas makes the endeavor worthwhile.\n\nTranscript:\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm going to be hosting again today. With us, we've got Justin, and Ramses, Eddy, and Will. Will, I think, is joining us for the first time. Welcome, Will. \n\nWILL: Happy to be here. \n\nMIKE: Happy to have you here. As usual, I'm going to give a lead here and kick off our meeting. I'm going to start with actually two stories today, and both of these are outside engineering. And I've given several music references. I'm going to do another one today [laughs]. It's a deep well to draw on. \n\nWhen I was a kid, my mom signed me up for piano lessons [chuckles], and I was nervous about it. I thought...like, everybody else talked about it being dreadfully boring, and I thought it would be as well. Actually, I enjoyed it. I loved it. I took lessons for a number of years, nine years, I think. \n\nAnd, in those nine years of lessons, I think I had zero lessons on improvisation or creativity. And I think I'm nowhere near unique in that respect. I think most people who have music lessons learn how to read music. And honestly, I think that's kind of a travesty. I've read from a mathematician, so there's something worth looking up. It's A Mathematician's Lament. And he actually gives music as an example. He said, \"Imagine that music was taught by everybody learning to read music, but you never listened to it,\" because he took that idea to its logical extreme.\n\nYou learned how to write notes, do all this notation, study chord structure, and maybe when you got to, you know, like, your teens or the really advanced students would be able to start listening to music. You know, in a world like that, of course, everybody would hate music. But music is often taught, not quite so badly, but kind of because we learn to read it, but not to write it. It's not given equal weight, and I think that's really unfortunate. Because if you don't give time for somebody to learn to create something on their own, they'll never learn. How could they? If there's not time, there's just no way. \n\nWhen I was in high school, I took a guitar class [chuckles] and learned to play guitar. And I loved it. And suddenly, for the first time, music theory made sense. I looked at the guitar. I was like, \"Oh, there's this circle of fifths thing, and, you know, let's see how this all works.\" \n\nJUSTIN: [laughs]\n\nMIKE: Then I started, you know, playing chords and chord progressions, and it was great. Later, I got a bass, and it was kind of the opposite of piano. Piano, you have all this polyphony and the bass; you just got one note you're plucking away at, and I loved it. You're thinking of, you know, I was able to improvise, think about just kind of the pure baseline there.\n\nAnd I've had many experiences that I've really enjoyed, like laying down a bass line. Somebody's playing, or somebody played something, and I try to come up with a bass line to it, or, you know, I've kind of come back to piano in the last few years as well. I enjoy making music with other people, and I like creating music. And I probably do more creative stuff than reading music, to be honest. I flipped the tables because I had time to do it, and I was given a structure that allowed me to do it. And it made all the difference, and it allowed me to enjoy music in a way that I wasn't able to before. \n\nOne more story. So, I want to do something different from music. We've done lots of music references, so I'm going to do something very outside of music. I've got a garden behind my house. I like greens. I'm a fan of greens, but I'm particularly fond of red Russian kale. But I'm actually not going to talk about red Russian kale. I'm going to talk about a different green, which is mustard greens. I've got a variety called Ruby Giant. It grows big, beautiful leaves that are red on one side and green on the other side. \n\nLast year, I let some of those go to seed, and when it gets hot, they do that. They go to seed, and they leave seed all over. And then I let the seeds grow, which looked kind of weedy, to be honest [laughs]. It was kind of messy in that area of my garden, but I was curious what would happen. And in the fall, I got a lot of mustard that grew up. And one of the mustard plants that came up was pure red. Usually, like I said, they're red, kind of red mottled on one side, and the other side, it was green. But this one was red, just deep burgundy all the way through. It was an amazingly beautiful plant, tasty, too [laughs]. That's some of it. I actually pickled some mustard greens. And I hope that it comes up again this year. \n\nThe point that I'm getting to is, if I had not let the garden get a little weedy, you know, get a little overgrown there and go to seed, I never would have had that second generation. I never would have had that innovation in my garden where I had something that I never had before. If I just kept everything nice and tidy, that would have been it. I would have had that first generation. I never would have had something new. I gave it space. If I had not given the space for something to be a little messy and go its own way for a while, then I never would have had something that was genuinely different from what I had before. \n\nThere's my two-lead story. Today, we are talking, and I don't know if I've mentioned it before, fostering innovation and collaboration among engineers. But I haven't talked about engineering yet, but these stories speak to me about what it takes to promote innovation or collaboration. I guess they're somewhat related. If you want collaboration, I think you have to make space for it. And you can't enforce it. You have to let it go to seed a little bit. So, there's my take. Thoughts? What do y'all think? \n\nWILL: I'm kind of curious, like, what do you mean by, like, sort of innovation? In that, for most of the work that we do, innovation is really more customer-facing than technical-facing. You know, like, there are companies and organizations and stuff like that that are actually sort of cutting new trails technically. But by and large, I think the overwhelming majority of innovation is, like, delivering things to customers. And we're not necessarily, like, writing our own database, or writing our own operating system, if we're doing a new LLM based on sort of, like, existing open-source work.\n\nAnd so, when I think of innovation within engineering teams, generally speaking, it comes in one or two flavors, one of which is a little bit of an anti-pattern and one of which I think is really, really healthy and good. Like, one of them is honestly, I mean, it's sort of, like, engineers gone wild because you've got a bunch of smart people who are maybe underutilized, you know, they're kind of chewing the walls a little bit.\n\nAnd so, you'll find just shiny object syndrome, you know, the sort of, like, JavaScript flavor of the moment, you know, just because people are bored. People are bored at work. They want to play with shiny, new toys. And, you know, you'll find yourself in a situation where, like, they're reinventing things that aren't really generating a problem. And that's a little bit of an anti-pattern, but that's the evil twin. \n\nThe really good part about it is when you have had a nagging, constant pain in an engineering organization and figuring out a solution to it. And so, you need to be, I think, disciplined, you know what I mean? Like, are you solving a real problem? Is this thing better, or is it just new? There's actually technical innovation that is sort of, like, customer-focused and facing, which, you know, I love but isn't necessarily an engineering question. I hate to buy into the grossly incorrect notion that only product could ever come up with technical customer-facing innovation.\n\nMIKE: [laughs]\n\nWILL: I think that's incorrect, borderline offensive. But, like, within the context of a sort of engineering organization, that's where I'm coming at it from. \n\nMIKE: I've got a couple of examples I can think of just off the bat. We have taken times in the past that I think we still got on the calendar, what we've called 5% time. It's just every other week in the afternoon, we have this space to collaborate on something, a time to scratch that itch to work on something together. \n\nAnd a couple of years ago, maybe three years ago [chuckles], sometime in the last few years, some of us chose to take that time and extract an important service out of the main application we were working in. And that service became actually kind of critical to the company because it's our merchant API, and it allows them to get information. I don't want to go too much into technical details about the company. We were able to extract this application. It ended up being a really valuable extraction and would never have happened. It wouldn't have had any legs at all unless we had just taken that time to pull that out.\n\nMore recently, we've done something similar. We had a DevDay project, worked on something that we wanted to get done. We took a, basically, it was a message queue [laughs] that some agents were using, and we pulled it out of the database, put it into Redis to make it perform better. And it was really volatile data anyway. And we put it over there, made it into production. And it's how it's running now. And it's been working [laughs], right? \n\nAnd, again, it wouldn't have gone forward unless we'd taken that opportunity to schedule some time and say, \"Hey, go do an experiment.\" We didn't finish the experiment on that DevDay, but it gave us something. We actually ended up scheduling [inaudible 08:35] engineering organization because it solved several problems, removed some old code that we needed to get rid of, and an aging library, you know, solved a problem. \n\nAnd I think to your point, Will, if you just set a bunch of people free and said, \"Hey, work from wherever you want to for as long as you want to,\" and there are some organizations that do that, I think, you end up with a lot of ivory towers that don't accomplish much [laughs]. You know, people build this amazing, perfect software that doesn't solve any problems. But if you box it in a little bit, and I've seen this a lot of times, you box in creativity a little bit, it actually tends to grow. If you restrict the number of options, then people have something to work with. You know, if you've got a riff to play against, well, now you've limited the options, so you can make some music on top of that. It works a lot better. \n\nEDDY: You know, Mike, you mentioned 5% time, and I'm pretty sure that's based off of Google's 20% time. It's just fractioned off a little bit. I want to go on record in saying if I remember correctly, I think some of their best products that Google uses right now on their subscription base was because of their 20% time that they fostered. I want to say some of those were, like, Gmail, for example, and, like, I don't know.\n\nMIKE: I think Gmail did come from that. Yeah. \n\nEDDY: Yeah, and, like, Google Maps, I think. It's been a while since I read that list, so I don't have an exhaustive list. But that's just a prime example of if you foster innovation in your team, you know, you get some really solid projects. \n\nJUSTIN: I think part of that is people who are in charge have the ability to recognize when something has legs as well, you know, a little bit of guidance there from management where they can recognize, hey, this project has a potential to solve a problem. Let's gently encourage people to continue working on it. \n\nAnd then, also, the flip side of that is maybe those same people look at stuff that other people are working on and say, \"Hey, you know, maybe you should be working on something else,\" or helping them recognize, \"Oh, is this a dead end,\" or \"Is this something that you want to keep on going on?\" and giving useful feedback that way. You don't want to, like, nip things in the bud necessarily, but at the same time, I think giving useful feedback and being able to receive useful feedback I think is key to being successful with these side projects that become big things, big successes. \n\nWILL: I think if you're doing 5% time, then you sort of, I mean, I don't know, maybe Mike could, like, maybe this isn't how it went down, but I feel like you guys found something good in 5% time and exactly like that, like, management, like, saw it. And they're like, \"Oh, this is kind of cool. Okay. You know, like, I'm going to feed this a little bit. I'm going to get this onto some sprints so that it could actually, like, go.\" \n\nI don't know, I personally favor, like, this 20% time because I don't think 5% is enough to ship a product, you know what I mean? If you actually want to ship a thing that somebody could use, 5% time ain't going to get it. And, like, the thing about, like, sort of, like, management is management has their own priorities, and management gets their say. They get their time. It's not like management is doing a bad thing, but I mean, the idea of unstructured creative time is stuff that isn't on management's radar.\n\nAnd I think, I mean, I'll say it directly, like, I think management is not as good at innovation as they think they are. It's not that they're bad necessarily, but, like, they don't have more good ideas than the whole of the organization, you know what I mean? Like, really tying people loose will come up with stuff. I mean, and, like, hear me, you have to be, I suppose, like, maybe more specifically what I'd say is that sort of, like, wide open 20% time, you're going to have some duds. You're going to have a lot of duds. You're going to have a lot of stupid, boneheaded, dumb go nowhere ideas. There's going to be some dumb stuff that comes out of that unstructured time.\n\nAnd management is a little bit...I think they're naturally resistant to just transparently stupid ideas. But you're also going to take stuff that's a good idea, but it's, you know what I mean, a little wild for, like, you know what I mean? Like, you'll never get it into a sprint plan unless it's done, and it's like, oh, wow, this is cool, like, you know what I mean? The Google projects are a classic example of that. They did a lot of stuff that was really, really big, but they also stopped doing it because nothing makes as much money as ads in search. The manager was like, \"This is cool.\" \n\nEverybody loves Google Reader, right? Beloved dead product. Or another one, I mean, like, and this is maybe the other side of the coin, Google Voice, right? Google Voice, right? What a stupid idea. And it never made any money, and it never did anything. Oh, wait, here it is, 2023. We have this absolutely gargantuan corpus of voice data that we have been snarfing up for literally a decade. Man, our LLM would love that, wouldn't it? [laughter] You know, I mean [inaudible 13:37], \n\nEDDY: You just suddenly stumbled upon having a full database of the stuff that you would kill to have, and you have it by accident. \n\n[laughter]\n\nWILL: Yeah. Oops! You know what I mean? And that's kind of the thing, you know, I mean, it's, you know, can you afford it? You know, I mean, there's good and bad points. But, I mean, like, the management control I think it's just a flavor, you know, like, somebody likes chocolate, somebody likes vanilla, and it is all heavily directed by business constraints. Google prints money. They print more money than anyone has ever seen, ever. And it just keeps on coming. So, they had opportunities to do that that people with tighter budgets maybe don't. \n\nEDDY: You know, what I feel like companies typically don't do is they don't reach out to people who are out in the field, you know, doing a bunch of that customer interaction. Let me give you an example. When I go into a restaurant that I haven't been to before, my general go-to rule of thumb is talk to the individual who is in the front-facing. And I'll ask, \"Hey, what is your favorite dish from your menu?\" They're probably going to have a more concise answer than someone who's up in management because they're consuming the product at a different level. \n\nBut not only that, let me take it a bit further. There are individuals who I ask, \"What do you do differently to the products that you sell that make it taste better?\" Do that sometime. I promise you, nine times out of 10, they're going to give you a different menu item that's not publicly available. But let me tell you what, it tastes so much better because that's not something that they typically offer. If you're trying to promote innovation, reaching out to the people who have the ability to play around with your product is probably the best thing. \n\nTo add to that, when I started at Acima a couple of years ago, part of the onboarding process was speaking to people and agents who are talking on the phone, who actively use the product that we develop on a daily basis, and I got to speak with them. And I'm like, \"Hey, what would you like the app to do, something that we haven't considered?\" The amount of input that they have is insane. So, I feel like there's some lost potential there that we could harness or any company can harness. \n\nMIKE: Absolutely. You know, I mentioned you have to have an untidy corner in your garden if you want something new, and not everybody's going to like that. It's going to make the neighbors uncomfortable [laughs]. It might make some people in your own home uncomfortable. They're like, \"Well, no. Why don't you just level that out?\" I just want to see some bare soil.\" But that's kind of the price you have to pay. You have to have some of those wild ideas, some of the dumb ideas, some of the things that aren't going to work because that's what innovation looks like. \n\nYou know, to Will's point, management is not uniquely qualified to have smart ideas. What good management does, and this also builds on what Eddy was saying, is that they look for those ideas. It's not, hey, the idea was mine; rather, I found a good idea that somebody had, and I'm going to promote that because it's a great idea.\n\nJUSTIN: I think that's one of the best talents that good leaders have is the ability to recognize good ideas. If you look at Steve Jobs, I mean, he's acknowledged for his designs and everything, but he also has the ability to recognize, you know, hey, what is a good idea? What all fits together? What could fit our company? Or what do people potentially want? And it's not all just him, of course, but it's his ability to recognize that. \n\nAnd Apple has a way of doing things that makes them one of the top companies in the world. And so, if you look at that, it's like, obviously, as a company, they're generating great ideas. They probably have a dozen misses for every hit they have. And so, being able to have a place where you can have a dozen misses and not be fired, and being able to do what you want to do to encourage that, I think, is key. Having a wild garden or a place where growth is encouraged. \n\nMIKE: Yeah. You mentioned Steve Jobs. One thing I've always been struck by is, as a kid in the United States, a lot of times we hear about Thomas Edison, this great inventor. And you picture some guy in a lab, just some guy in a lab. But if you actually read about his lab, he had, like, a hundred employees [laughs]. His job was not sitting there at a bench inventing stuff. His job was to lead a team of engineers. \n\nAnd what made them successful wasn't one guy being brilliant. It was a team of engineers being given the space to work on good things and then filtering down the ideas and channeling them. It's a department effort with good leadership from the top that makes a difference. That guy's name's on it, but it really wasn't him who came up with most of the ideas. He just led a team. \n\nWILL: But, I mean, like, if I'm being honest with you, I mean, like, most of the corporate managers I know were not selected for their ability to innovate, you know what I mean? Like, how do you become a manager, right? Well, you know what I mean? You have, like, sort of technical expertise, and you have the ability to, like, sort of, like, organize a team. And a line-level manager is not really an innovator. That's not really the job, you know what I mean? Like, the job is to sort of, like, organize and implement somebody else's ideas. \n\nAnd how do you become, like, a mid-level manager? A mid-level manager is a line-level manager, and a senior manager is a good mid-level manager. And as you go through, like, successive generations, I mean, like, the original person, okay, that's like a Steve Jobs type, right? Which is why Apple went down the tubes pretty quick after the innovative person he left. And so, I mean, like, most corporate managers, being good at innovation is not how you get that job. \n\nSo, I'm [inaudible 19:21] for a very large retailer who shall remain nameless. But they have succession, successive generations of these sort of managers, you know what I mean? Who are implementers, you know what I mean? Generation after generation, after generation after generation of these guys, and they're not dumb guys. But, like, that job is not their job, and sort of, like, they've been evolutionarily selected, for, like, particular traits, and then they get to the VP level, and it's just like, okay, innovate. And it's just like, okay. [laughs] \n\nJUSTIN: So, what you're saying is we are selecting for the wrong thing at the manager level, or many companies are selecting for the wrong thing at the manager level. They should be selecting for innovation when they are instead selecting for the ability to manage a Jira project. \n\nWILL: Well, I mean, like, you need the ability to manage a Jira project and sort of, like, what that 20% time was, you know what I mean? Maybe the argument for it is an antidote for Jira itis implementation type stuff in that, like, okay, let a bunch of wild prototypes out and not sort of, like, curating them because you are a tastemaker, which you're not, you know what I mean? But, like, sort of, like, being humble and saying like, \"You know what? I don't know what's going to work. Let's just let a thousand flowers bloom. \n\nAnd when something goes, when we have a winner, when something hooks, even though it wasn't my idea, then I'll take it, and I'll do what I do, which is, like, get this thing over the line in a polished professional setting.\" Like, that's the counter, right? But it takes a certain level of, like, egoness and, like, a release of control, which is not necessarily how corporate hierarchical management works. \n\nEDDY: You also need a butt load of money to innovate and take that risk, too, right? So, it's not like anyone can really do that. \n\nJUSTIN: That's an interesting constraint. If you are in an environment where you are trying to squeeze every developer efficiency out, allocating 20% time for other stuff that you don't have a guarantee of return on, that's hard. \n\nMIKE: Two things, Will, you said. The 20% is the antidote for everything else. I think that's exactly right. It's the part you set aside that you don't control [laughs], and controlling the rest is actually really important. That 80% is critical to your business. You don't want that 20% to grow to 80% because then you go down the tubes pretty quick. You know, you need to keep that constraint, but you have to have that innovation.\n\nThere's a huge risk in being stagnant. In some ways, that's maybe the most risky thing. If you look at the most valuable companies from 20 years ago, it was like Exxon [laughs]; IBM may have been on there. You know, the companies that you don't really think about that much anymore. You know, there's all these tech companies today. And 20 years from now, it'll probably be another set. If you look a hundred years ago, you had train companies or the big oil companies, and they were huge. They looked like they were unstoppable. They were massive transportation company. But they quit thinking about themselves as a transportation company, started thinking of themselves as a train company because they've got all these trains. \n\nAnd once you start getting that line of thinking where you don't innovate against yourself, you become stagnant, and then an upstart comes and out-innovates you, and you lose your momentum. You have to have that innovation because that's also risky. It's risky to put all of your eggs into that, but it's also hugely risky not to innovate because you will eventually stagnate and die out. \n\nWILL: And I'd also say, like, I mean, a little bit of a false premise in that, like, you think, like, oh, well, we're going to invest 20% time in people coming up with their wild, crazy ideas. Okay. Well, I mean, that's a big risk. But it's also a risk, like, I'm working for a very large company, where bluntly, the innovation stuff is the decisions are made based on VP-level people who did not get their position through being an innovator. And they have vibes, and they have some vibes. \n\nAnd then, all the chips go to the middle of the table based on one individual who is...and I want to be very clear; they're smart people and hardworking, you know what I mean? Like, they're not bad people. Everybody that I've dealt with has been. Like, they've all been, like, solid folks. But, like, that's not their thing. They've never invented a product, ever, until they get to do it, and then all the chips go to the center of the table. \n\nAnd if their vibes are wrong, you know, then you're cooked, whereas, I mean, bluntly, if it's 20% time and everybody's just coming up with some wild idea, I will call a spade a spade. You have a much higher standard that that idea has to meet for somebody in management to pick it up and run with it. It's got to be a lot stronger than somebody just having a vibe. \n\nJUSTIN: Yeah, I got an interesting story about this. My friend works for Ford pretty high up in the finance department. Ford, a couple of years ago, decided that they were 100% all in on the electric. Then they came out with a couple of electric vehicles, most notably, the Ford F-150 Lightning, which came out to great fanfare, but turns out that the battery is just not there for what people use a truck for. So, all of a sudden, his decision to do this very innovative thing...because Ford is, like, 120 years old or 100 years old, right? \n\nAnd as CEO, he put all his chips in on this new electric drive train, which I think is awesome. I love electric cars. But, for Ford, their number one seller is the Ford F-150 truck, which is a standard truck that people love, and they love the ability that it gives them to, you know, a variety of things. But one of the main things is like, you know, you can go out and gas it up and keep on working. Whereas with the Ford F-150 electric truck, you can charge it overnight and try to find a charger somewhere else. But if you can't find a charger, you're high and dry, and you're in for an expensive tow. \n\nSo, he went in on innovation that perhaps was not ready yet, and he's probably going to lose his job over it, which he probably should, in some ways because that's the CEO. But it's just interesting because I think, yes, you need to recognize innovation and go for it, but maybe not bet the company on it [laughs]. \n\nEDDY: Well, fear of innovation is also what's going to put you in serious risk...\n\nJUSTIN: Yeah. \n\nEDDY: Right? Of bankruptcy. As an example, off the top of my head, and it's not a jab at this company, but it is a prime example. Blockbuster was amazing, right? Like, they were a striving company for years. Staple name, staple IP. Everyone knows the name. Even now, you could talk to someone, \"Hey, do you remember Blockbuster?\" \"Oh yeah. They were awesome, you know.\" They had the opportunity to buy Netflix at the time. And then, they passed up on that because they didn't believe that that was the future. And being scared of innovation it was a prime example of why they went out of business. So, there's definitely [chuckles] a balance with fostering innovation in your company. \n\nMIKE: Yeah. 80% of your company going into innovation is bad, and 0% of your [chuckles] company going into innovation is bad. That suggests that maybe there is somewhere in between that is good. \n\nWILL: Well, I sort of like 20%, and I like releasing the illusion of control. I like releasing the illusion of, like...the reason I like sort of, like, unrestricted 20% time is because you're not predicating your ability to continually successfully innovate based on the smart guy that I have designated. Me, the big boss with my big brain, have said, \"These four or five guys, these are the smart guys. I know best, and these guys are the people who are allowed to have ideas. And they will be smart guys and give me the correct ideas. Versus just sort of like, I don't know, we're going to try some stuff, and we're going to pick the winners, and we're going to ditch the losers, and we're going to see how things go.\n\nIt's the ego control, like, only I know best thing, which I think is endemic to top-down corporate hierarchy, and they will kill you deader than fried chicken. And I would also like to tip of the hat to Netflix because, like, Netflix, they're doing better than ever. They torched their business, remember? \n\nMIKE: Yeah, they did.\n\nWILL: Remember the DVDs? \n\nMIKE: They did [chuckles]. \n\nWILL: [inaudible 28:08] dollar company, and they're just like, \"Nah, we're done with that. This is stupid. This mail stuff is dumb, you know?\" They are sort of, like, this sort of counterexample to, like, you know, they had a really smart guy who really got it, and he had the right idea. He's just like, \"Nah, this is it.\" I mean, it's great as long as you have a Steve Jobs, and you can continue to have successive Steve Jobs. If you could guarantee that, you're going to do great. \n\nJUSTIN: It sounds like we have a great conclusion here that, you know, yes, there needs to be innovation and, you know, enable our engineers to kind of run with their ideas a certain percentage of time. But is there a way that you can make them more successful? Like, granted, you know, X number are going to be unsuccessful, right? You're going to have a lot of duds. But is there a way that you can help structure their projects that could make them more successful than not? What would you do? Would you encourage project planning, or maybe a deadline, or something, some sort of guardrails, or guides that could help them on those?\n\nWILL: I think you got to go the other way. I think people's natural inherent bias is fear of failure. I think that's baked into our DNA, our bones, who we are as human beings. Honestly, like, I think you have to encourage, like, wild, stupid failures. People don't want to...even if it's 20% time, it's like, it's cool. Fridays just do weird stuff. Nobody wants to go to their boss and say, like, \"You know, hey, what'd you do for the past year's worth of Fridays?\" It's like, \"I just wasted it all. It was all just stupid. It was all a complete loss.\" Like, think about even if it's like, don't worry, it's not going to affect your performance if you fail more, not succeed more, fail more. It's just the bias that we have to correct for as human beings is a fear of failure. \n\nMIKE: I think you're dead on, by the way [laughs]. I actually have...I'm sitting up where my kids do school. I've got a sign that says...I'm not sure I got it quite right, but I'm going to get close. \"Mistakes are proof you are trying.\" I want my kids to hear that every day. It's so important that they know mistakes are part of this. Mistakes are great. Please make a lot of mistakes because that means that you're doing the right thing. \n\nNow, I want you to pay attention enough that maybe you're not making mistakes that you knew better than. But I want you to be trying new things that you make mistakes on. If you're not trying things that are hard enough to make mistakes, that means that you're not really learning anything. \n\nJUSTIN: Well, maybe that's just the answer then. It's just, like, you go in and set the, I hate saying, set expectations, but you set the expectation of, hey, go out and try this. Go make a bunch of mistakes, and recognize that you aren't going to be perfect. And recognize that, hey, go out and collaborate with your teammates and share ideas maybe with each other. Go out and ask for help. Don't be afraid to share what you're working on. And even if it's a stupid idea, you know, chatting with other people maybe...actually, this may be a separate, you know, encouragement of, like, I don't know, some people may want to go off on their own and do stuff all by themselves, but maybe encourage people to collaborate at least. \n\nMIKE: So, encourage pairing, for example? You're going to be pairing with somebody, you know, X number of hours a week, N number of hours a week, whatever N is, three, two, I don't know. Give your [inaudible 31:27] \n\nJUSTIN: I'm just saying in terms of your 20% time.\n\nMIKE: Got it. Got it.\n\nJUSTIN: Because a lot of times, if you go out and you go try to solo something, that's good. Sometimes you just got to, like, research the heck out of something. But in order to get it to the next stage, you recognize that, hey, I need some help. Let's see if I can convince some other people to join my 20% time project. \n\nWILL: Exactly. I mean, we've been talking about a higher bar, right? The higher bar, like, your manager doesn't have to persuade you. They didn't even have to persuade you that they were your manager, somebody said. \n\nMIKE: [laughs].\n\nWILL: And I'm like, \"Well, I don't want to work for Mike.\" Like, \"Do you like getting your paycheck?\" \"Yeah.\" \"There you go.\"\n\nJUSTIN: [laughs].\n\nWILL: I mean, like, yeah, the fact that you have to persuade, I mean, that's extremely uncharitable of me, but it's incorrect. It's wholly incorrect to say that somebody just, like, made something up. Like, there's even in management meetings, like, you got to make your case. You do have to persuade people. It is necessary. \n\nMIKE: So, to summarize what we've come up with here, if you want to have innovation, you have to set aside some time for it. You have to make a space, and it has to be uncomfortable. That's not to say you put all your time and space for it. You budget a portion because you got to keep the lights on. You got to keep the business running. And doing most of your business should probably be the biggest part of your priority. But you better put a portion of that dedicated to doing these new things, most of which will not work out.\n\nJUSTIN: It's also worth noting that if you aren't encouraging the innovation inside your company, the smart people are going to go out and start their own company with whatever ideas they had, so...\n\nMIKE: I think that's exactly right. \n\nWILL: And I think, like, as I think about it a little bit more, like, there's a level of, like, it's like venture capital, right? There's a level of scale that you need in terms of, like, sort of, like, 20% time. Like, a company as big as Google, 20% time, it's like, okay, that's a lot of different ideas, a lot of smart people. They can do stuff. \n\nBut, I mean, like, if you say, like, \"Okay, 10% is going to win,\" and you've got, like, ten people, you're going to have to bet on having a smart guy. You can't afford a lot of losses. You need a certain scale to just sort of like, let's go! If it's let a thousand flowers bloom, okay, that's one thing, but if it's, like, let one flower bloom or five flowers bloom, you know what I mean? Like, it's going to be more difficult to be assured of a win, you know what I mean? Like, then you might have to put your eggs in one basket and, like, be more judicious about it. \n\nMIKE: That probably just comes down though to management [laughs], and there's a flip side. Like, managers actually can do a good job if they're good. I think that's a good stopping point. And this has been a great session. And I look forward to getting together again in the next episode of the Acima Development Podcast. ","content_html":"The panelists discuss innovation and collaboration, particularly in engineering and beyond. Mike kicks off with a personal anecdote about his musical education, highlighting the limitations of conventional music lessons that focus heavily on theory and reading music, rather than fostering creativity and improvisation. This experience ties into his broader theme of innovation, suggesting that traditional educational methods might stifle creativity, which is essential for genuine innovation.
\n\nThe conversation shifts to practical applications of fostering innovation within organizations. Mike uses the analogy of his own gardening experience, where allowing a garden to overgrow led to unexpected and beautiful variations in his plants. This metaphor extends to the workplace, where Mike argues that allowing some processes to be unstructured can lead to innovative outcomes. He stresses the importance of making space for collaboration and letting ideas "go to seed," which can spur development and bring forth new, valuable changes that wouldn't occur in overly controlled environments.
\n\nAs the discussion unfolds, Will and other guests explore different aspects of innovation in the workplace, including the potential pitfalls of too much freedom or too much control. They debate the merits and drawbacks of Google's famed 20% time, where employees are allowed to spend one-fifth of their work hours on projects they're passionate about. This leads to a broader reflection on how companies can balance structured and unstructured time to foster an environment where innovation thrives without sacrificing operational efficiency. The episode concludes with a consensus that while not all innovative efforts will succeed, the potential for groundbreaking ideas makes the endeavor worthwhile.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm going to be hosting again today. With us, we've got Justin, and Ramses, Eddy, and Will. Will, I think, is joining us for the first time. Welcome, Will.
\n\nWILL: Happy to be here.
\n\nMIKE: Happy to have you here. As usual, I'm going to give a lead here and kick off our meeting. I'm going to start with actually two stories today, and both of these are outside engineering. And I've given several music references. I'm going to do another one today [laughs]. It's a deep well to draw on.
\n\nWhen I was a kid, my mom signed me up for piano lessons [chuckles], and I was nervous about it. I thought...like, everybody else talked about it being dreadfully boring, and I thought it would be as well. Actually, I enjoyed it. I loved it. I took lessons for a number of years, nine years, I think.
\n\nAnd, in those nine years of lessons, I think I had zero lessons on improvisation or creativity. And I think I'm nowhere near unique in that respect. I think most people who have music lessons learn how to read music. And honestly, I think that's kind of a travesty. I've read from a mathematician, so there's something worth looking up. It's A Mathematician's Lament. And he actually gives music as an example. He said, "Imagine that music was taught by everybody learning to read music, but you never listened to it," because he took that idea to its logical extreme.
\n\nYou learned how to write notes, do all this notation, study chord structure, and maybe when you got to, you know, like, your teens or the really advanced students would be able to start listening to music. You know, in a world like that, of course, everybody would hate music. But music is often taught, not quite so badly, but kind of because we learn to read it, but not to write it. It's not given equal weight, and I think that's really unfortunate. Because if you don't give time for somebody to learn to create something on their own, they'll never learn. How could they? If there's not time, there's just no way.
\n\nWhen I was in high school, I took a guitar class [chuckles] and learned to play guitar. And I loved it. And suddenly, for the first time, music theory made sense. I looked at the guitar. I was like, "Oh, there's this circle of fifths thing, and, you know, let's see how this all works."
\n\nJUSTIN: [laughs]
\n\nMIKE: Then I started, you know, playing chords and chord progressions, and it was great. Later, I got a bass, and it was kind of the opposite of piano. Piano, you have all this polyphony and the bass; you just got one note you're plucking away at, and I loved it. You're thinking of, you know, I was able to improvise, think about just kind of the pure baseline there.
\n\nAnd I've had many experiences that I've really enjoyed, like laying down a bass line. Somebody's playing, or somebody played something, and I try to come up with a bass line to it, or, you know, I've kind of come back to piano in the last few years as well. I enjoy making music with other people, and I like creating music. And I probably do more creative stuff than reading music, to be honest. I flipped the tables because I had time to do it, and I was given a structure that allowed me to do it. And it made all the difference, and it allowed me to enjoy music in a way that I wasn't able to before.
\n\nOne more story. So, I want to do something different from music. We've done lots of music references, so I'm going to do something very outside of music. I've got a garden behind my house. I like greens. I'm a fan of greens, but I'm particularly fond of red Russian kale. But I'm actually not going to talk about red Russian kale. I'm going to talk about a different green, which is mustard greens. I've got a variety called Ruby Giant. It grows big, beautiful leaves that are red on one side and green on the other side.
\n\nLast year, I let some of those go to seed, and when it gets hot, they do that. They go to seed, and they leave seed all over. And then I let the seeds grow, which looked kind of weedy, to be honest [laughs]. It was kind of messy in that area of my garden, but I was curious what would happen. And in the fall, I got a lot of mustard that grew up. And one of the mustard plants that came up was pure red. Usually, like I said, they're red, kind of red mottled on one side, and the other side, it was green. But this one was red, just deep burgundy all the way through. It was an amazingly beautiful plant, tasty, too [laughs]. That's some of it. I actually pickled some mustard greens. And I hope that it comes up again this year.
\n\nThe point that I'm getting to is, if I had not let the garden get a little weedy, you know, get a little overgrown there and go to seed, I never would have had that second generation. I never would have had that innovation in my garden where I had something that I never had before. If I just kept everything nice and tidy, that would have been it. I would have had that first generation. I never would have had something new. I gave it space. If I had not given the space for something to be a little messy and go its own way for a while, then I never would have had something that was genuinely different from what I had before.
\n\nThere's my two-lead story. Today, we are talking, and I don't know if I've mentioned it before, fostering innovation and collaboration among engineers. But I haven't talked about engineering yet, but these stories speak to me about what it takes to promote innovation or collaboration. I guess they're somewhat related. If you want collaboration, I think you have to make space for it. And you can't enforce it. You have to let it go to seed a little bit. So, there's my take. Thoughts? What do y'all think?
\n\nWILL: I'm kind of curious, like, what do you mean by, like, sort of innovation? In that, for most of the work that we do, innovation is really more customer-facing than technical-facing. You know, like, there are companies and organizations and stuff like that that are actually sort of cutting new trails technically. But by and large, I think the overwhelming majority of innovation is, like, delivering things to customers. And we're not necessarily, like, writing our own database, or writing our own operating system, if we're doing a new LLM based on sort of, like, existing open-source work.
\n\nAnd so, when I think of innovation within engineering teams, generally speaking, it comes in one or two flavors, one of which is a little bit of an anti-pattern and one of which I think is really, really healthy and good. Like, one of them is honestly, I mean, it's sort of, like, engineers gone wild because you've got a bunch of smart people who are maybe underutilized, you know, they're kind of chewing the walls a little bit.
\n\nAnd so, you'll find just shiny object syndrome, you know, the sort of, like, JavaScript flavor of the moment, you know, just because people are bored. People are bored at work. They want to play with shiny, new toys. And, you know, you'll find yourself in a situation where, like, they're reinventing things that aren't really generating a problem. And that's a little bit of an anti-pattern, but that's the evil twin.
\n\nThe really good part about it is when you have had a nagging, constant pain in an engineering organization and figuring out a solution to it. And so, you need to be, I think, disciplined, you know what I mean? Like, are you solving a real problem? Is this thing better, or is it just new? There's actually technical innovation that is sort of, like, customer-focused and facing, which, you know, I love but isn't necessarily an engineering question. I hate to buy into the grossly incorrect notion that only product could ever come up with technical customer-facing innovation.
\n\nMIKE: [laughs]
\n\nWILL: I think that's incorrect, borderline offensive. But, like, within the context of a sort of engineering organization, that's where I'm coming at it from.
\n\nMIKE: I've got a couple of examples I can think of just off the bat. We have taken times in the past that I think we still got on the calendar, what we've called 5% time. It's just every other week in the afternoon, we have this space to collaborate on something, a time to scratch that itch to work on something together.
\n\nAnd a couple of years ago, maybe three years ago [chuckles], sometime in the last few years, some of us chose to take that time and extract an important service out of the main application we were working in. And that service became actually kind of critical to the company because it's our merchant API, and it allows them to get information. I don't want to go too much into technical details about the company. We were able to extract this application. It ended up being a really valuable extraction and would never have happened. It wouldn't have had any legs at all unless we had just taken that time to pull that out.
\n\nMore recently, we've done something similar. We had a DevDay project, worked on something that we wanted to get done. We took a, basically, it was a message queue [laughs] that some agents were using, and we pulled it out of the database, put it into Redis to make it perform better. And it was really volatile data anyway. And we put it over there, made it into production. And it's how it's running now. And it's been working [laughs], right?
\n\nAnd, again, it wouldn't have gone forward unless we'd taken that opportunity to schedule some time and say, "Hey, go do an experiment." We didn't finish the experiment on that DevDay, but it gave us something. We actually ended up scheduling [inaudible 08:35] engineering organization because it solved several problems, removed some old code that we needed to get rid of, and an aging library, you know, solved a problem.
\n\nAnd I think to your point, Will, if you just set a bunch of people free and said, "Hey, work from wherever you want to for as long as you want to," and there are some organizations that do that, I think, you end up with a lot of ivory towers that don't accomplish much [laughs]. You know, people build this amazing, perfect software that doesn't solve any problems. But if you box it in a little bit, and I've seen this a lot of times, you box in creativity a little bit, it actually tends to grow. If you restrict the number of options, then people have something to work with. You know, if you've got a riff to play against, well, now you've limited the options, so you can make some music on top of that. It works a lot better.
\n\nEDDY: You know, Mike, you mentioned 5% time, and I'm pretty sure that's based off of Google's 20% time. It's just fractioned off a little bit. I want to go on record in saying if I remember correctly, I think some of their best products that Google uses right now on their subscription base was because of their 20% time that they fostered. I want to say some of those were, like, Gmail, for example, and, like, I don't know.
\n\nMIKE: I think Gmail did come from that. Yeah.
\n\nEDDY: Yeah, and, like, Google Maps, I think. It's been a while since I read that list, so I don't have an exhaustive list. But that's just a prime example of if you foster innovation in your team, you know, you get some really solid projects.
\n\nJUSTIN: I think part of that is people who are in charge have the ability to recognize when something has legs as well, you know, a little bit of guidance there from management where they can recognize, hey, this project has a potential to solve a problem. Let's gently encourage people to continue working on it.
\n\nAnd then, also, the flip side of that is maybe those same people look at stuff that other people are working on and say, "Hey, you know, maybe you should be working on something else," or helping them recognize, "Oh, is this a dead end," or "Is this something that you want to keep on going on?" and giving useful feedback that way. You don't want to, like, nip things in the bud necessarily, but at the same time, I think giving useful feedback and being able to receive useful feedback I think is key to being successful with these side projects that become big things, big successes.
\n\nWILL: I think if you're doing 5% time, then you sort of, I mean, I don't know, maybe Mike could, like, maybe this isn't how it went down, but I feel like you guys found something good in 5% time and exactly like that, like, management, like, saw it. And they're like, "Oh, this is kind of cool. Okay. You know, like, I'm going to feed this a little bit. I'm going to get this onto some sprints so that it could actually, like, go."
\n\nI don't know, I personally favor, like, this 20% time because I don't think 5% is enough to ship a product, you know what I mean? If you actually want to ship a thing that somebody could use, 5% time ain't going to get it. And, like, the thing about, like, sort of, like, management is management has their own priorities, and management gets their say. They get their time. It's not like management is doing a bad thing, but I mean, the idea of unstructured creative time is stuff that isn't on management's radar.
\n\nAnd I think, I mean, I'll say it directly, like, I think management is not as good at innovation as they think they are. It's not that they're bad necessarily, but, like, they don't have more good ideas than the whole of the organization, you know what I mean? Like, really tying people loose will come up with stuff. I mean, and, like, hear me, you have to be, I suppose, like, maybe more specifically what I'd say is that sort of, like, wide open 20% time, you're going to have some duds. You're going to have a lot of duds. You're going to have a lot of stupid, boneheaded, dumb go nowhere ideas. There's going to be some dumb stuff that comes out of that unstructured time.
\n\nAnd management is a little bit...I think they're naturally resistant to just transparently stupid ideas. But you're also going to take stuff that's a good idea, but it's, you know what I mean, a little wild for, like, you know what I mean? Like, you'll never get it into a sprint plan unless it's done, and it's like, oh, wow, this is cool, like, you know what I mean? The Google projects are a classic example of that. They did a lot of stuff that was really, really big, but they also stopped doing it because nothing makes as much money as ads in search. The manager was like, "This is cool."
\n\nEverybody loves Google Reader, right? Beloved dead product. Or another one, I mean, like, and this is maybe the other side of the coin, Google Voice, right? Google Voice, right? What a stupid idea. And it never made any money, and it never did anything. Oh, wait, here it is, 2023. We have this absolutely gargantuan corpus of voice data that we have been snarfing up for literally a decade. Man, our LLM would love that, wouldn't it? [laughter] You know, I mean [inaudible 13:37],
\n\nEDDY: You just suddenly stumbled upon having a full database of the stuff that you would kill to have, and you have it by accident.
\n\n[laughter]
\n\nWILL: Yeah. Oops! You know what I mean? And that's kind of the thing, you know, I mean, it's, you know, can you afford it? You know, I mean, there's good and bad points. But, I mean, like, the management control I think it's just a flavor, you know, like, somebody likes chocolate, somebody likes vanilla, and it is all heavily directed by business constraints. Google prints money. They print more money than anyone has ever seen, ever. And it just keeps on coming. So, they had opportunities to do that that people with tighter budgets maybe don't.
\n\nEDDY: You know, what I feel like companies typically don't do is they don't reach out to people who are out in the field, you know, doing a bunch of that customer interaction. Let me give you an example. When I go into a restaurant that I haven't been to before, my general go-to rule of thumb is talk to the individual who is in the front-facing. And I'll ask, "Hey, what is your favorite dish from your menu?" They're probably going to have a more concise answer than someone who's up in management because they're consuming the product at a different level.
\n\nBut not only that, let me take it a bit further. There are individuals who I ask, "What do you do differently to the products that you sell that make it taste better?" Do that sometime. I promise you, nine times out of 10, they're going to give you a different menu item that's not publicly available. But let me tell you what, it tastes so much better because that's not something that they typically offer. If you're trying to promote innovation, reaching out to the people who have the ability to play around with your product is probably the best thing.
\n\nTo add to that, when I started at Acima a couple of years ago, part of the onboarding process was speaking to people and agents who are talking on the phone, who actively use the product that we develop on a daily basis, and I got to speak with them. And I'm like, "Hey, what would you like the app to do, something that we haven't considered?" The amount of input that they have is insane. So, I feel like there's some lost potential there that we could harness or any company can harness.
\n\nMIKE: Absolutely. You know, I mentioned you have to have an untidy corner in your garden if you want something new, and not everybody's going to like that. It's going to make the neighbors uncomfortable [laughs]. It might make some people in your own home uncomfortable. They're like, "Well, no. Why don't you just level that out?" I just want to see some bare soil." But that's kind of the price you have to pay. You have to have some of those wild ideas, some of the dumb ideas, some of the things that aren't going to work because that's what innovation looks like.
\n\nYou know, to Will's point, management is not uniquely qualified to have smart ideas. What good management does, and this also builds on what Eddy was saying, is that they look for those ideas. It's not, hey, the idea was mine; rather, I found a good idea that somebody had, and I'm going to promote that because it's a great idea.
\n\nJUSTIN: I think that's one of the best talents that good leaders have is the ability to recognize good ideas. If you look at Steve Jobs, I mean, he's acknowledged for his designs and everything, but he also has the ability to recognize, you know, hey, what is a good idea? What all fits together? What could fit our company? Or what do people potentially want? And it's not all just him, of course, but it's his ability to recognize that.
\n\nAnd Apple has a way of doing things that makes them one of the top companies in the world. And so, if you look at that, it's like, obviously, as a company, they're generating great ideas. They probably have a dozen misses for every hit they have. And so, being able to have a place where you can have a dozen misses and not be fired, and being able to do what you want to do to encourage that, I think, is key. Having a wild garden or a place where growth is encouraged.
\n\nMIKE: Yeah. You mentioned Steve Jobs. One thing I've always been struck by is, as a kid in the United States, a lot of times we hear about Thomas Edison, this great inventor. And you picture some guy in a lab, just some guy in a lab. But if you actually read about his lab, he had, like, a hundred employees [laughs]. His job was not sitting there at a bench inventing stuff. His job was to lead a team of engineers.
\n\nAnd what made them successful wasn't one guy being brilliant. It was a team of engineers being given the space to work on good things and then filtering down the ideas and channeling them. It's a department effort with good leadership from the top that makes a difference. That guy's name's on it, but it really wasn't him who came up with most of the ideas. He just led a team.
\n\nWILL: But, I mean, like, if I'm being honest with you, I mean, like, most of the corporate managers I know were not selected for their ability to innovate, you know what I mean? Like, how do you become a manager, right? Well, you know what I mean? You have, like, sort of technical expertise, and you have the ability to, like, sort of, like, organize a team. And a line-level manager is not really an innovator. That's not really the job, you know what I mean? Like, the job is to sort of, like, organize and implement somebody else's ideas.
\n\nAnd how do you become, like, a mid-level manager? A mid-level manager is a line-level manager, and a senior manager is a good mid-level manager. And as you go through, like, successive generations, I mean, like, the original person, okay, that's like a Steve Jobs type, right? Which is why Apple went down the tubes pretty quick after the innovative person he left. And so, I mean, like, most corporate managers, being good at innovation is not how you get that job.
\n\nSo, I'm [inaudible 19:21] for a very large retailer who shall remain nameless. But they have succession, successive generations of these sort of managers, you know what I mean? Who are implementers, you know what I mean? Generation after generation, after generation after generation of these guys, and they're not dumb guys. But, like, that job is not their job, and sort of, like, they've been evolutionarily selected, for, like, particular traits, and then they get to the VP level, and it's just like, okay, innovate. And it's just like, okay. [laughs]
\n\nJUSTIN: So, what you're saying is we are selecting for the wrong thing at the manager level, or many companies are selecting for the wrong thing at the manager level. They should be selecting for innovation when they are instead selecting for the ability to manage a Jira project.
\n\nWILL: Well, I mean, like, you need the ability to manage a Jira project and sort of, like, what that 20% time was, you know what I mean? Maybe the argument for it is an antidote for Jira itis implementation type stuff in that, like, okay, let a bunch of wild prototypes out and not sort of, like, curating them because you are a tastemaker, which you're not, you know what I mean? But, like, sort of, like, being humble and saying like, "You know what? I don't know what's going to work. Let's just let a thousand flowers bloom.
\n\nAnd when something goes, when we have a winner, when something hooks, even though it wasn't my idea, then I'll take it, and I'll do what I do, which is, like, get this thing over the line in a polished professional setting." Like, that's the counter, right? But it takes a certain level of, like, egoness and, like, a release of control, which is not necessarily how corporate hierarchical management works.
\n\nEDDY: You also need a butt load of money to innovate and take that risk, too, right? So, it's not like anyone can really do that.
\n\nJUSTIN: That's an interesting constraint. If you are in an environment where you are trying to squeeze every developer efficiency out, allocating 20% time for other stuff that you don't have a guarantee of return on, that's hard.
\n\nMIKE: Two things, Will, you said. The 20% is the antidote for everything else. I think that's exactly right. It's the part you set aside that you don't control [laughs], and controlling the rest is actually really important. That 80% is critical to your business. You don't want that 20% to grow to 80% because then you go down the tubes pretty quick. You know, you need to keep that constraint, but you have to have that innovation.
\n\nThere's a huge risk in being stagnant. In some ways, that's maybe the most risky thing. If you look at the most valuable companies from 20 years ago, it was like Exxon [laughs]; IBM may have been on there. You know, the companies that you don't really think about that much anymore. You know, there's all these tech companies today. And 20 years from now, it'll probably be another set. If you look a hundred years ago, you had train companies or the big oil companies, and they were huge. They looked like they were unstoppable. They were massive transportation company. But they quit thinking about themselves as a transportation company, started thinking of themselves as a train company because they've got all these trains.
\n\nAnd once you start getting that line of thinking where you don't innovate against yourself, you become stagnant, and then an upstart comes and out-innovates you, and you lose your momentum. You have to have that innovation because that's also risky. It's risky to put all of your eggs into that, but it's also hugely risky not to innovate because you will eventually stagnate and die out.
\n\nWILL: And I'd also say, like, I mean, a little bit of a false premise in that, like, you think, like, oh, well, we're going to invest 20% time in people coming up with their wild, crazy ideas. Okay. Well, I mean, that's a big risk. But it's also a risk, like, I'm working for a very large company, where bluntly, the innovation stuff is the decisions are made based on VP-level people who did not get their position through being an innovator. And they have vibes, and they have some vibes.
\n\nAnd then, all the chips go to the middle of the table based on one individual who is...and I want to be very clear; they're smart people and hardworking, you know what I mean? Like, they're not bad people. Everybody that I've dealt with has been. Like, they've all been, like, solid folks. But, like, that's not their thing. They've never invented a product, ever, until they get to do it, and then all the chips go to the center of the table.
\n\nAnd if their vibes are wrong, you know, then you're cooked, whereas, I mean, bluntly, if it's 20% time and everybody's just coming up with some wild idea, I will call a spade a spade. You have a much higher standard that that idea has to meet for somebody in management to pick it up and run with it. It's got to be a lot stronger than somebody just having a vibe.
\n\nJUSTIN: Yeah, I got an interesting story about this. My friend works for Ford pretty high up in the finance department. Ford, a couple of years ago, decided that they were 100% all in on the electric. Then they came out with a couple of electric vehicles, most notably, the Ford F-150 Lightning, which came out to great fanfare, but turns out that the battery is just not there for what people use a truck for. So, all of a sudden, his decision to do this very innovative thing...because Ford is, like, 120 years old or 100 years old, right?
\n\nAnd as CEO, he put all his chips in on this new electric drive train, which I think is awesome. I love electric cars. But, for Ford, their number one seller is the Ford F-150 truck, which is a standard truck that people love, and they love the ability that it gives them to, you know, a variety of things. But one of the main things is like, you know, you can go out and gas it up and keep on working. Whereas with the Ford F-150 electric truck, you can charge it overnight and try to find a charger somewhere else. But if you can't find a charger, you're high and dry, and you're in for an expensive tow.
\n\nSo, he went in on innovation that perhaps was not ready yet, and he's probably going to lose his job over it, which he probably should, in some ways because that's the CEO. But it's just interesting because I think, yes, you need to recognize innovation and go for it, but maybe not bet the company on it [laughs].
\n\nEDDY: Well, fear of innovation is also what's going to put you in serious risk...
\n\nJUSTIN: Yeah.
\n\nEDDY: Right? Of bankruptcy. As an example, off the top of my head, and it's not a jab at this company, but it is a prime example. Blockbuster was amazing, right? Like, they were a striving company for years. Staple name, staple IP. Everyone knows the name. Even now, you could talk to someone, "Hey, do you remember Blockbuster?" "Oh yeah. They were awesome, you know." They had the opportunity to buy Netflix at the time. And then, they passed up on that because they didn't believe that that was the future. And being scared of innovation it was a prime example of why they went out of business. So, there's definitely [chuckles] a balance with fostering innovation in your company.
\n\nMIKE: Yeah. 80% of your company going into innovation is bad, and 0% of your [chuckles] company going into innovation is bad. That suggests that maybe there is somewhere in between that is good.
\n\nWILL: Well, I sort of like 20%, and I like releasing the illusion of control. I like releasing the illusion of, like...the reason I like sort of, like, unrestricted 20% time is because you're not predicating your ability to continually successfully innovate based on the smart guy that I have designated. Me, the big boss with my big brain, have said, "These four or five guys, these are the smart guys. I know best, and these guys are the people who are allowed to have ideas. And they will be smart guys and give me the correct ideas. Versus just sort of like, I don't know, we're going to try some stuff, and we're going to pick the winners, and we're going to ditch the losers, and we're going to see how things go.
\n\nIt's the ego control, like, only I know best thing, which I think is endemic to top-down corporate hierarchy, and they will kill you deader than fried chicken. And I would also like to tip of the hat to Netflix because, like, Netflix, they're doing better than ever. They torched their business, remember?
\n\nMIKE: Yeah, they did.
\n\nWILL: Remember the DVDs?
\n\nMIKE: They did [chuckles].
\n\nWILL: [inaudible 28:08] dollar company, and they're just like, "Nah, we're done with that. This is stupid. This mail stuff is dumb, you know?" They are sort of, like, this sort of counterexample to, like, you know, they had a really smart guy who really got it, and he had the right idea. He's just like, "Nah, this is it." I mean, it's great as long as you have a Steve Jobs, and you can continue to have successive Steve Jobs. If you could guarantee that, you're going to do great.
\n\nJUSTIN: It sounds like we have a great conclusion here that, you know, yes, there needs to be innovation and, you know, enable our engineers to kind of run with their ideas a certain percentage of time. But is there a way that you can make them more successful? Like, granted, you know, X number are going to be unsuccessful, right? You're going to have a lot of duds. But is there a way that you can help structure their projects that could make them more successful than not? What would you do? Would you encourage project planning, or maybe a deadline, or something, some sort of guardrails, or guides that could help them on those?
\n\nWILL: I think you got to go the other way. I think people's natural inherent bias is fear of failure. I think that's baked into our DNA, our bones, who we are as human beings. Honestly, like, I think you have to encourage, like, wild, stupid failures. People don't want to...even if it's 20% time, it's like, it's cool. Fridays just do weird stuff. Nobody wants to go to their boss and say, like, "You know, hey, what'd you do for the past year's worth of Fridays?" It's like, "I just wasted it all. It was all just stupid. It was all a complete loss." Like, think about even if it's like, don't worry, it's not going to affect your performance if you fail more, not succeed more, fail more. It's just the bias that we have to correct for as human beings is a fear of failure.
\n\nMIKE: I think you're dead on, by the way [laughs]. I actually have...I'm sitting up where my kids do school. I've got a sign that says...I'm not sure I got it quite right, but I'm going to get close. "Mistakes are proof you are trying." I want my kids to hear that every day. It's so important that they know mistakes are part of this. Mistakes are great. Please make a lot of mistakes because that means that you're doing the right thing.
\n\nNow, I want you to pay attention enough that maybe you're not making mistakes that you knew better than. But I want you to be trying new things that you make mistakes on. If you're not trying things that are hard enough to make mistakes, that means that you're not really learning anything.
\n\nJUSTIN: Well, maybe that's just the answer then. It's just, like, you go in and set the, I hate saying, set expectations, but you set the expectation of, hey, go out and try this. Go make a bunch of mistakes, and recognize that you aren't going to be perfect. And recognize that, hey, go out and collaborate with your teammates and share ideas maybe with each other. Go out and ask for help. Don't be afraid to share what you're working on. And even if it's a stupid idea, you know, chatting with other people maybe...actually, this may be a separate, you know, encouragement of, like, I don't know, some people may want to go off on their own and do stuff all by themselves, but maybe encourage people to collaborate at least.
\n\nMIKE: So, encourage pairing, for example? You're going to be pairing with somebody, you know, X number of hours a week, N number of hours a week, whatever N is, three, two, I don't know. Give your [inaudible 31:27]
\n\nJUSTIN: I'm just saying in terms of your 20% time.
\n\nMIKE: Got it. Got it.
\n\nJUSTIN: Because a lot of times, if you go out and you go try to solo something, that's good. Sometimes you just got to, like, research the heck out of something. But in order to get it to the next stage, you recognize that, hey, I need some help. Let's see if I can convince some other people to join my 20% time project.
\n\nWILL: Exactly. I mean, we've been talking about a higher bar, right? The higher bar, like, your manager doesn't have to persuade you. They didn't even have to persuade you that they were your manager, somebody said.
\n\nMIKE: [laughs].
\n\nWILL: And I'm like, "Well, I don't want to work for Mike." Like, "Do you like getting your paycheck?" "Yeah." "There you go."
\n\nJUSTIN: [laughs].
\n\nWILL: I mean, like, yeah, the fact that you have to persuade, I mean, that's extremely uncharitable of me, but it's incorrect. It's wholly incorrect to say that somebody just, like, made something up. Like, there's even in management meetings, like, you got to make your case. You do have to persuade people. It is necessary.
\n\nMIKE: So, to summarize what we've come up with here, if you want to have innovation, you have to set aside some time for it. You have to make a space, and it has to be uncomfortable. That's not to say you put all your time and space for it. You budget a portion because you got to keep the lights on. You got to keep the business running. And doing most of your business should probably be the biggest part of your priority. But you better put a portion of that dedicated to doing these new things, most of which will not work out.
\n\nJUSTIN: It's also worth noting that if you aren't encouraging the innovation inside your company, the smart people are going to go out and start their own company with whatever ideas they had, so...
\n\nMIKE: I think that's exactly right.
\n\nWILL: And I think, like, as I think about it a little bit more, like, there's a level of, like, it's like venture capital, right? There's a level of scale that you need in terms of, like, sort of, like, 20% time. Like, a company as big as Google, 20% time, it's like, okay, that's a lot of different ideas, a lot of smart people. They can do stuff.
\n\nBut, I mean, like, if you say, like, "Okay, 10% is going to win," and you've got, like, ten people, you're going to have to bet on having a smart guy. You can't afford a lot of losses. You need a certain scale to just sort of like, let's go! If it's let a thousand flowers bloom, okay, that's one thing, but if it's, like, let one flower bloom or five flowers bloom, you know what I mean? Like, it's going to be more difficult to be assured of a win, you know what I mean? Like, then you might have to put your eggs in one basket and, like, be more judicious about it.
\n\nMIKE: That probably just comes down though to management [laughs], and there's a flip side. Like, managers actually can do a good job if they're good. I think that's a good stopping point. And this has been a great session. And I look forward to getting together again in the next episode of the Acima Development Podcast.
","summary":"","date_published":"2024-05-08T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/751b7993-803b-4e25-bff3-bb1a0e9ace97.mp3","mime_type":"audio/mpeg","size_in_bytes":22187011,"duration_in_seconds":2058}]},{"id":"f3f2bd1a-c50b-4e68-817c-8e3f8a92e982","title":"Episode 44: Conformity vs Autonomy","url":"https://acima-development.fireside.fm/44","content_text":"The panelists explore the tension between conformity and autonomy within software development teams and the balance of standardization and flexibility in coding practices. The conversation revolves around their efforts at Acima to standardize pull request assignments and the dual roles in code reviews, highlighting their team's unique approach of using a chatbot compared with other teams using GitHub Actions. They also discuss the challenges of integrating new developers into standardized practices, especially for teams with a lot of junior developers.\n\nEddy emphasizes the importance of standardization across teams to reduce the onboarding time and confusion when developers shift between projects or teams and advocates for company-wide code standardization to facilitate easier transitions and maintain consistency. Dave discusses the implications of standardizing tools versus processes and how each choice affects team operations and risk management strategies.\n\nThe discussion turns philosophical, pondering the broader impacts of autonomy in development practices. Dave and Tad debate whether autonomy should extend to individual tool preferences or be constrained by team and organizational standards to ensure cohesive and efficient operations.\n\nTranscript:\n\nTAD: Hello. Welcome to another episode of the Acima Development Podcast. My name is Tad, and I'm the one who's going to be hosting today. Today we're going to be talking about conformity versus autonomy, or another way to put it is, how much do you need your devs to standardize versus how much flexibility are you going to allow them to have? Today I have with me, Eddy. \n\nEDDY: Hey, guys. \n\nTAD: And Ramses. \n\nRAMSES: Hey, guys. \n\nTAD: Sergio. \n\nSERGIO: Hey. \n\nTAD: Dave. \n\nDAVE: Howdy, howdy. \n\nTAD: One of the reasons why this is kind of timely for us is because we have several different services, several different teams here at Acima, and we've been making a push to standardize things between the teams and to become a bit more uniform between the teams. So, I have some examples, but I thought I'd throw that out. What are your thoughts? What are some of the things that we're trying to standardize on right now, and how do you feel about it? Or maybe I'll just go first. \n\nSo, one thing that we're trying to do is standardize how we do assignments of pull requests. And the team that most of us are on, actually all of us on this podcast today are on, we have two different roles that we have when we're doing code reviews, where one of them is a code reviewer, and that person just reads through the code, looks for anything weird or unusual, maybe asks some questions, and then they give the thumbs up: yes or no. \n\nThe 2nd role is a full reviewer, and that person goes through, reads all the code, but then they also go through a bunch of steps to actually exercise the code and assure themselves that that code is working. And that works great for us because then we have two people who are reading the code and two people who are then QA-ing the code because we also have a third QA person. But the other teams don't do it that way. \n\nWhat we've done is we actually wrote a chatbot that would manage our assignments for us so that we get a mix of people doing the reviews. And not everyone gets back-to-back full reviews because, you know, you can skim through code, maybe on a PR, and that takes you 5 or 6 minutes. But it might take you 30 minutes to actually go through and exercise all that code. And so, because full reviews are a little more time-consuming, we like to make that a little more fair. \n\nAnd having our chatbot and having coded up a way for us to do our code reviews works great for our particular team. But our team is the only team that does it that way. So, the other teams are all doing GitHub Actions. So, we're trying to reconcile the fact that we have a chatbot, and the other teams have GitHub Actions. I think chatbot is better, but we're outvoted in this. It's not quite a democracy. So, we're currently trying to figure out how to get GitHub Actions to work for our needs.\n\nEDDY: I think that standardization for code reviews and testing, et cetera, is super crucial, right? Because what happens if you pick up...and I don't know if it's common practice in other companies to allow a developer to just clone the repo that the other team works on, and then just do the code change, and then just assign it [inaudible 03:35]. I don't know how common that is. But I do like the idea that Acima facilitates that. And having a standardization, I think, is important company-wide, right? So that you're not daunted with different team dynamics. \n\nDAVE: I think there's a thing to look at here as well that the way our team works and the other teams work we're talking about standardization of, like, generic process, right? It's like there's this implicit mapping from, like, GitHub teams to their team that isn't present on ours. So, it's a struggle for us because we do things a little bit differently. And we sometimes wonder, okay, do we want to standardize on a tool, or do we want to standardize on process? And, in this case, the processes map to tools that are different, right? That don't cooperate with each other. Yeah, it's a sticky issue. Like, either one of the tools has to be upgraded so that it can do both, or one team has to change process. \n\nEDDY: I think it's important to also distinct this, you know, that the Atlas team mostly comprises of junior developers, I do want to say, like, a good chunk of that, maybe half of the pie. Maybe that's deviated since, but historically speaking, the team that we are representing for most of us today are from the Atlas team, which is the name, right? And we adopted the idea of a full review and code review in a way to sort of make sure, you know, that the code changes are solid. And if you have a junior developer pushing out code, I would argue that the probability of a bug, you know, being released is greater since they haven't had the full exposure as a senior developer.\n\nSo, the reason why our team deviates a little bit more than others is because of how many developers, one, we have and, two, how many of those are actually junior developers. So, I think that is an important distinguishing factor to give context on why we have different procedures.\n\nDAVE: Yeah. It's a weird thing to draw it back to, but in my mind, it all comes down to how risk-averse or how you mitigate risk on your team. I've worked in shops where everything had to be reviewed, double-checked, super QA'd, jots and tittles because there's finance in this code, like, SOC 2 compliance, where whoever wrote the code cannot deploy the code. And I've also worked at a company where we had, you know, PHI and really sensitive data. But we had the agile mentality of if you want to make a feature happen, you own it. And if that means going into another team's project and into their repo across the building, that's fine because they're doing it to us. \n\nAnd the mentality at the company was if you need to change something, you go to that team and say, \"Hey, I need to add this feature.\" And, usually, somebody on that team will say, \"I can help you with that. I own that piece, and I'll be happy to walk you through it.\" But then they walk you through it, and then in that code, you did your own deploys. Like, you walk it all the way to production. And the risk mitigation there was if something goes wrong, you own it. Nobody else can handle this for you. \n\nThere are other places, like when you've got a team full of junior developers, where you can't own this. If this blows up, you're going to need, for lack of a better word, an adult to come help you. You're going to need a responsible adult, to put it that way. That way, we can exclude me from that group. You need a responsible adult to come, you know, fix the server for you because you took it down. And this happens anywhere you have people that have, like, principle of least access, where developers can't manage stuff, or SOC 2 where you can't do the deploy. And so, all the processes kind of vary. \n\nTad, you mentioned at the top that we were talking about, like, when do we allow autonomy, and when do we want conformity? And, in my mind, I think it comes to...and this is, again, more risk mitigation, but it comes down to how much of your autonomy is going to affect the people around you, right? It's like your autonomy stops at my IDE, that your feelings stop at my rights, or your rights stop at my nose, or something like that. And so, we'll see people that it's like, if you want to develop on Emacs, or Vim, or RubyMine, it doesn't matter. If you want to ship this straight to production without QA, that matters. That's a process that, you know, that there will be people at your door saying, \"This is unacceptable risk.\" \n\nEDDY: Well, it also depends on how robust your QA integration really is and how big of a change that really...or the impact of that change really is, right? Like, for example, I'd argue that if you're pushing out, like, a simple text change, does that really warrant a QA assignment? Probably not. They can probably allot...their allotment for them would be better elsewhere, right? \n\nTAD: I was going to ask, I think another part of it is can you pull a developer off one service and put them on another? Because if other developers have been pulled off of our team and need to do a PR against our codebase and they don't know how to do it, right? Because it's not the same process to do a PR on their team, like, we have certain standards. Like, it's small, and we have a full reviewer, and a code reviewer, and a QA person. And those aren't the same standards on another team. \n\nAnd so, you know, it's like Eli Whitney in the interchangeable parts, like, can you move devs between different pieces of your codebase? Or can you move devs between other teams? And if you don't have some standard there, then there's friction. There's an impedance, right? \n\nDAVE: Yeah, that's fair. The shop that I was at where we had...you would...in fact, we literally had developer hostage exchanges where you would literally go work on another team for, like, two weeks, you know, for a sprint and then come back, and they would send somebody in your place. \n\nBut, like, if you went to, you know, this other team and said, \"Hey, I need to add this feature,\" you would have somebody that would be your Sherpa and would be your subject matter expert and say, \"Okay. Let me show you the part of the project you're going to be working on. Let me show you what specs are covering that code. It's going to come in here. Data's going to go here, here, here, and here. You're following that? Okay, cool. When you hit here, you're going to have to...that's your feature. You have to change that. Change this. Don't touch that. Anything else is fair game. Go nuts.\" \n\nAnd then, you'd go off and write it and come back and [inaudible 09:28]. So, basically, you would get that basic grasp of, like, the lay of the land. At that particular shop, we would not just throw you cold into 100,000 lines of code and say, \"Good luck. Have fun.\" That's not fun. \n\nEDDY: I actually want to advocate for company-wide standardization for code for that same reason, right? When you get dumped into another codebase. And I think at Acima, and Ramses, you can kind of correct me if I'm wrong here, but it seems as though each team adopts their own philosophy. It's always been that way from what it seems. And the code is a great example of that, right? \n\nRAMSES: Yeah, totally different between different teams.\n\nEDDY: To me, that's kind of difficult, right? Because I'm a junior developer who's going over a year, right? Just pushing out code changes and stuff. And it was a bit of a [laughs]...so the codebase that I currently work on it's kind of grown a soft spot for me because I know where everything is, you know, like if I need to add a new client, I know where that is. Cool. If I need to do this, oh, I know where the service object lives, whatever. And I can just reference it, and I can be very productive. \n\nI did a change, like, two weeks ago, give or take, on another repository, another service, and it took me, like, God, I don't know, like, half the day to really understand, like, what they were doing before I could do anything. So, it's like, for me, it's like, I felt super, super, like, I was wasting a lot of time just trying to figure out, like, how that codebase works before I even went ahead and wrote anything or implemented any changes. \n\nSo, I can't help but wonder, if we standardize conventions for code company-wide, it will just be, like, a seamless transition to go and make another change, right? But at the same time, you run into the idea of, like, standardizing something that you are not a big fan of, right? And so, I guess it's kind of, like, a give and take.\n\nDAVE: Yeah, wanting to have everybody work on the same standard that's a lovely idea. That and five kilos of cocaine will have you creating RuboCop. \n\nSERGIO: But it has the bad side. It's like, if we standardize something, five years later, we figure out that this is not the right solution. It's like, this happened to us. We have this tool that we were kind of removing right now. I guess Tad is talking about that. I don't know if I can talk freely about that here, but it's like, we have this tool we built. I don't know who built in the team this tool. And we have a bunch of services using this tool, and we need to remove this, like, five years later. And it's like, whatever you make right now is going to be outdated in five years. So [laughs], standardizing is good, but sometimes it's [inaudible 12:09], you know, yeah. \n\nDAVE: I think it's important to be careful not to set the standard for all time. We spend so much time as developers trying to tie the hands of future us, which is dumb because future us is always, maybe not smarter, but always more experienced, always older than us. And, honestly, legitimately, my biggest frustration as a developer is when I have tied my own hands. I'm like, I need to change the way this works. \n\nI had a knockdown drag-out with a developer once over whether or not you could order the keys in a hash because a hash is a mathematical function, and the set of keys of a hash is a set. And sets, by mathematical definition, must not have an order. And I'm like, yeah, but the customer wants stuff to come out in the same order that they put it in. Customer gets what they want. Don't try to teach the customer set theory, right? It's tomatoes might be a fruit, but you don't put it in fruit salad. Don't do that. \n\nEDDY: Yeah. Can't you organize a hash, though? I'm pretty sure you can, and it's -- \n\nDAVE: By default, Ruby and Python they keep a list, an ordered list as things get put in. Yeah, they have a hash for quick access, and then they have a list for ordering. \n\nEDDY: So, it seems like a pretty trivial change, right? \n\nDAVE: But ten years ago, you could just about have an honest-to-gosh fistfight with the math majors over whether or not you should be allowed to do that. If you can't guarantee something, there are programmers who will spend a lot of time locking things down so that they can guarantee that you can't, which is not the same thing as saying, \"You can't guarantee.\" They want to guarantee that you can't. Now it's locked down. It's perfect. It's airtight. There's no way anybody can do anything wrong with the system. The problem is that every future change is something wrong with the system, right? It's something that hadn't been thought when that first mathematical formula was locked down.\n\nTAD: I was just going to go back to ask Eddy some follow-up questions. So, first of all, when you say having the same conventions, is that RuboCop, or is that style guides, or is that training? Or like some of the people mentioned already, what if you hate those things that the other team does and you're glad you're not on that team?\n\nEDDY: [laughs].\n\nTAD: And you can do it your own way on your team. And maybe a related question that I'm going to throw out to the group is, is there some value to having competing ideas? If everything is genetically the same in your population, then that means some plague can come through and kill everything, right? And so, diversity does have some value where you have competing ideas, and the ones with merit kind of float to the top over time, and then they fall out of disfavor, and new ones kind of clobber those.\n\nEDDY: Well, I think, okay, so it's more of a selfish ask for me than anything else, and I'll preface by saying that. Because, again, like, that was my first exposure contributing to another repository to such a degree, testing against a different codebase. And, again, like, the fact that I had to spend, like, half the day, you know, figuring out, like, their placement, you know, like where they locate a bunch of their code and stuff, and then how they write it; their style is a little different, too. \n\nAnd so, selfish me would just be like, cool, if we can all just agree on, like, being explicit with our return nils [laughs], you know, like, and that's just adopted across the board, you know, you'll just look at it, and you're like, \"Okay, yeah, cool, that makes sense.\" And I wouldn't have to stay there longer than I need to trying to figure something out, right? Or, like, using optional params, you know, like, in our team, we prefer it. We love it, you know. But other teams are like, eh. \n\nOr, like, a really hot topic is, like, factories versus mocking, you know, it's sort of like...and so, for me, it's like, if we can standardize that, you just know what to expect when you go into the other team, you know. And you don't have to worry about, like, understanding their concepts, especially if you're just there to make a simple change. Like, if you're just there to do, like, a simple change that you need to work and they don't have the resources on their team to do it, you know, suddenly, your task is two times or three times longer than it would have taken the other person to do it, right? And it's just kind of hard to do that, you know, if everyone has their own lick.\n\nTAD: I'm curious: are there some things that we maybe should standardize on and some things that are just trivial but we should standardize on? Meaning, we're always going to paint our bike sheds red, and that's just our standard color, right? So, for example, I know that we've had, in our codebase, like, four or five different HTTP libraries. And really, all the HTTP libraries do the same thing. They're a little bit different flavored, but they all make POSTs; they all make GETs. They all take a URL, right? Like, there's not a whole lot of difference. And so, would something like that make sense to standardize across all the teams? Where it doesn't really matter, but we should pick something? Are there things like that that we should be considering?\n\nEDDY: I've learned that if Rails can do it natively, use the Rails convention and don't try to get fancy [laughs]. \n\nDAVE: Basically, it's the same thing. It's like, bike sheds are red until further notice, or unless specified otherwise for a good reason, right? So, it's like, you can go to the water cooler and talk about how you should do it all day, what color do you want to paint it. That's fine. It's going to be red, unless there's a really good reason, and that's fine.\n\nAnd for, like, HTTP, my out-of-pocket answer is, yeah, you should standardize because, you know, convention over configuration. Where we run into trouble is when we have convention and screw your configuration, which is kind of where Rails is kind of headed. It used to be, like, Rails 2, Rails 3, man, you could change anything. You could back that thing onto a wacky data store and just, da, da, da, all kind of...and everything was super configurable. And most of that's still there, but it's getting more and more complicated and more ceremonial to change those things. \n\nThe thing, specifically with HTTP, I love the HTTParty gem. It's the most simple, straightforward, like, httparty.getURL and response. And you're just done. There's no setting stuff up. There's no socket handling, da da da. Just do it and go. And most like Faraday and the other ones will, Excon, they'll let you do that, too, but it's a little wordier. But HTTParty had, at least as of, like, 2017, had a threading bug. I want to say it used green threads, which is Ruby's internal thread manager, which runs inside one system thread, so it doesn't thread well. You stack up ten threads, and it's exactly as fast as running one thing ten times in a row. There's just no speed-up whatsoever. \n\nAnd so we switched to Faraday, which at the time did not have just Faraday GET. Like, Faraday 1.0 didn't have that. I could be wrong on that, but I didn't see it in the code. It was always Faraday dot connection do, and then inside the block, do your thing. It was ugly, but we needed it for performance. And so, that's an example of no, this bike shed has to be blue. It can't be red. It has to be blue.\n\nEDDY: You know, I'm starting to think...as we've been talking, I'm trying to think of all the things that we can typically, like, standardize. And, like, some of that is enforced by RuboCop. Is it not? I mean, most of that should be enforced by RuboCop, assuming that your repository uses it, right? So, it really is just a matter of all adopting the same rules.\n\nTAD: The same linter and the same rules for your linters. \n\nDAVE: And to be clear, I love Rubocop. It's just I want to kill some of the cops that we favor as a team. I'm like, I hate that we made this choice. \n\nEDDY: [laughs] I agree. You know, what's crazy is I used to be a huge fan of comments, right? And, like, anytime I wrote a function, you know, I found myself writing a comment about it, even though it was pretty self-explanatory. Until someone basically told me, like, \"Your code should be explaining it to you, you know, from the moment you read it.\" Like, you shouldn't have to dig into the nitty gritty to be like, \"Oh, that's what you're doing. You're doing something really fancy and stuff.\" \n\nSo, someone told me, and I can't remember who it was, and I kind of want to put them on the spot because, [laughs] like, that's rang true for me forever. It's pretty much what they said. It's like, if you find yourself making comments to a code, it probably means nine times out of 10 that it's more complicated than it should be, and you should consider refactoring. And that's rang to me true, you know, and for a while. \n\nTAD: I've had an exact opposite experience where people tell me, \"Oh, my code is so readable. It doesn't need documentation,\" and I beg to differ. \n\nEDDY: [laughs]\n\nTAD: I go in...and, like, \"I don't need to document my code. It's self-documenting.\" And when I hear a phrase like that, I cringe.\n\nDAVE: To steal a joke from [SP] Louis C.K., readability, readable, you know, writing readable code, it's like being called a jerk. If you say, \"I'm not a jerk,\" you don't get to decide that. Other people get to decide that for you, right? So, if somebody comes to you and says, \"Your code is really readable. I don't think it needs comments,\" then, yeah, especially if your comment is literally, do the thing, and then the line of code is very clearly do the thing. \n\nIt's especially from, like, the old C and C++ days, where you had to sneak up on your solution. You had to trick the compiler into giving you what you wanted as a side effect of the math that you were throwing at it. So, we had a piece of code go by this week where we have a certain number of products that can be in a list, and there was just one thing. There was only one kind of product. Well, now there's two things that can be in it. \n\nAnd so, somebody stuffed in a bit of code that said, \"Hey, if the list of products is longer than one, it has to be this combination.\" And I'm looking way down the road map, like, six months, nine months, ten months when we add a third product or a fourth product to this thing, and this is going to be wrong. Greater than one that's sneaking up on the side effect of, well, if you have two products, you've got more than one. Therefore, it's this comment.\n\nAnd Sergio and I changed it so that it was like, \"Hey, if you have this product and you have that product, then it's that combination of those two products.\" It's the same code. It does the same thing, but now I think it kind of doesn't need the comment on it, def combo item has item 1 and and has item 2. That's literally the code. I'm changing the names of the products to be a little vague here, but other than that, that's literally what the code is. \n\nTAD: I should maybe clarify what I like in a comment. If you give me the mindset you were in when you wrote that code, the reason you made the decision, why you took the approach that you did, I love those type of comments. If it's, this adds A and B together and returns the total, then, to me, that's a useless comment because I can see what it does, but I rarely know why you chose to do it that way, what the trade-offs were, what your mindset was, things like that, when you wrote the code. And those types of comments are rare but invaluable.\n\nDAVE: Yeah. Like, you have a thing that's like, A add B using this special adding method. So, you've got this, you know, conglomerate A and B, and the comment is, \"Level four figuring compliance.\" And you're like, oh, that's why we have to use the custom thing to do it, right? And otherwise, it would be just this weird addition.\n\nEDDY: You know, Ramses, you wrote something that's ringing true for me right now, and I kind of want you to elaborate on that, if you don't mind. Because I, too, agree with your sentiment, but I want to hear your opinion behind it. \n\nRAMSES: Regarding the class-level comments? \n\nEDDY: Yep. \n\nRAMSES: Yeah. Well, there's just a lot of times, like, you'll see in a model, or a class, or whatever it's basically just a repeat of what the class name is, like, \"Representation of user.\" Yeah, that's what your model is. \n\nDAVE: It's just repetition at that point, and you're only putting it there because RuboCop demands the documentation. When I document a class, I try to say why. Why does this class have to exist, or what purpose does it serve? And you can...yeah, you can have...I can't think of an example off the top of my head, but you get the idea that the comment should not just be if you've got, you know, class particle accelerator and a comment that says, \"A class for particle accelerator.\"\n\nEDDY: Yes [laughs].\n\nDAVE: It's completely useless, right? But if you've got a comment that basically says, \"General class interface for all accelerometrox products,\" then you're like, oh, okay, now I know why we have a particle accelerator class. \n\nTAD: So, going along with this, would you guys advocate for a standard commenting style? Because there's people that use YARD. There's people that use RDoC. There's people that say, \"You must state your inputs, your outputs, and give a why for this class, or this method, or whatever you're commenting.\" \n\nDAVE: I would say, \"Yes,\" if it's high ceremony, if the interface needs to be...like, if it's a Conway's...[chuckles] Conway's wall, not Conway's Law, Conway's wall, that's like, another team is going to come use that piece of code. It should be documented like the old MSDN libraries where you could hit F1 anywhere in the code in Developer Studio and get, you know, a page of documentation and examples, and gazintas and gazotas, and every possible thing that this thing can do. Yeah, document the snot out of it. If it's a private method buried down deep in some sidebar class that only affects your specific domain in that module of that sub-piece of the code, I don't know, maybe not. \n\nTAD: So, are you saying for things like our shared gems you would advocate for some kind of commenting standard?\n\nDAVE: I feel like you might be baiting me into a trap here, but at the risk of sounding like a complete hypocrite, yes. What I will say about us hypocrites, [crosstalk 25:56] criticize hypocrites how you want, but we do have higher standards than you. \n\nEDDY: So, you know, it kind of begs the question, right? So, like, standardization and comments, I feel like we don't have that, and I'm not very spoiled or privy to that, right? Because, again, I'm a junior developer, not much of experience in the industry. But I do love hitting, you know, certain logic, you know, and they basically say, \"Hey. Make sure you keep this in mind when you make a change here or whatever,\" right? I love that. \n\nI love that because they're being super, like, they're being super nice to me when they're saying, \"Hey, dude, if you're going to make a change here, like, just make sure you're cognizant about this, this, and this, you know.\" And comments do that, and they do accomplish that. And so, I feel like we don't have a standard on that, but I feel like we should, right? I think it is nice. \n\nTAD: So, I'm curious to ask about standardizing on some other aspects and how you feel about it. How would you feel about doing standardization of all of our setup stuff for all of our different services? \n\nEDDY: Oh, that would be nice. \n\nTAD: So, would you be okay with forcing everyone to use Docker or some other system? \n\nRAMSES: Sure, why not? Make the process much easier. \n\nEDDY: Okay, so I have a love-hate relationship with what you just said, right? Because there are people who utterly refuse to use Docker, right? Because their machine just isn't strong enough. So, like, why not provide an alternative for individuals who just don't have a beefed-up computer, for example? Or not everyone uses the same operating system. And what if your documentation is only catered to a certain OS? Then, at that point, you're kind of like, \"Ugh,\" you know, so I don't think you can truly standardize --\n\nTAD: Well, you can standardize hardware. You could say, \"Everyone must have an Apple laptop.\"\n\nEDDY: Wow. Yeah. I didn't realize that that was possible. \n\nRAMSES: Yeah. Tell everyone to start using Electron products, in-line, editors only.\n\nEDDY: [laughs]\n\nTAD: Yeah, like, would you guys be okay with saying, \"Everyone uses Linux\"? Because that's something that pretty much everyone on our development team would be able to use and that has maybe the best Docker support. \n\nEDDY: I haven't had an issue with Mac. Basically, anything that I needed to accomplish, like, Mac has been able to provide for me. So, like, there hasn't really been a need for me to be like, oh man, I really wish I was on a Linux [laughs] distro. There hasn't really been a necessity for that. I feel like that's because macOS has just gained so much credibility for development. Am I wrong on that assessment? \n\nTAD: Well, we have a lot of contractors that have to bring their own laptop. And so, you have the luxury of getting a company-issued laptop. So, you're indirectly advocating that our contractors would go out and buy Apple products. \n\nEDDY: It's a good point. \n\nTAD: Standardization has trade-offs, right? It's like, it would be great if we all ran on the same hardware, but then everyone who doesn't have the standard has to go out and somehow now fit to the standard. \n\nEDDY: I feel like it's easier to enforce standardization on code than anything else. Like, if you're standardizing something on, like, hardware, you know, I feel like that's super trivial, and you may lose potential talent because you're telling them, \"Hey, you're forced to use this specific machine, this specific operating system.\" So, like, for example, I've paired with our contractors who were from India and some of them, yeah, and like you said, they use Linux. They use different IDEs. Like one of them uses Sublime for God knows what reason, you know.\n\nTAD: Because it's fast and awesome. \n\nEDDY: [laughs] And the thing is, is, like, you would see him just kind of, like, flow through that seamlessly because he understands that super well. And I'm just like, cool, we shouldn't be forcing you to be using something if your innate flow caters to a specific software, so...\n\nTAD: But would it make it easier for you to pair with him if you had standard tools and standard hardware and maybe even, like, a standard IDE that you both were using?\n\nEDDY: Well, I want to confess something on record...Ramses because he's on the call. When we first paired, when I was learning how to code, he would pair with Vim. And for most of the time, like, early on in our pairing, I was like, oh man, I was like, what are you doing? Where are you at? I don't even know what I'm looking at. So, there is a level to that complexity, but I feel like eventually, you kind of just grow accustomed to looking at someone else's IDE, and you just know what happens. You know, I feel like, as wisdom prevails, it's easier to adapt oneself. \n\nTAD: What about you, Ramses? Side note, Ramses is a Vim user, and he loves Vim. So, I'd like to hear what his thoughts are. \n\nRAMSES: It'd certainly be easier if everyone was using the same tool in terms of collaboration. If I want to do a live sharing with someone in Vim, it's technically possible. It's not great, you know. It's not a great experience. It's certainly not as seamless as, like, Live Share on VS Code or live coding on RubyMine or, you know, any other tool. If I'm planning on doing a pairing with someone, I'll just open up VS Code. It's easy enough. It doesn't impact my workflow that much.\n\nEDDY: And to your credit, Ramses, I think you tried using it entirely for a month, right? \n\nRAMSES: Yeah, I've used it, like, I mean, I've used a wide variety of IDEs and other editors. For the most part, I don't have a problem with VS Code. It works just fine, for the most part -- \n\nTAD: I think the trade-off here is individual productivity, right? If you let developers choose what they want, then they'll choose the most productive, most familiar environment that they have. But if you standardize, then you might be increasing, like, pairing productivity or some other form of efficiencies, right? Like, if our servers are on Linux, they're all running in Docker. And so, if everyone ran Linux and everyone ran Docker, it would make it a lot easier for our DevOps team. So, are you willing to choose the approach that makes our DevOps team sad, Eddy? \n\n[laughter]\n\nEDDY: I feel like there's not a right answer [laughs]. \n\nTAD: I'm kidding. No, it's just hard because there's trade-offs with all these things, right? \n\nEDDY: Yeah, I think, to a degree, there has to be a balance between standardization and not. And I feel like I've been spoiled [chuckles] here at Acima because everyone gets to customize their machine, you know, to a certain degree. You know, it helps them with their flow. So, like, everyone can select whatever IDE they want to use. As long as they get the code out, it doesn't really matter. Or, like, some of us prefer to use different Git commands, you know, when rebasing or pushing stuff up. Like, that's fine.\n\nLike, ultimately, it accomplishes the same thing at the end of the day. So, I like the fact that I'm not micromanaged that I have to choose certain hardware and, like, certain software. Because at the end of the day, the one who's pushing up the code changes is the developer, right? \n\nTAD: I'm going to hit you guys with another one. How do you feel about standardizing on time? Meaning you do things at a certain time, and other people do things at a certain time. \n\nEDDY: What do you mean? \n\nTAD: Meaning, everyone starts their day at the same time. Everyone has their meetings at the same time. Everyone pairs at the same time. Everyone takes lunch at the same time. Everyone codes at the same time. Everyone does PRs at the same time. You could have a pretty regimented schedule and make sure that everyone's pairing at the same time, which means that you never have to coordinate with people to say, \"What's your schedule? What's my schedule? Oh man, we're not going to be able to get together on this.\" Because it would always be free. Like, you could really standardize when certain things happen and how things work for your team. \n\nEDDY: I don't really like that. And I'm just going off of my first reaction here. But I get hungry in different times than other people. So, like, what happens, like, if suddenly we're all forced to have lunch at 12:00 p.m.? But I'm like, \"Oh, but I usually don't eat till, like, 2:00 p.m.\" Suddenly, it's just I'm not being productive because now I'm having to force myself to go against whatever my habits are. \n\nOr, like, what if I'm like, I'm not very productive waking up at 7:00 in the morning and working at 8:00? What if I work better working from 9:00 p.m. or 9:00 a.m. to, like, 7:00 p.m., and that's the schedule that I prefer? And, like, as long as you get the work done, it really shouldn't matter, I feel like. And, like, time management should really be left off to the developer, in my opinion. Just, like, from the first reaction, I feel like the developer should be the one who pretty much decides the time management. \n\nTAD: Okay. Ramses?\n\nRAMSES: I think I am in the opposite camp, at least for the most part. I don't really care when other people start their day. If they want to start it later, end it later, it doesn't really faze me. But I think the parts of standardization that's good for time management is where...and this is something that we follow as an organization, where we have, like, a cadence, and we have structures like, okay, all teams do stand-ups in the morning, you know, between, like, 9:00 and 10:00, or whatever, you know. \n\nAnd then, in the afternoon, okay, that's developer coding time, so no one else can schedule meetings during that time. Like, I mean, you could probably do pairings with other people during that time because that's when you should be productive, but it's not time for engineering-wide meetings or team meetings. Those are kind of blocked out at very specific times. I think that's helpful for team collaboration.\n\nTAD: Yeah, I mean, I've kind of been playing devil's advocate or being a little bit provocative here, but the reason it did come to mind is because we did, a few months ago, agree on a team cadence where certain things would happen at certain times just because they found that they couldn't schedule things. They couldn't plan things because they never knew when people would be available or not. Or, on the other side of that is, you didn't know when you would have free time and when you'd get pulled into a spontaneous meeting, right?\n\nEDDY: Right. \n\nTAD: So, are there times that you think should be standardized, like meeting times, things like that? \n\nEDDY: [inaudible 36:52]\n\nTAD: Maybe not lunch. Maybe you don't dictate lunchtime.\n\nEDDY: I want to go on record and say I don't really like meetings, personally. \n\nTAD: [laughs]\n\nEDDY: I have limited attention span. \n\nRAMSES: I don't think anyone [inaudible 37:03] meetings.\n\nEDDY: Dude, like, if I get put...and this is just me, like, if I get put in a meeting that's an hour long, after the 30 minutes, you know, I'm kind of wandering, doing something else just because it's kind of hard to focus [laughs]. So, maybe standardizing meetings so that it's short and concise sounds kind of nice. \n\nTAD: How would you feel about something like meetings are standardized at 50 minutes long, and you always have to allow for a 10-minute break? You know, meetings always start on the hour or on the half-hour, and they are always, at most, 50 minutes long. And you always have to give a 10-minute gap before the next meeting. \n\nEDDY: That sounds awesome.\n\nTAD: Personally, I've been in back-to-back to back-to-back meetings where I've had five hours straight of meetings. And my brain is burned out by, like, hour three or hour four. So, would that kind of standardization be beneficial where you standardize the length and the style of the meeting, or maybe even the content of the meeting? Do you say, \"If you're going to have a meeting, you have to have an itinerary for that meeting. You have to give everyone the bullet points of the meeting beforehand and say, 'This is only going to be 50 minutes'\"? \n\nEDDY: I would agree. \n\nRAMSES: All meetings need to come prepared with a slide presentation. \n\nEDDY: [laughs].\n\nRAMSES: And it has to fit on three slides only.\n\nEDDY: You know, I'm trying to think because, like, I've looked at other code, right? And I'm thinking, huh, the other things I've noticed that they have conventions on is, like, camel case versus snake case and, like, naming for your functions and methods and variables and stuff, you know. I think we can all agree that we share naming conventions for that. Some of the really silly ones are, like, oh, your characters can't...your line can't be longer than X amount of characters. That's where I'm sort of like, ah, you're forced to rewrite the code differently and probably run the risk of it looking worse because you're trying to fit [inaudible 39:13]\n\nTAD: Well, arguably, if your line of code is 120 characters long, it's maybe a little too complicated. It could be broken into maybe a few lines of code.\n\nEDDY: Yeah, maybe, maybe. Unlike silly conventions that, you know, that we have in our codebase, where I'm just like, oh, man, but it looks better with the unless [laughter]. \n\nTAD: Yeah. It is nice to read it all as one complete thought rather than three partial thoughts, right? I mean, there's kind of something going on sometimes in the code, where you want to break it into, like, it almost compares to, like, sentences and paragraphs. And you're like, ugh, like, I just want to express it in a certain way. \n\nEDDY: Yeah, I agree. You know what's crazy? Is because sometimes those standardizations aren't present, I've learned to look at a code, and I'm like, oh man, this reads just like Ramses.\n\nTAD: [laughs]\n\nEDDY: And so, like, I'll go to the code. Like, I'll do a git blame. You know, I'm like, oh, it was Ramses. You know, I can just pick out, like, people's styles, right? \n\nTAD: Do you think it would be better if you removed that fingerprint, where you can't quite tell the style? \n\nEDDY: Yeah, right? So, like, if you're standardizing stuff, then it also removes, like, ambiguity because everyone's following suit, you know. And, to me, it's kind of fun to just kind of look at a code block and be like, oh yeah, this totally reads like Tad, you know [laughter]. And you're like, 9 times out of 10, you know, like, you're right. \n\nTAD: I'm curious: how do you guys feel about standardizing on policies? For example, what if you had a policy, \"No deployments on Fridays\"?\n\nEDDY: You know, a wise person once told me a little while back, and they said, \"If you're afraid to deploy your code on a Friday, then your code is probably not ready to be deployed.\" Like, you got to be confident with your changes, and if deploying on a Friday raises eyebrows, then is it really ready for production? Probably not. I mean, would you both agree with that sentiment? \n\nTAD: Well, I guess, just to clarify, so your argument is that perhaps standardizing policies is a symptom for a different problem. \n\nEDDY: Maybe. \n\nTAD: So, in your argument, the problem is we don't have confidence in our processes and our code quality, so, therefore, we make a policy to protect ourselves rather than fix the confidence problem or the quality problem. \n\nEDDY: I feel like that's not what I said [laughs]. \n\nTAD: Okay. Well, then restate. I'm sorry if I'm misrepresenting you. Go ahead.\n\nEDDY: [laughs] I was just saying, like, it's not the symptom of bad code or anything. It's just a matter of I feel like the reason why some certain teams prefer to not deploy on Fridays is because you do...regardless of how robust that code has been tested, you always do run a risk, you know, of it breaking something, like -- \n\nRAMSES: Yeah. No one wants to work on the weekends.\n\nEDDY: Exactly. So, it's not necessarily because it's bad code. It's just you do run the risk of it breaking something, and if you do, you're making people work more time than they have to. So, it's more or less just being nice. \n\nTAD: Are there other policies that you wish that we would implement that we don't have right now? We just barely talked about today in architecture meeting; for example, we floated the idea of...so, just for some context, we have a staging environment where we can deploy things, and kind of test things out, and try things in an environment that feels a lot like production but doesn't break things like production would, and it's a bit of a bottleneck. And so, now we're saying if you're going to take a lot of testing time, save that for the afternoon. And if you're just doing a quick check, do that in the morning because that alleviates a bit of a bottleneck that we've had. \n\nEDDY: Yeah, I think that's a good problem to solve, right? How do you both feel about standardization on, like, how big a development team can be? If your development team comprises of over 20x, you know, developers, like, how do you standardize, you know, and keep all your ducks in a line, you know, when you have 20x people pushing [inaudible 43:34] on these, right?\n\nTAD: Yeah.\n\nRAMSES: Like, Amazon says, like, the team should only be the size that it takes to feed, like, two pizzas, so, like, four or five people generally. \n\nEDDY: Really? That's their comparison [laughs]? \n\nRAMSES: Yeah [laughs].\n\nEDDY: Well, what happens —-\n\nTAD: Yeah, they say if your team is too big to be fed by a pizza or two, then you need to split it. \n\nEDDY: But what happens if I can eat a whole pizza? Does that mean that I don't need other people? \n\nTAD: [laughs] They're theoretical pizza-eating people [laughter]. Yeah, it's a way to not necessarily have a fixed number but more just, like, a sense of, yeah, this team is too big, right? It's kind of more rule of thumb rather than saying exactly five. They're like, \"Ooh, we're not going to be able to feed this team anymore.\" We are maybe too big. It is analogous, to some degree, to, you know, feeding a team, meaning providing work and coordinating that work with the other people, right?\n\nEDDY: Yeah. And you sort of lose that as the development team grows, right?\n\nRAMSES: Yeah. Yeah, it seems to be harder to collaborate and for decisions to be made on a larger team. \n\nTAD: Yeah. And I think just because standardization is kind of the topic, the bigger the team, the more of these protocols, the more of these policies, the more of these standardizations, the more things that you need to make that team work. \n\nEDDY: You know, I want to do a comparison, and I've never done the research on this. But, for example, if I were to look at, like, a Fortune 500 company, like, I don't know, like Tesla, Google, Amazon, et cetera, how they structure their development teams and how they standardize certain things, I think it'd be kind of cool to contrast. Like, off the top of your head, do both of you kind of have an idea of, like, how they differentiate themselves from startups?\n\nTAD: I've never worked for a company that big, so I don't have any comparisons. \n\nRAMSES: Yeah, same.\n\nTAD: But I think Amazon still follows that rule of thumb that if you can't feed your team with a pizza, then time to split the team.\n\nEDDY: But yeah, to kind of just come full circle, I do believe, you know, that there should be a balance, you know, on standardization, and there's an argument to be said for both. \n\nTAD: Do you agree with that assertion that I just made that the bigger the team, the more standardization that you'll need to have in order to have that team work together?\n\nEDDY: Well, the thing is, it's easier to enforce, right? So, if you have a standardization on code, then that just becomes an expectation, you know, regardless of if you're new, or you're a senior on the team, et cetera. So, being able to enforce certain conventions, you know, pretty much guarantees that that philosophy is being followed, you know, and it's easier to review and test.\n\nTAD: Yeah. Well, I guess what I'm asking is, if I'm a team of one, how much standardization do I need? Do I need any? \n\nRAMSES: Zero.\n\nTAD: If I'm a team of two, how much do I need? If I'm in a team of 30 [laughs], do I need to add a lot to my linting rules if I'm on a team of 30 than if I'm on a team of 2? Or we can just say, like, \"Oh, we kind of like it this way,\" and then we go with it?\n\nEDDY: I feel like --\n\nTAD: I'm kind of just throwing that out there because -- \n\nEDDY: I feel like Ramses has an awesome...you have an interesting opinion, right? Because for the listeners out there, Ramses is part of a smaller team than what me and Tad are in. And his team they finally have been able to claim their own service. And so, they've been able to sort of have a say on the way the structure of that service is written, you know, and architected. So, I feel like you may have some opinion on that, Ramses. \n\nRAMSES: Yeah, I think the standard should be the same, regardless of the team size. It would be slightly more difficult to communicate the standard and probably to enforce it on a larger team. It's just when you have to communicate to, you know, 30 individuals instead of just 2 or 3, it's a little bit more difficult, but it should have the same standard, I would imagine.\n\nTAD: The same standards because we're all part of the same company? Same standard just because that makes it easier for you to work with your, you know, coworkers? What's the reason behind that? \n\nRAMSES: Probably for easier to work with your coworkers. And it could be the same company, but in our organization or in our department, we have different teams that work on different tech stacks, so creating that standard between, you know, Ruby and Java or whatever, it's a little bit different. But all the teams that are using the same stack, I mean, they should generally have the same standards. \n\nTAD: Just because it reduces friction or communication overhead, or what's the...? \n\nRAMSES: I'd say because it...yeah, it does reduce friction, and it increases cross-team collaboration. Like, if I wanted to move to a different team, if we had the same standard, it'd be really easy, or easier at least, if we were using the same stack. \n\nEDDY: I agree, because it's like, cool, I'm used to using this certain gem to do a certain logic, and, suddenly, oh yeah, this service doesn't. They'll use a different gem. And you're like, oh, okay, cool, now I have to do some reading on their documentation [inaudible 49:09] how this works, right? Or, like, cool, we do our schema validation differently, you know.\n\nAnd so, suddenly, now you're like, okay, now I have to read that documentation in order for me to come up to speed. And it's sort of like, if we can all agree on standardizing on what gems are being used, what libraries are being used, et cetera, it will make it loads easier to jump across teams. \n\nTAD: What about everyone puts their documentation in the same place?\n\nEDDY: That would be in an ideal world. \n\nTAD: Because I know some teams put it in the docs directory, some people put it in the README, but some people put it in the Wiki, some people put it in Confluence, right? \n\nEDDY: Right. So, yeah, in essence, I can agree on both [chuckles], on non-standardization and on standardization. \n\nTAD: Okay. Well, I think we're at the end of time. So, final thoughts: how much standardization do you favor, and what areas do you think you favor standardization in?\n\nEDDY: I think, as far as software is concerned, it should be pretty much free game. \n\nTAD: Software like the tools that you're using? \n\nEDDY: Yeah. For example, like, if you're trying to do some changes on, like, messaging for, like, Kafka, there's, like, a gazillion [laughs] software clients that do that. And you're like, okay, cool, we're all forced to use Lenses, or, like, Conduktor, or something. And you're just like, ah, but, like, I've never used it before. This sucks, you know? And, like, now you have to learn, like, a new...so, like, that just causes a little bit of friction.\n\nSo, like, I feel like I'm in the camp I'm like, cool, choose your own IDE. Yeah, choose your own Kafka consumer. Oh yeah, choose your own whatever, as long as you pretty much get the same result. At least that's my current opinion, and it could change tomorrow [laughs]. \n\nTAD: All opinions subject to change with new information and evidence. Ramses, what do you think? How much standardization do you like, and in what areas do you like standardization? \n\nRAMSES: 100% conformity. Everyone uses Vim. \n\nTAD: [laughs] Everyone standardizes to what your preferences are. \n\nRAMSES: Or to Nano. I guess if I'm going to make everyone's life hell, I might as well make it as worse as possible. \n\nTAD: Yeah, the least common denominator thing that everyone equally hates is what we'll choose.\n\nEDDY: And if they don't like Vim, they're wrong. \n\nRAMSES: No. Like Eddy said, there's a balance to standardization. I don't think it's necessarily an easy answer, depending on what you're trying to standardize. But I think, you know, at least having the conversation and trying to make a decision is probably the right thing.\n\nEDDY: Agreed.\n\nTAD: Yeah, I think after this discussion, and probably related to what Dave was saying earlier about convention versus configuration, is, I think I do like the hybrid where you have a recommended way, and you standardize around that recommended way, but you don't necessarily enforce the recommended way.\n\nIt's like we recommend Docker, but if you want to run Kafka natively, then knock yourself out, but you're not going to get the support. Or we recommend that you, you know, do X, and if you're not going to do X, then knock yourself out but realize that you're going to have a harder time with it. Cool. I think that's it. \n\nEDDY: Thanks, everyone, for listening to us rant. ","content_html":"The panelists explore the tension between conformity and autonomy within software development teams and the balance of standardization and flexibility in coding practices. The conversation revolves around their efforts at Acima to standardize pull request assignments and the dual roles in code reviews, highlighting their team's unique approach of using a chatbot compared with other teams using GitHub Actions. They also discuss the challenges of integrating new developers into standardized practices, especially for teams with a lot of junior developers.
\n\nEddy emphasizes the importance of standardization across teams to reduce the onboarding time and confusion when developers shift between projects or teams and advocates for company-wide code standardization to facilitate easier transitions and maintain consistency. Dave discusses the implications of standardizing tools versus processes and how each choice affects team operations and risk management strategies.
\n\nThe discussion turns philosophical, pondering the broader impacts of autonomy in development practices. Dave and Tad debate whether autonomy should extend to individual tool preferences or be constrained by team and organizational standards to ensure cohesive and efficient operations.
\n\nTranscript:
\n\nTAD: Hello. Welcome to another episode of the Acima Development Podcast. My name is Tad, and I'm the one who's going to be hosting today. Today we're going to be talking about conformity versus autonomy, or another way to put it is, how much do you need your devs to standardize versus how much flexibility are you going to allow them to have? Today I have with me, Eddy.
\n\nEDDY: Hey, guys.
\n\nTAD: And Ramses.
\n\nRAMSES: Hey, guys.
\n\nTAD: Sergio.
\n\nSERGIO: Hey.
\n\nTAD: Dave.
\n\nDAVE: Howdy, howdy.
\n\nTAD: One of the reasons why this is kind of timely for us is because we have several different services, several different teams here at Acima, and we've been making a push to standardize things between the teams and to become a bit more uniform between the teams. So, I have some examples, but I thought I'd throw that out. What are your thoughts? What are some of the things that we're trying to standardize on right now, and how do you feel about it? Or maybe I'll just go first.
\n\nSo, one thing that we're trying to do is standardize how we do assignments of pull requests. And the team that most of us are on, actually all of us on this podcast today are on, we have two different roles that we have when we're doing code reviews, where one of them is a code reviewer, and that person just reads through the code, looks for anything weird or unusual, maybe asks some questions, and then they give the thumbs up: yes or no.
\n\nThe 2nd role is a full reviewer, and that person goes through, reads all the code, but then they also go through a bunch of steps to actually exercise the code and assure themselves that that code is working. And that works great for us because then we have two people who are reading the code and two people who are then QA-ing the code because we also have a third QA person. But the other teams don't do it that way.
\n\nWhat we've done is we actually wrote a chatbot that would manage our assignments for us so that we get a mix of people doing the reviews. And not everyone gets back-to-back full reviews because, you know, you can skim through code, maybe on a PR, and that takes you 5 or 6 minutes. But it might take you 30 minutes to actually go through and exercise all that code. And so, because full reviews are a little more time-consuming, we like to make that a little more fair.
\n\nAnd having our chatbot and having coded up a way for us to do our code reviews works great for our particular team. But our team is the only team that does it that way. So, the other teams are all doing GitHub Actions. So, we're trying to reconcile the fact that we have a chatbot, and the other teams have GitHub Actions. I think chatbot is better, but we're outvoted in this. It's not quite a democracy. So, we're currently trying to figure out how to get GitHub Actions to work for our needs.
\n\nEDDY: I think that standardization for code reviews and testing, et cetera, is super crucial, right? Because what happens if you pick up...and I don't know if it's common practice in other companies to allow a developer to just clone the repo that the other team works on, and then just do the code change, and then just assign it [inaudible 03:35]. I don't know how common that is. But I do like the idea that Acima facilitates that. And having a standardization, I think, is important company-wide, right? So that you're not daunted with different team dynamics.
\n\nDAVE: I think there's a thing to look at here as well that the way our team works and the other teams work we're talking about standardization of, like, generic process, right? It's like there's this implicit mapping from, like, GitHub teams to their team that isn't present on ours. So, it's a struggle for us because we do things a little bit differently. And we sometimes wonder, okay, do we want to standardize on a tool, or do we want to standardize on process? And, in this case, the processes map to tools that are different, right? That don't cooperate with each other. Yeah, it's a sticky issue. Like, either one of the tools has to be upgraded so that it can do both, or one team has to change process.
\n\nEDDY: I think it's important to also distinct this, you know, that the Atlas team mostly comprises of junior developers, I do want to say, like, a good chunk of that, maybe half of the pie. Maybe that's deviated since, but historically speaking, the team that we are representing for most of us today are from the Atlas team, which is the name, right? And we adopted the idea of a full review and code review in a way to sort of make sure, you know, that the code changes are solid. And if you have a junior developer pushing out code, I would argue that the probability of a bug, you know, being released is greater since they haven't had the full exposure as a senior developer.
\n\nSo, the reason why our team deviates a little bit more than others is because of how many developers, one, we have and, two, how many of those are actually junior developers. So, I think that is an important distinguishing factor to give context on why we have different procedures.
\n\nDAVE: Yeah. It's a weird thing to draw it back to, but in my mind, it all comes down to how risk-averse or how you mitigate risk on your team. I've worked in shops where everything had to be reviewed, double-checked, super QA'd, jots and tittles because there's finance in this code, like, SOC 2 compliance, where whoever wrote the code cannot deploy the code. And I've also worked at a company where we had, you know, PHI and really sensitive data. But we had the agile mentality of if you want to make a feature happen, you own it. And if that means going into another team's project and into their repo across the building, that's fine because they're doing it to us.
\n\nAnd the mentality at the company was if you need to change something, you go to that team and say, "Hey, I need to add this feature." And, usually, somebody on that team will say, "I can help you with that. I own that piece, and I'll be happy to walk you through it." But then they walk you through it, and then in that code, you did your own deploys. Like, you walk it all the way to production. And the risk mitigation there was if something goes wrong, you own it. Nobody else can handle this for you.
\n\nThere are other places, like when you've got a team full of junior developers, where you can't own this. If this blows up, you're going to need, for lack of a better word, an adult to come help you. You're going to need a responsible adult, to put it that way. That way, we can exclude me from that group. You need a responsible adult to come, you know, fix the server for you because you took it down. And this happens anywhere you have people that have, like, principle of least access, where developers can't manage stuff, or SOC 2 where you can't do the deploy. And so, all the processes kind of vary.
\n\nTad, you mentioned at the top that we were talking about, like, when do we allow autonomy, and when do we want conformity? And, in my mind, I think it comes to...and this is, again, more risk mitigation, but it comes down to how much of your autonomy is going to affect the people around you, right? It's like your autonomy stops at my IDE, that your feelings stop at my rights, or your rights stop at my nose, or something like that. And so, we'll see people that it's like, if you want to develop on Emacs, or Vim, or RubyMine, it doesn't matter. If you want to ship this straight to production without QA, that matters. That's a process that, you know, that there will be people at your door saying, "This is unacceptable risk."
\n\nEDDY: Well, it also depends on how robust your QA integration really is and how big of a change that really...or the impact of that change really is, right? Like, for example, I'd argue that if you're pushing out, like, a simple text change, does that really warrant a QA assignment? Probably not. They can probably allot...their allotment for them would be better elsewhere, right?
\n\nTAD: I was going to ask, I think another part of it is can you pull a developer off one service and put them on another? Because if other developers have been pulled off of our team and need to do a PR against our codebase and they don't know how to do it, right? Because it's not the same process to do a PR on their team, like, we have certain standards. Like, it's small, and we have a full reviewer, and a code reviewer, and a QA person. And those aren't the same standards on another team.
\n\nAnd so, you know, it's like Eli Whitney in the interchangeable parts, like, can you move devs between different pieces of your codebase? Or can you move devs between other teams? And if you don't have some standard there, then there's friction. There's an impedance, right?
\n\nDAVE: Yeah, that's fair. The shop that I was at where we had...you would...in fact, we literally had developer hostage exchanges where you would literally go work on another team for, like, two weeks, you know, for a sprint and then come back, and they would send somebody in your place.
\n\nBut, like, if you went to, you know, this other team and said, "Hey, I need to add this feature," you would have somebody that would be your Sherpa and would be your subject matter expert and say, "Okay. Let me show you the part of the project you're going to be working on. Let me show you what specs are covering that code. It's going to come in here. Data's going to go here, here, here, and here. You're following that? Okay, cool. When you hit here, you're going to have to...that's your feature. You have to change that. Change this. Don't touch that. Anything else is fair game. Go nuts."
\n\nAnd then, you'd go off and write it and come back and [inaudible 09:28]. So, basically, you would get that basic grasp of, like, the lay of the land. At that particular shop, we would not just throw you cold into 100,000 lines of code and say, "Good luck. Have fun." That's not fun.
\n\nEDDY: I actually want to advocate for company-wide standardization for code for that same reason, right? When you get dumped into another codebase. And I think at Acima, and Ramses, you can kind of correct me if I'm wrong here, but it seems as though each team adopts their own philosophy. It's always been that way from what it seems. And the code is a great example of that, right?
\n\nRAMSES: Yeah, totally different between different teams.
\n\nEDDY: To me, that's kind of difficult, right? Because I'm a junior developer who's going over a year, right? Just pushing out code changes and stuff. And it was a bit of a [laughs]...so the codebase that I currently work on it's kind of grown a soft spot for me because I know where everything is, you know, like if I need to add a new client, I know where that is. Cool. If I need to do this, oh, I know where the service object lives, whatever. And I can just reference it, and I can be very productive.
\n\nI did a change, like, two weeks ago, give or take, on another repository, another service, and it took me, like, God, I don't know, like, half the day to really understand, like, what they were doing before I could do anything. So, it's like, for me, it's like, I felt super, super, like, I was wasting a lot of time just trying to figure out, like, how that codebase works before I even went ahead and wrote anything or implemented any changes.
\n\nSo, I can't help but wonder, if we standardize conventions for code company-wide, it will just be, like, a seamless transition to go and make another change, right? But at the same time, you run into the idea of, like, standardizing something that you are not a big fan of, right? And so, I guess it's kind of, like, a give and take.
\n\nDAVE: Yeah, wanting to have everybody work on the same standard that's a lovely idea. That and five kilos of cocaine will have you creating RuboCop.
\n\nSERGIO: But it has the bad side. It's like, if we standardize something, five years later, we figure out that this is not the right solution. It's like, this happened to us. We have this tool that we were kind of removing right now. I guess Tad is talking about that. I don't know if I can talk freely about that here, but it's like, we have this tool we built. I don't know who built in the team this tool. And we have a bunch of services using this tool, and we need to remove this, like, five years later. And it's like, whatever you make right now is going to be outdated in five years. So [laughs], standardizing is good, but sometimes it's [inaudible 12:09], you know, yeah.
\n\nDAVE: I think it's important to be careful not to set the standard for all time. We spend so much time as developers trying to tie the hands of future us, which is dumb because future us is always, maybe not smarter, but always more experienced, always older than us. And, honestly, legitimately, my biggest frustration as a developer is when I have tied my own hands. I'm like, I need to change the way this works.
\n\nI had a knockdown drag-out with a developer once over whether or not you could order the keys in a hash because a hash is a mathematical function, and the set of keys of a hash is a set. And sets, by mathematical definition, must not have an order. And I'm like, yeah, but the customer wants stuff to come out in the same order that they put it in. Customer gets what they want. Don't try to teach the customer set theory, right? It's tomatoes might be a fruit, but you don't put it in fruit salad. Don't do that.
\n\nEDDY: Yeah. Can't you organize a hash, though? I'm pretty sure you can, and it's --
\n\nDAVE: By default, Ruby and Python they keep a list, an ordered list as things get put in. Yeah, they have a hash for quick access, and then they have a list for ordering.
\n\nEDDY: So, it seems like a pretty trivial change, right?
\n\nDAVE: But ten years ago, you could just about have an honest-to-gosh fistfight with the math majors over whether or not you should be allowed to do that. If you can't guarantee something, there are programmers who will spend a lot of time locking things down so that they can guarantee that you can't, which is not the same thing as saying, "You can't guarantee." They want to guarantee that you can't. Now it's locked down. It's perfect. It's airtight. There's no way anybody can do anything wrong with the system. The problem is that every future change is something wrong with the system, right? It's something that hadn't been thought when that first mathematical formula was locked down.
\n\nTAD: I was just going to go back to ask Eddy some follow-up questions. So, first of all, when you say having the same conventions, is that RuboCop, or is that style guides, or is that training? Or like some of the people mentioned already, what if you hate those things that the other team does and you're glad you're not on that team?
\n\nEDDY: [laughs].
\n\nTAD: And you can do it your own way on your team. And maybe a related question that I'm going to throw out to the group is, is there some value to having competing ideas? If everything is genetically the same in your population, then that means some plague can come through and kill everything, right? And so, diversity does have some value where you have competing ideas, and the ones with merit kind of float to the top over time, and then they fall out of disfavor, and new ones kind of clobber those.
\n\nEDDY: Well, I think, okay, so it's more of a selfish ask for me than anything else, and I'll preface by saying that. Because, again, like, that was my first exposure contributing to another repository to such a degree, testing against a different codebase. And, again, like, the fact that I had to spend, like, half the day, you know, figuring out, like, their placement, you know, like where they locate a bunch of their code and stuff, and then how they write it; their style is a little different, too.
\n\nAnd so, selfish me would just be like, cool, if we can all just agree on, like, being explicit with our return nils [laughs], you know, like, and that's just adopted across the board, you know, you'll just look at it, and you're like, "Okay, yeah, cool, that makes sense." And I wouldn't have to stay there longer than I need to trying to figure something out, right? Or, like, using optional params, you know, like, in our team, we prefer it. We love it, you know. But other teams are like, eh.
\n\nOr, like, a really hot topic is, like, factories versus mocking, you know, it's sort of like...and so, for me, it's like, if we can standardize that, you just know what to expect when you go into the other team, you know. And you don't have to worry about, like, understanding their concepts, especially if you're just there to make a simple change. Like, if you're just there to do, like, a simple change that you need to work and they don't have the resources on their team to do it, you know, suddenly, your task is two times or three times longer than it would have taken the other person to do it, right? And it's just kind of hard to do that, you know, if everyone has their own lick.
\n\nTAD: I'm curious: are there some things that we maybe should standardize on and some things that are just trivial but we should standardize on? Meaning, we're always going to paint our bike sheds red, and that's just our standard color, right? So, for example, I know that we've had, in our codebase, like, four or five different HTTP libraries. And really, all the HTTP libraries do the same thing. They're a little bit different flavored, but they all make POSTs; they all make GETs. They all take a URL, right? Like, there's not a whole lot of difference. And so, would something like that make sense to standardize across all the teams? Where it doesn't really matter, but we should pick something? Are there things like that that we should be considering?
\n\nEDDY: I've learned that if Rails can do it natively, use the Rails convention and don't try to get fancy [laughs].
\n\nDAVE: Basically, it's the same thing. It's like, bike sheds are red until further notice, or unless specified otherwise for a good reason, right? So, it's like, you can go to the water cooler and talk about how you should do it all day, what color do you want to paint it. That's fine. It's going to be red, unless there's a really good reason, and that's fine.
\n\nAnd for, like, HTTP, my out-of-pocket answer is, yeah, you should standardize because, you know, convention over configuration. Where we run into trouble is when we have convention and screw your configuration, which is kind of where Rails is kind of headed. It used to be, like, Rails 2, Rails 3, man, you could change anything. You could back that thing onto a wacky data store and just, da, da, da, all kind of...and everything was super configurable. And most of that's still there, but it's getting more and more complicated and more ceremonial to change those things.
\n\nThe thing, specifically with HTTP, I love the HTTParty gem. It's the most simple, straightforward, like, httparty.getURL and response. And you're just done. There's no setting stuff up. There's no socket handling, da da da. Just do it and go. And most like Faraday and the other ones will, Excon, they'll let you do that, too, but it's a little wordier. But HTTParty had, at least as of, like, 2017, had a threading bug. I want to say it used green threads, which is Ruby's internal thread manager, which runs inside one system thread, so it doesn't thread well. You stack up ten threads, and it's exactly as fast as running one thing ten times in a row. There's just no speed-up whatsoever.
\n\nAnd so we switched to Faraday, which at the time did not have just Faraday GET. Like, Faraday 1.0 didn't have that. I could be wrong on that, but I didn't see it in the code. It was always Faraday dot connection do, and then inside the block, do your thing. It was ugly, but we needed it for performance. And so, that's an example of no, this bike shed has to be blue. It can't be red. It has to be blue.
\n\nEDDY: You know, I'm starting to think...as we've been talking, I'm trying to think of all the things that we can typically, like, standardize. And, like, some of that is enforced by RuboCop. Is it not? I mean, most of that should be enforced by RuboCop, assuming that your repository uses it, right? So, it really is just a matter of all adopting the same rules.
\n\nTAD: The same linter and the same rules for your linters.
\n\nDAVE: And to be clear, I love Rubocop. It's just I want to kill some of the cops that we favor as a team. I'm like, I hate that we made this choice.
\n\nEDDY: [laughs] I agree. You know, what's crazy is I used to be a huge fan of comments, right? And, like, anytime I wrote a function, you know, I found myself writing a comment about it, even though it was pretty self-explanatory. Until someone basically told me, like, "Your code should be explaining it to you, you know, from the moment you read it." Like, you shouldn't have to dig into the nitty gritty to be like, "Oh, that's what you're doing. You're doing something really fancy and stuff."
\n\nSo, someone told me, and I can't remember who it was, and I kind of want to put them on the spot because, [laughs] like, that's rang true for me forever. It's pretty much what they said. It's like, if you find yourself making comments to a code, it probably means nine times out of 10 that it's more complicated than it should be, and you should consider refactoring. And that's rang to me true, you know, and for a while.
\n\nTAD: I've had an exact opposite experience where people tell me, "Oh, my code is so readable. It doesn't need documentation," and I beg to differ.
\n\nEDDY: [laughs]
\n\nTAD: I go in...and, like, "I don't need to document my code. It's self-documenting." And when I hear a phrase like that, I cringe.
\n\nDAVE: To steal a joke from [SP] Louis C.K., readability, readable, you know, writing readable code, it's like being called a jerk. If you say, "I'm not a jerk," you don't get to decide that. Other people get to decide that for you, right? So, if somebody comes to you and says, "Your code is really readable. I don't think it needs comments," then, yeah, especially if your comment is literally, do the thing, and then the line of code is very clearly do the thing.
\n\nIt's especially from, like, the old C and C++ days, where you had to sneak up on your solution. You had to trick the compiler into giving you what you wanted as a side effect of the math that you were throwing at it. So, we had a piece of code go by this week where we have a certain number of products that can be in a list, and there was just one thing. There was only one kind of product. Well, now there's two things that can be in it.
\n\nAnd so, somebody stuffed in a bit of code that said, "Hey, if the list of products is longer than one, it has to be this combination." And I'm looking way down the road map, like, six months, nine months, ten months when we add a third product or a fourth product to this thing, and this is going to be wrong. Greater than one that's sneaking up on the side effect of, well, if you have two products, you've got more than one. Therefore, it's this comment.
\n\nAnd Sergio and I changed it so that it was like, "Hey, if you have this product and you have that product, then it's that combination of those two products." It's the same code. It does the same thing, but now I think it kind of doesn't need the comment on it, def combo item has item 1 and and has item 2. That's literally the code. I'm changing the names of the products to be a little vague here, but other than that, that's literally what the code is.
\n\nTAD: I should maybe clarify what I like in a comment. If you give me the mindset you were in when you wrote that code, the reason you made the decision, why you took the approach that you did, I love those type of comments. If it's, this adds A and B together and returns the total, then, to me, that's a useless comment because I can see what it does, but I rarely know why you chose to do it that way, what the trade-offs were, what your mindset was, things like that, when you wrote the code. And those types of comments are rare but invaluable.
\n\nDAVE: Yeah. Like, you have a thing that's like, A add B using this special adding method. So, you've got this, you know, conglomerate A and B, and the comment is, "Level four figuring compliance." And you're like, oh, that's why we have to use the custom thing to do it, right? And otherwise, it would be just this weird addition.
\n\nEDDY: You know, Ramses, you wrote something that's ringing true for me right now, and I kind of want you to elaborate on that, if you don't mind. Because I, too, agree with your sentiment, but I want to hear your opinion behind it.
\n\nRAMSES: Regarding the class-level comments?
\n\nEDDY: Yep.
\n\nRAMSES: Yeah. Well, there's just a lot of times, like, you'll see in a model, or a class, or whatever it's basically just a repeat of what the class name is, like, "Representation of user." Yeah, that's what your model is.
\n\nDAVE: It's just repetition at that point, and you're only putting it there because RuboCop demands the documentation. When I document a class, I try to say why. Why does this class have to exist, or what purpose does it serve? And you can...yeah, you can have...I can't think of an example off the top of my head, but you get the idea that the comment should not just be if you've got, you know, class particle accelerator and a comment that says, "A class for particle accelerator."
\n\nEDDY: Yes [laughs].
\n\nDAVE: It's completely useless, right? But if you've got a comment that basically says, "General class interface for all accelerometrox products," then you're like, oh, okay, now I know why we have a particle accelerator class.
\n\nTAD: So, going along with this, would you guys advocate for a standard commenting style? Because there's people that use YARD. There's people that use RDoC. There's people that say, "You must state your inputs, your outputs, and give a why for this class, or this method, or whatever you're commenting."
\n\nDAVE: I would say, "Yes," if it's high ceremony, if the interface needs to be...like, if it's a Conway's...[chuckles] Conway's wall, not Conway's Law, Conway's wall, that's like, another team is going to come use that piece of code. It should be documented like the old MSDN libraries where you could hit F1 anywhere in the code in Developer Studio and get, you know, a page of documentation and examples, and gazintas and gazotas, and every possible thing that this thing can do. Yeah, document the snot out of it. If it's a private method buried down deep in some sidebar class that only affects your specific domain in that module of that sub-piece of the code, I don't know, maybe not.
\n\nTAD: So, are you saying for things like our shared gems you would advocate for some kind of commenting standard?
\n\nDAVE: I feel like you might be baiting me into a trap here, but at the risk of sounding like a complete hypocrite, yes. What I will say about us hypocrites, [crosstalk 25:56] criticize hypocrites how you want, but we do have higher standards than you.
\n\nEDDY: So, you know, it kind of begs the question, right? So, like, standardization and comments, I feel like we don't have that, and I'm not very spoiled or privy to that, right? Because, again, I'm a junior developer, not much of experience in the industry. But I do love hitting, you know, certain logic, you know, and they basically say, "Hey. Make sure you keep this in mind when you make a change here or whatever," right? I love that.
\n\nI love that because they're being super, like, they're being super nice to me when they're saying, "Hey, dude, if you're going to make a change here, like, just make sure you're cognizant about this, this, and this, you know." And comments do that, and they do accomplish that. And so, I feel like we don't have a standard on that, but I feel like we should, right? I think it is nice.
\n\nTAD: So, I'm curious to ask about standardizing on some other aspects and how you feel about it. How would you feel about doing standardization of all of our setup stuff for all of our different services?
\n\nEDDY: Oh, that would be nice.
\n\nTAD: So, would you be okay with forcing everyone to use Docker or some other system?
\n\nRAMSES: Sure, why not? Make the process much easier.
\n\nEDDY: Okay, so I have a love-hate relationship with what you just said, right? Because there are people who utterly refuse to use Docker, right? Because their machine just isn't strong enough. So, like, why not provide an alternative for individuals who just don't have a beefed-up computer, for example? Or not everyone uses the same operating system. And what if your documentation is only catered to a certain OS? Then, at that point, you're kind of like, "Ugh," you know, so I don't think you can truly standardize --
\n\nTAD: Well, you can standardize hardware. You could say, "Everyone must have an Apple laptop."
\n\nEDDY: Wow. Yeah. I didn't realize that that was possible.
\n\nRAMSES: Yeah. Tell everyone to start using Electron products, in-line, editors only.
\n\nEDDY: [laughs]
\n\nTAD: Yeah, like, would you guys be okay with saying, "Everyone uses Linux"? Because that's something that pretty much everyone on our development team would be able to use and that has maybe the best Docker support.
\n\nEDDY: I haven't had an issue with Mac. Basically, anything that I needed to accomplish, like, Mac has been able to provide for me. So, like, there hasn't really been a need for me to be like, oh man, I really wish I was on a Linux [laughs] distro. There hasn't really been a necessity for that. I feel like that's because macOS has just gained so much credibility for development. Am I wrong on that assessment?
\n\nTAD: Well, we have a lot of contractors that have to bring their own laptop. And so, you have the luxury of getting a company-issued laptop. So, you're indirectly advocating that our contractors would go out and buy Apple products.
\n\nEDDY: It's a good point.
\n\nTAD: Standardization has trade-offs, right? It's like, it would be great if we all ran on the same hardware, but then everyone who doesn't have the standard has to go out and somehow now fit to the standard.
\n\nEDDY: I feel like it's easier to enforce standardization on code than anything else. Like, if you're standardizing something on, like, hardware, you know, I feel like that's super trivial, and you may lose potential talent because you're telling them, "Hey, you're forced to use this specific machine, this specific operating system." So, like, for example, I've paired with our contractors who were from India and some of them, yeah, and like you said, they use Linux. They use different IDEs. Like one of them uses Sublime for God knows what reason, you know.
\n\nTAD: Because it's fast and awesome.
\n\nEDDY: [laughs] And the thing is, is, like, you would see him just kind of, like, flow through that seamlessly because he understands that super well. And I'm just like, cool, we shouldn't be forcing you to be using something if your innate flow caters to a specific software, so...
\n\nTAD: But would it make it easier for you to pair with him if you had standard tools and standard hardware and maybe even, like, a standard IDE that you both were using?
\n\nEDDY: Well, I want to confess something on record...Ramses because he's on the call. When we first paired, when I was learning how to code, he would pair with Vim. And for most of the time, like, early on in our pairing, I was like, oh man, I was like, what are you doing? Where are you at? I don't even know what I'm looking at. So, there is a level to that complexity, but I feel like eventually, you kind of just grow accustomed to looking at someone else's IDE, and you just know what happens. You know, I feel like, as wisdom prevails, it's easier to adapt oneself.
\n\nTAD: What about you, Ramses? Side note, Ramses is a Vim user, and he loves Vim. So, I'd like to hear what his thoughts are.
\n\nRAMSES: It'd certainly be easier if everyone was using the same tool in terms of collaboration. If I want to do a live sharing with someone in Vim, it's technically possible. It's not great, you know. It's not a great experience. It's certainly not as seamless as, like, Live Share on VS Code or live coding on RubyMine or, you know, any other tool. If I'm planning on doing a pairing with someone, I'll just open up VS Code. It's easy enough. It doesn't impact my workflow that much.
\n\nEDDY: And to your credit, Ramses, I think you tried using it entirely for a month, right?
\n\nRAMSES: Yeah, I've used it, like, I mean, I've used a wide variety of IDEs and other editors. For the most part, I don't have a problem with VS Code. It works just fine, for the most part --
\n\nTAD: I think the trade-off here is individual productivity, right? If you let developers choose what they want, then they'll choose the most productive, most familiar environment that they have. But if you standardize, then you might be increasing, like, pairing productivity or some other form of efficiencies, right? Like, if our servers are on Linux, they're all running in Docker. And so, if everyone ran Linux and everyone ran Docker, it would make it a lot easier for our DevOps team. So, are you willing to choose the approach that makes our DevOps team sad, Eddy?
\n\n[laughter]
\n\nEDDY: I feel like there's not a right answer [laughs].
\n\nTAD: I'm kidding. No, it's just hard because there's trade-offs with all these things, right?
\n\nEDDY: Yeah, I think, to a degree, there has to be a balance between standardization and not. And I feel like I've been spoiled [chuckles] here at Acima because everyone gets to customize their machine, you know, to a certain degree. You know, it helps them with their flow. So, like, everyone can select whatever IDE they want to use. As long as they get the code out, it doesn't really matter. Or, like, some of us prefer to use different Git commands, you know, when rebasing or pushing stuff up. Like, that's fine.
\n\nLike, ultimately, it accomplishes the same thing at the end of the day. So, I like the fact that I'm not micromanaged that I have to choose certain hardware and, like, certain software. Because at the end of the day, the one who's pushing up the code changes is the developer, right?
\n\nTAD: I'm going to hit you guys with another one. How do you feel about standardizing on time? Meaning you do things at a certain time, and other people do things at a certain time.
\n\nEDDY: What do you mean?
\n\nTAD: Meaning, everyone starts their day at the same time. Everyone has their meetings at the same time. Everyone pairs at the same time. Everyone takes lunch at the same time. Everyone codes at the same time. Everyone does PRs at the same time. You could have a pretty regimented schedule and make sure that everyone's pairing at the same time, which means that you never have to coordinate with people to say, "What's your schedule? What's my schedule? Oh man, we're not going to be able to get together on this." Because it would always be free. Like, you could really standardize when certain things happen and how things work for your team.
\n\nEDDY: I don't really like that. And I'm just going off of my first reaction here. But I get hungry in different times than other people. So, like, what happens, like, if suddenly we're all forced to have lunch at 12:00 p.m.? But I'm like, "Oh, but I usually don't eat till, like, 2:00 p.m." Suddenly, it's just I'm not being productive because now I'm having to force myself to go against whatever my habits are.
\n\nOr, like, what if I'm like, I'm not very productive waking up at 7:00 in the morning and working at 8:00? What if I work better working from 9:00 p.m. or 9:00 a.m. to, like, 7:00 p.m., and that's the schedule that I prefer? And, like, as long as you get the work done, it really shouldn't matter, I feel like. And, like, time management should really be left off to the developer, in my opinion. Just, like, from the first reaction, I feel like the developer should be the one who pretty much decides the time management.
\n\nTAD: Okay. Ramses?
\n\nRAMSES: I think I am in the opposite camp, at least for the most part. I don't really care when other people start their day. If they want to start it later, end it later, it doesn't really faze me. But I think the parts of standardization that's good for time management is where...and this is something that we follow as an organization, where we have, like, a cadence, and we have structures like, okay, all teams do stand-ups in the morning, you know, between, like, 9:00 and 10:00, or whatever, you know.
\n\nAnd then, in the afternoon, okay, that's developer coding time, so no one else can schedule meetings during that time. Like, I mean, you could probably do pairings with other people during that time because that's when you should be productive, but it's not time for engineering-wide meetings or team meetings. Those are kind of blocked out at very specific times. I think that's helpful for team collaboration.
\n\nTAD: Yeah, I mean, I've kind of been playing devil's advocate or being a little bit provocative here, but the reason it did come to mind is because we did, a few months ago, agree on a team cadence where certain things would happen at certain times just because they found that they couldn't schedule things. They couldn't plan things because they never knew when people would be available or not. Or, on the other side of that is, you didn't know when you would have free time and when you'd get pulled into a spontaneous meeting, right?
\n\nEDDY: Right.
\n\nTAD: So, are there times that you think should be standardized, like meeting times, things like that?
\n\nEDDY: [inaudible 36:52]
\n\nTAD: Maybe not lunch. Maybe you don't dictate lunchtime.
\n\nEDDY: I want to go on record and say I don't really like meetings, personally.
\n\nTAD: [laughs]
\n\nEDDY: I have limited attention span.
\n\nRAMSES: I don't think anyone [inaudible 37:03] meetings.
\n\nEDDY: Dude, like, if I get put...and this is just me, like, if I get put in a meeting that's an hour long, after the 30 minutes, you know, I'm kind of wandering, doing something else just because it's kind of hard to focus [laughs]. So, maybe standardizing meetings so that it's short and concise sounds kind of nice.
\n\nTAD: How would you feel about something like meetings are standardized at 50 minutes long, and you always have to allow for a 10-minute break? You know, meetings always start on the hour or on the half-hour, and they are always, at most, 50 minutes long. And you always have to give a 10-minute gap before the next meeting.
\n\nEDDY: That sounds awesome.
\n\nTAD: Personally, I've been in back-to-back to back-to-back meetings where I've had five hours straight of meetings. And my brain is burned out by, like, hour three or hour four. So, would that kind of standardization be beneficial where you standardize the length and the style of the meeting, or maybe even the content of the meeting? Do you say, "If you're going to have a meeting, you have to have an itinerary for that meeting. You have to give everyone the bullet points of the meeting beforehand and say, 'This is only going to be 50 minutes'"?
\n\nEDDY: I would agree.
\n\nRAMSES: All meetings need to come prepared with a slide presentation.
\n\nEDDY: [laughs].
\n\nRAMSES: And it has to fit on three slides only.
\n\nEDDY: You know, I'm trying to think because, like, I've looked at other code, right? And I'm thinking, huh, the other things I've noticed that they have conventions on is, like, camel case versus snake case and, like, naming for your functions and methods and variables and stuff, you know. I think we can all agree that we share naming conventions for that. Some of the really silly ones are, like, oh, your characters can't...your line can't be longer than X amount of characters. That's where I'm sort of like, ah, you're forced to rewrite the code differently and probably run the risk of it looking worse because you're trying to fit [inaudible 39:13]
\n\nTAD: Well, arguably, if your line of code is 120 characters long, it's maybe a little too complicated. It could be broken into maybe a few lines of code.
\n\nEDDY: Yeah, maybe, maybe. Unlike silly conventions that, you know, that we have in our codebase, where I'm just like, oh, man, but it looks better with the unless [laughter].
\n\nTAD: Yeah. It is nice to read it all as one complete thought rather than three partial thoughts, right? I mean, there's kind of something going on sometimes in the code, where you want to break it into, like, it almost compares to, like, sentences and paragraphs. And you're like, ugh, like, I just want to express it in a certain way.
\n\nEDDY: Yeah, I agree. You know what's crazy? Is because sometimes those standardizations aren't present, I've learned to look at a code, and I'm like, oh man, this reads just like Ramses.
\n\nTAD: [laughs]
\n\nEDDY: And so, like, I'll go to the code. Like, I'll do a git blame. You know, I'm like, oh, it was Ramses. You know, I can just pick out, like, people's styles, right?
\n\nTAD: Do you think it would be better if you removed that fingerprint, where you can't quite tell the style?
\n\nEDDY: Yeah, right? So, like, if you're standardizing stuff, then it also removes, like, ambiguity because everyone's following suit, you know. And, to me, it's kind of fun to just kind of look at a code block and be like, oh yeah, this totally reads like Tad, you know [laughter]. And you're like, 9 times out of 10, you know, like, you're right.
\n\nTAD: I'm curious: how do you guys feel about standardizing on policies? For example, what if you had a policy, "No deployments on Fridays"?
\n\nEDDY: You know, a wise person once told me a little while back, and they said, "If you're afraid to deploy your code on a Friday, then your code is probably not ready to be deployed." Like, you got to be confident with your changes, and if deploying on a Friday raises eyebrows, then is it really ready for production? Probably not. I mean, would you both agree with that sentiment?
\n\nTAD: Well, I guess, just to clarify, so your argument is that perhaps standardizing policies is a symptom for a different problem.
\n\nEDDY: Maybe.
\n\nTAD: So, in your argument, the problem is we don't have confidence in our processes and our code quality, so, therefore, we make a policy to protect ourselves rather than fix the confidence problem or the quality problem.
\n\nEDDY: I feel like that's not what I said [laughs].
\n\nTAD: Okay. Well, then restate. I'm sorry if I'm misrepresenting you. Go ahead.
\n\nEDDY: [laughs] I was just saying, like, it's not the symptom of bad code or anything. It's just a matter of I feel like the reason why some certain teams prefer to not deploy on Fridays is because you do...regardless of how robust that code has been tested, you always do run a risk, you know, of it breaking something, like --
\n\nRAMSES: Yeah. No one wants to work on the weekends.
\n\nEDDY: Exactly. So, it's not necessarily because it's bad code. It's just you do run the risk of it breaking something, and if you do, you're making people work more time than they have to. So, it's more or less just being nice.
\n\nTAD: Are there other policies that you wish that we would implement that we don't have right now? We just barely talked about today in architecture meeting; for example, we floated the idea of...so, just for some context, we have a staging environment where we can deploy things, and kind of test things out, and try things in an environment that feels a lot like production but doesn't break things like production would, and it's a bit of a bottleneck. And so, now we're saying if you're going to take a lot of testing time, save that for the afternoon. And if you're just doing a quick check, do that in the morning because that alleviates a bit of a bottleneck that we've had.
\n\nEDDY: Yeah, I think that's a good problem to solve, right? How do you both feel about standardization on, like, how big a development team can be? If your development team comprises of over 20x, you know, developers, like, how do you standardize, you know, and keep all your ducks in a line, you know, when you have 20x people pushing [inaudible 43:34] on these, right?
\n\nTAD: Yeah.
\n\nRAMSES: Like, Amazon says, like, the team should only be the size that it takes to feed, like, two pizzas, so, like, four or five people generally.
\n\nEDDY: Really? That's their comparison [laughs]?
\n\nRAMSES: Yeah [laughs].
\n\nEDDY: Well, what happens —-
\n\nTAD: Yeah, they say if your team is too big to be fed by a pizza or two, then you need to split it.
\n\nEDDY: But what happens if I can eat a whole pizza? Does that mean that I don't need other people?
\n\nTAD: [laughs] They're theoretical pizza-eating people [laughter]. Yeah, it's a way to not necessarily have a fixed number but more just, like, a sense of, yeah, this team is too big, right? It's kind of more rule of thumb rather than saying exactly five. They're like, "Ooh, we're not going to be able to feed this team anymore." We are maybe too big. It is analogous, to some degree, to, you know, feeding a team, meaning providing work and coordinating that work with the other people, right?
\n\nEDDY: Yeah. And you sort of lose that as the development team grows, right?
\n\nRAMSES: Yeah. Yeah, it seems to be harder to collaborate and for decisions to be made on a larger team.
\n\nTAD: Yeah. And I think just because standardization is kind of the topic, the bigger the team, the more of these protocols, the more of these policies, the more of these standardizations, the more things that you need to make that team work.
\n\nEDDY: You know, I want to do a comparison, and I've never done the research on this. But, for example, if I were to look at, like, a Fortune 500 company, like, I don't know, like Tesla, Google, Amazon, et cetera, how they structure their development teams and how they standardize certain things, I think it'd be kind of cool to contrast. Like, off the top of your head, do both of you kind of have an idea of, like, how they differentiate themselves from startups?
\n\nTAD: I've never worked for a company that big, so I don't have any comparisons.
\n\nRAMSES: Yeah, same.
\n\nTAD: But I think Amazon still follows that rule of thumb that if you can't feed your team with a pizza, then time to split the team.
\n\nEDDY: But yeah, to kind of just come full circle, I do believe, you know, that there should be a balance, you know, on standardization, and there's an argument to be said for both.
\n\nTAD: Do you agree with that assertion that I just made that the bigger the team, the more standardization that you'll need to have in order to have that team work together?
\n\nEDDY: Well, the thing is, it's easier to enforce, right? So, if you have a standardization on code, then that just becomes an expectation, you know, regardless of if you're new, or you're a senior on the team, et cetera. So, being able to enforce certain conventions, you know, pretty much guarantees that that philosophy is being followed, you know, and it's easier to review and test.
\n\nTAD: Yeah. Well, I guess what I'm asking is, if I'm a team of one, how much standardization do I need? Do I need any?
\n\nRAMSES: Zero.
\n\nTAD: If I'm a team of two, how much do I need? If I'm in a team of 30 [laughs], do I need to add a lot to my linting rules if I'm on a team of 30 than if I'm on a team of 2? Or we can just say, like, "Oh, we kind of like it this way," and then we go with it?
\n\nEDDY: I feel like --
\n\nTAD: I'm kind of just throwing that out there because --
\n\nEDDY: I feel like Ramses has an awesome...you have an interesting opinion, right? Because for the listeners out there, Ramses is part of a smaller team than what me and Tad are in. And his team they finally have been able to claim their own service. And so, they've been able to sort of have a say on the way the structure of that service is written, you know, and architected. So, I feel like you may have some opinion on that, Ramses.
\n\nRAMSES: Yeah, I think the standard should be the same, regardless of the team size. It would be slightly more difficult to communicate the standard and probably to enforce it on a larger team. It's just when you have to communicate to, you know, 30 individuals instead of just 2 or 3, it's a little bit more difficult, but it should have the same standard, I would imagine.
\n\nTAD: The same standards because we're all part of the same company? Same standard just because that makes it easier for you to work with your, you know, coworkers? What's the reason behind that?
\n\nRAMSES: Probably for easier to work with your coworkers. And it could be the same company, but in our organization or in our department, we have different teams that work on different tech stacks, so creating that standard between, you know, Ruby and Java or whatever, it's a little bit different. But all the teams that are using the same stack, I mean, they should generally have the same standards.
\n\nTAD: Just because it reduces friction or communication overhead, or what's the...?
\n\nRAMSES: I'd say because it...yeah, it does reduce friction, and it increases cross-team collaboration. Like, if I wanted to move to a different team, if we had the same standard, it'd be really easy, or easier at least, if we were using the same stack.
\n\nEDDY: I agree, because it's like, cool, I'm used to using this certain gem to do a certain logic, and, suddenly, oh yeah, this service doesn't. They'll use a different gem. And you're like, oh, okay, cool, now I have to do some reading on their documentation [inaudible 49:09] how this works, right? Or, like, cool, we do our schema validation differently, you know.
\n\nAnd so, suddenly, now you're like, okay, now I have to read that documentation in order for me to come up to speed. And it's sort of like, if we can all agree on standardizing on what gems are being used, what libraries are being used, et cetera, it will make it loads easier to jump across teams.
\n\nTAD: What about everyone puts their documentation in the same place?
\n\nEDDY: That would be in an ideal world.
\n\nTAD: Because I know some teams put it in the docs directory, some people put it in the README, but some people put it in the Wiki, some people put it in Confluence, right?
\n\nEDDY: Right. So, yeah, in essence, I can agree on both [chuckles], on non-standardization and on standardization.
\n\nTAD: Okay. Well, I think we're at the end of time. So, final thoughts: how much standardization do you favor, and what areas do you think you favor standardization in?
\n\nEDDY: I think, as far as software is concerned, it should be pretty much free game.
\n\nTAD: Software like the tools that you're using?
\n\nEDDY: Yeah. For example, like, if you're trying to do some changes on, like, messaging for, like, Kafka, there's, like, a gazillion [laughs] software clients that do that. And you're like, okay, cool, we're all forced to use Lenses, or, like, Conduktor, or something. And you're just like, ah, but, like, I've never used it before. This sucks, you know? And, like, now you have to learn, like, a new...so, like, that just causes a little bit of friction.
\n\nSo, like, I feel like I'm in the camp I'm like, cool, choose your own IDE. Yeah, choose your own Kafka consumer. Oh yeah, choose your own whatever, as long as you pretty much get the same result. At least that's my current opinion, and it could change tomorrow [laughs].
\n\nTAD: All opinions subject to change with new information and evidence. Ramses, what do you think? How much standardization do you like, and in what areas do you like standardization?
\n\nRAMSES: 100% conformity. Everyone uses Vim.
\n\nTAD: [laughs] Everyone standardizes to what your preferences are.
\n\nRAMSES: Or to Nano. I guess if I'm going to make everyone's life hell, I might as well make it as worse as possible.
\n\nTAD: Yeah, the least common denominator thing that everyone equally hates is what we'll choose.
\n\nEDDY: And if they don't like Vim, they're wrong.
\n\nRAMSES: No. Like Eddy said, there's a balance to standardization. I don't think it's necessarily an easy answer, depending on what you're trying to standardize. But I think, you know, at least having the conversation and trying to make a decision is probably the right thing.
\n\nEDDY: Agreed.
\n\nTAD: Yeah, I think after this discussion, and probably related to what Dave was saying earlier about convention versus configuration, is, I think I do like the hybrid where you have a recommended way, and you standardize around that recommended way, but you don't necessarily enforce the recommended way.
\n\nIt's like we recommend Docker, but if you want to run Kafka natively, then knock yourself out, but you're not going to get the support. Or we recommend that you, you know, do X, and if you're not going to do X, then knock yourself out but realize that you're going to have a harder time with it. Cool. I think that's it.
\n\nEDDY: Thanks, everyone, for listening to us rant.
","summary":"","date_published":"2024-04-24T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/f3f2bd1a-c50b-4e68-817c-8e3f8a92e982.mp3","mime_type":"audio/mpeg","size_in_bytes":33260487,"duration_in_seconds":3161}]},{"id":"cbc02627-2a80-4134-b936-ee60e155108a","title":"Episode 43: Habits 2.0","url":"https://acima-development.fireside.fm/43","content_text":"This podcast episode from The Acima Developer Podcast crew dives into the concept of developer habits, focusing on how habits are formed and their importance in software development. The discussion begins with a recap of the previous episode, emphasizing the \"four laws\" of habit formation—making it obvious, attractive, easy, and satisfying—as presented by Justin. These principles are highlighted as foundational to acquiring and maintaining good habits that can significantly impact one's personal and professional life.\n\nThe conversation shifts to personal experiences and practices that contribute to productivity and good habit formation in a software development context. Matt shares his perspective on taking ownership and how it has been pivotal in his career. He references the book \"Extreme Ownership\" by Jocko Willink, stressing the importance of accountability in software development. David expands on this, discussing how owning the success of a project often involves being open to feedback and adjustments, even if it means stepping back from one's own work.\n\nThe latter part of the discussion delves into Test-Driven Development (TDD) and its role in productive software engineering practices. Eddy brings up the challenge of spending too much time refining projects instead of coding, questioning the productivity of such tasks. This leads to a row on the efficacy of TDD, with several participants, including Matt and Justin, defending its importance not just in writing quality code but also in understanding problems more deeply and fostering productivity. They argue that TDD, when properly applied, not only helps in reducing bugs but also in enhancing the developer's understanding of the codebase, ultimately leading to more productive coding practices.\n\nTransciption\n\nDAVID: Hello and welcome to the Acima Developer podcast. We are doing a part two on developer habits. Justin, you kicked us off last week. I'm going to pick on you again. Give us a quick summary on, like, what are the elements of a habit so that we can kind of just jump straight in. Last week, we spent most of the time talking about, like, why and how of habits, and we didn't get into too many specific engineering habits. \n\nJUSTIN: Right. One of the main things is, and here I'm just going off a table of contents here that perhaps is a good, quick summary, there were four laws that kind of make up a good habit or how you can acquire a habit. And the four laws were: make it obvious, make it attractive, make it easy, and make it satisfying. All of those require perhaps a little bit more work than just the desire to do something. If you actually go through and do what's needed to follow those four laws, you are much more likely to actually acquire that habit and have it make a change in your life. That's, like, the two-minute summary.\n\nDAVID: It's awesome. \n\nJUSTIN: [laughs]\n\nEDDY: I kind of want to, like, punt this to individuals who weren't present in our last just to kind of get, like, a fresh perspective (if you're okay with that, Dave) just to see, like, what other people's opinions are on what makes them more productive. \n\nMATT: I'm happy to talk about it. For those of you who do not know who I am out in GV land, my name is Matt. I'm one of the engineering leads over here at Acima. For me, one of the most important things that has helped me form really good habits over my career is taking ownership. I think it's extremely important in this industry and, you know, just in life in general.\n\nThere's a book, maybe some of you may or may not have read, called Extreme Ownership, written by Jocko Willink, and he was a Navy SEAL, I believe, platoon leader. And he's written a couple of books, but that one in particular really helped me. And the preface of it is that we just need to take accountability and ownership over all of the things that we're doing. And in software, part of that is not getting married to your code but having ownership of your code, have some pride in your code, take ownership of bugs, anything that arises with it. And I feel like that's going to help you write better software and think through your problems up front.\n\nDAVID: I like to think of that by saying I want to take ownership of the success of the project. And sometimes, that means letting somebody rewrite my code or somebody push back on my design because cash flow doesn't care about your pretty, little design. Cash flow cares about whether or not a customer can get through the system. And so, when somebody pushes back on me, even if it chafes, I'm often very quick...and this might be an internalized habit, but I try to be very quick to say, \"What do I really want here? Oh, this hurts, but it's getting me what I want.\" So yeah, I'm on board with this. \n\nEDDY: So, I wanted to kind of throw something out there, especially for people who have more experience than I do. The past few weeks the project that I'm currently working on and one I'm involved in has required a bunch, a bunch, a bunch of requirements in order to finally get some work done and finally start writing some code.\n\nHere's the thing, and here's kind of where my perspective lies is: refinement, at least for me at a high level, isn't productive. For me, I've always defined productivity as how much code you're pumping out, right? Because those are the metrics. Those are what really define you as you doing your work. So, if most of your time is consumed on refining a project, for example, can you really, at a high level, consider that a productivity effort, and does that really help? Can you constitute as that? Is it kind of, like, a gray area between you...it's a given. In order for you to be productive, you need to have something defined in order for you to work, right? So, I feel like I know the answer, but I want to get people's opinions when it comes to productivity.\n\nJUSTIN: Like, a classic bad metric is lines of code. I could be super productive. I could just sit with my hands on my keyboard and just churn out code, but that doesn't necessarily mean anything, right? Like, it has to be quality code that meets demand or does something, right? Like, you can't just say lines of code or how much code I've written. I think if you measure that way, you're going to end up going the wrong direction. \n\nDAVID: Goodhart's law says, \"When a good measure becomes a goal, it ceases to be a good measure.\"\n\nMATT: Yeah, I think refinements are every bit as important as the actual code you're writing. When we get requirements, one of the key things about refining this work with the engineers is making sure they have a good understanding of the problem. Without a good understanding of a problem, you can't solve a problem. And if you front-load your work with a good refinement, make sure that your requirements are defined, and clear, and concise, you're going to write good code. \n\nIt's just like test-driven development, right? If we're writing our tests first with a good understanding of the problem and a good understanding of the outcome, that almost writes our code for us. Versus if we're doing that after we're writing the code, then we're writing tests to pass against the code we just wrote, which is kind of contrary to what we really want to accomplish. Because we don't know if that code we just wrote is meeting the requirements exactly as defined, whereas a good written test will.\n\nDAVID: Mm-hmm. You end up writing the test to follow the code, and if the code is sort of a sideways implementation of what you thought the card was going to do, the test will then become a sideways implementation of the following of it, right? But if you start with the TDD, you're like, no, this is what it needs to do. You also ran into the thing of like, oh, the code is hard to test, and that's because you wrote the code first. If you had started with the test, the code would be easy to test because it would have to follow the test. \n\nEDDY: I have a caveat to that, Dave, and I think...I spoke with Tad about TDD a few weeks ago. And I told him, I'm like, \"How is it possible for you to write a unit test for something, you know, that you don't even know how you're going to write the code for?\" So, it makes it extremely difficult to, like, set up all the instance doubles and all of the mock data and all of the stub data that you need. You don't even know where you're reaching, where you're looking, right?\n\nAnd so, to me, I feel like it's more like a skeleton TDD, where it's like, cool, I can probably get my get, or my it blocks and my context set up the way I think they should be, but that's as far as I've gotten, as far as TDD. I've never actually implemented anything and then wrote the code to pass it if that makes sense.\n\nDAVID: You said one word at the start of that paragraph, and I knew...I'm like, yep, you're headed down the wrong trouser leg of these pants: unit test. A unit test is how you assert that this tiny, little piece satisfies what the whole should do. That's where TDD starts. You write a test to say, \"Does the whole thing behave correctly?\" Then you start breaking down into the pieces, and then you write unit tests against those. You don't write a unit test to say, \"Does this have a callback on the database before save?\" until you have something higher up that says, \"Hey, when I do this, it updates this other thing.\" And so, you come out of...it's a multi-layer approach.\n\nEDDY: Right. So, I had a misconception of what [inaudible 07:58] was, right? And so, like [laughs], when I spoke to Tad, I was like, \"Oh, gotcha, gotcha. So, you're not writing all the branches,\" right? \n\nDAVID: Right. \n\nEDDY: Like, making those branches pass. You're essentially doing, like, this is the happy path. \n\nDAVID: Eddy, I want to sidebar with you afterwards and bang out this idea because you just sparked an amazing thought in my head. And poor Justin is just waiting for us to talk about habits [laughter]. But you just sparked an amazing thought in my head, which is, I think a lot of people push back on TDD because they're like, well, I wrote the code, and then the testing was dumb and stupid, and hard, and after the fact. And they look at TDD as write the dumb, stupid, after-the-fact test before writing the code. It's not going to work. \n\nIt's like, you have to write something different first, and then you're like, oh, if we were just doing that, right? But yeah, I just realized that, yeah, if you see all this stuff, all the baggage that testing and awkward tests are, if you just move that ahead and try to do the awkward testing first, it's much harder to do that. Why would you do that? \n\nENRIQUE: Basically, TDD is it's like a good practice when you have a domain knowledge, what you're doing. Because sometimes, for example, here at Acima, it's been the first time where I work with mocks instead of intensively writing the database when you write specs and start with specs. For someone like me in this context, when I don't know anything about the domain, and I don't know anything about how things are mocked, it is really, really hard. I really need to go into the UI, understand what is going on, go into the controllers, and see that everything is working correctly then I write specs. \n\nMATT: Yeah. Back to your refinement comment, Eddy, if you have a really good understanding of the problem and we're writing stories properly and breaking them down to a level at which I feel a story should be broken down, you don't have to have a whole lot of domain knowledge. You just need to know what's coming in and what you expect out, and if you have that understanding, you can write a test. \n\nAnd you don't have to write the entire test for it to be TDD, right? You know what's going to happen first, so you write that piece of your test. And you should run it, and it should fail. So, you implement that piece, and then you go to the next step. Let's write the next step in the test for it. And you can just step through it that way. And that actually, in my opinion, makes it so you don't require as much domain knowledge to be able to write software in a big application. \n\nDAVID: For me, the secret is to go up a level and identify the behavior that the system should follow. That you can test in a very generic way. It's like, oh, when these things go in, they need to come out sorted. Now you go write a unit test that says, \"Oh, I need you to call the sort method,\" or \"I need you to sort it in the database,\" or \"I need to use a B-tree,\" right? But the behavior is: it should be sorted when we're done, that if I pass in A, C, B, I should get A, B, C out. And how we got from A, C, B to...right? Who knows? We could split the text and pass it through...who knows, right? That's the thing. \n\nAnd I think if you start your TDD with, okay, I need to mock out the database SQL query with an expect an order clause so that it will sort, oof, that's not test first. That's [chuckles]...Tad will call me on this one. That's [inaudible 11:27], which is test after I thought up the implementation, but before I wrote it [laughter]. \n\nMATT: So, and I think that's a good habit to form, right? TDD is going to help us write better code and more accurate to the actual requirement. \n\nTAD: I think when you start out, you're right. You get something, and you're like, I don't really know how to do this. I don't know what this code is going to be, right? And I know, for me, a lot of times, step one is kind of poke around and brainstorm and kind of look [laughs] at where I'm putting the code and what's going on there. But that could be tests, too, right? Like, if I'm exploring the code and I'm testing, I'm like, what does this gem do? What could this code look like? What's the environment that this feature is going to be written in? I could easily write a test that kind of sets that up for me to poke around in. \n\nJUSTIN: One of the things I'm picking up here from TDD, and I've done limited TDD, I'm not as good at it as I would hope, but just if you generalize it to kind of, like, a habit, I think it's worth recognizing that any or most good habits that you think are good habits when you start out at them, you're going to suck. \n\nAnd it is something that you have to realize you may need to push yourself, or do other incentives, or try a different strategy to do the thing to be able to actually make that habit stick. If one thing isn't working for you, recognize that, and then try another thing, or try a different strategy, or talk to people, all of those things. You know, seek out help that helps you, you know, get you closer to where you're going to try to get to the habit. \n\nMATT: Yeah, good habits are hard to form, right? There's a reason that millions of people make a New Year's resolution that they're going to exercise this year. And then, the gyms are totally packed for about three weeks or so. And then they just fall off because good habits are hard to form. And they're worth it though. The effort is worth it.\n\nEDDY: Since we've been talking a little about TDD, and I kind of want to stay on track a little bit, would you go as far as to say that TDD will make you more productive? Assuming you've honed the skill, and it's just, like, second nature. And you're just like, cool, I'm going to do TDD, and that's it. Like, would you compare someone who is more senior, who's already acclimated doing TDD, and categorize that essentially as, yeah, that makes me more productive than just running the...or banging out of the code first? \n\nJUSTIN: TDD itself is like a combination of a bunch of different things, like breaking down problems, knowing what your target is, you know, all those things kind of add into like, hey, I'm good at TDD now.\n\nMATT: Yeah, so look at it from this perspective: if I'm writing accurate tests on a problem that I understand, the likelihood of me introducing a bug into the codebase is much, much lower. So, from a productivity perspective, I would say if I'm introducing bugs into the code because I'm not testing and I don't understand the problems that I'm trying to solve, that is significantly dropping my productivity because I'm going to have to go back to it or someone is and fix it, which is going to take even more time. It's going to take debug time, tracking things down, and then, on top of that, coding time. So, if you can avoid all of those things by writing good tests upfront and solving that problem, I would 100% say that yes, it is going to increase your productivity.\n\nDAVID: I think a lot of people push back on TDD because they're like, I'm not sure how I'm going to solve this problem, so how am I going to test it? This is really percolating; this idea of TDD is not test after but backwards in time. If you go up a level and figure out what is it that I'm trying to solve, that's the thing that you test and that you can do in advance, and then you go down slow. And then, when you go down a level, you have to write a unit test that say, \"Does this code do the...?\" Yeah. \n\nYou guys have fried my brain here. I'm, like, smoking neurons as well as we speak and, like, trying to get my head wrapped around this idea. What I will say is, if I don't know how to solve something, TDD lets me come at it from above and sketch in and say, \"You must satisfy this to make this happen.\" Where, if you are expecting to come up from underneath of, like, well, I'm going to build a thing that combines this, and then recurses into that, and then calls this query over here, and then; eventually, I have a thing that does the thing in the end, TDD sucks when you're trying to do that. That much more suits the write it, test it, write it, test it, write it, test it. \n\nAnd there your unit tests are, like, regression specs. They make sure that the next three things that you do don't break the first thing that you did, where, for me, TDD gets out in front. I was talking with Tad about this earlier in the week. I wrote a spec, and then I wrote the code. And the spec was just there to help me keep my thinking straight and make sure that it would do the thing. And when I was done, I had a spec that did not explain what the code was trying to do. And it duplicated a lot of the, like, external stuff that really wasn't useful, and it forced a database hit, which made the thing very, very slow. \n\nAnd after we had the whole thing written out, the spec was superfluous. It was useless. It was not a really good regression test. It was just going to be a maintenance nightmare. So, I wrote the test. I got the code working, and then I deleted the test and I pushed up the PR. And Tad called me on it because I did it on two PRs. And the second one, he's like, \"Where's the test for this?\" And I'm like, \"Oh, that actually was a good test. I shouldn't have gotten rid...\"\n\nThe first one was just a database scope, and, like, to test that in Rails, you're going to duplicate Rails, and it was kind of useless. And there's not really a clean way to just say, \"This scope should exist.\" So, anything outside of that was just duplicating. Oh, I kind of start to receive a message chain, but yeah, the arguments could be all over the map. \n\nMATT: To be able to do this, right, you need to know what is your expected input, and what's your expected output. It doesn't need to dictate your implementation. So, it's not going to write good code for you, but it is going to solve your problem, and it's going to prevent you from breaking things when you make choices.\n\nDAVID: Yeah. You just touched on a really key distinction there, Matt. You have to know what your inputs and your outputs are. When we come at these tests, and we're like, \"This testing is hard,\" it's because we're coming at from the other side, and we're saying, okay, I should expect this model to receive the message chain of dot where, dot order, dot...you try constructing the ActiveRecord query, which is all implementation, right? It's all pure implementation, and we're trying to mock and stub that out. And you're standing at the wrong end of the code for TDD when you do that. Man, I feel a blog post coming on. Remember blogs? Three people on the call are like, \"No,\" [laughter]. \n\nEDDY: Dave, [inaudible 18:27] might actually have something that's really interesting. And you said test-driven development allows you to come at it from a different perspective, right? \n\nDAVID: Mm-hmm.\n\nEDDY: Like, at a higher level, then we're acclimated [inaudible 18:36]. I want to say something about that. And there's a concept, you know, that is pretty notorious around the tech industry, especially for programmers, and it's called rubber ducking debugging. And I've associated writing tests...I used to not like it, especially doing RSpec because the DSL is crazy, right? But, like, once you, like, really narrow it down, it actually caught...I've caught myself actually approaching the problem differently. For me, it's sort of like a rubber duck, where I'm able to express it in a different way that I wasn't looking at it before, so a new perspective. \n\nNow, we're talking about productivity. That is a prime example. Now, I need to test my code, but my code isn't working. How am I going to set it up? And then, suddenly, the setup is like, oh, that's why it's not working [laughs], right? And you're able to go through it line by line in a different angle, right? So, when we're talking about productivity, I think TDD, in a sense, at least I have some experience with it getting me unstuck, right? Because it's able to provide a different perspective. \n\nSo, I do kind of want to go on record and say hey, I don't hate TDD. I've seen the benefits on why we do it, right? And it's keeping ourselves in check. And it's also a way to solidify the code that we wrote is on purpose [laughs] and that we truly understand it.\n\nMATT: Well, right. And it's up to the engineers to figure out the middle, right? And, again, it can't dictate good implementation, but it prevents you from breaking your inputs and outputs. And as long as you know those things, test-driven development is absolutely relevant. \n\nDAVID: Yeah. Matt, you're feeding my brain hamster. It is not an input or an output to assert that ActiveRecord receives this convoluted message chain, right? That's implementation support to make your test go a certain way. And this is the kind of spec that we don't do in our code a lot because we have a very large test base, and we're always trying to speed it up, and we've had productivity hits from trying to talk to the database.\n\nBut, like, when you have a thing that says, \"Hey, I'm going to write this kind of contract and this other kind of contract. And I'm going to assert that when I call this thing, I get the first contract and not the other one,\" and that's all handled by database stuff. That's stuff that we would be tempted to stub out the ActiveRecord query and da da da. And that's very implementation-specific. And those are not inputs and outputs, right? The inputs were I had these two contracts, one was even, and one was odd, or one was red and one was blue. And when I ask it, \"Give me blue contracts,\" I need to make sure I got the blue one, and not the red one. And that's input-output. And now it doesn't matter.\n\nEddy is frantically waving, \"Mike's on the call. Mike's on the call.\" \n\nMATT: [laughs]\n\nDAVID: Welcome, Mike. We were just talking about...well, today on the Acima Developers podcast; we are baiting and switching Justin on his habits stuff. We let him give a two-minute introduction on habits, and then we went down the rabbit hole of TDD and testing. Next week, we'll talk about ADHD and bicycles, which reminds me of a story about bicycles. \n\nEDDY: To be fair, Mike, we also have circled back, and we were able to kind of deduce that TDD really does help with productivity. \n\nMATT: I think it would be hard to argue that it isn't a good habit if you're doing it properly. \n\nMIKE: You touched on something there: if you're doing it properly. There is actually some debate in the community about how religiously you should follow TDD. I think there are circumstances, particularly when I'm doing more exploration and generally within existing code, where I might not write TDD first. But then, again, sometimes it's for sure great to have a test, right? And you can use the test to see if something works. You can actually use the test to, you know, test that interface to see if it works. There may be some personal application there, but in general, TDD, while it may take a little overhead up front, leads to a reasonably performant process and generally leads to stability, right? Predictably, which is always a good thing.\n\nEDDY: Can I just go ahead and also go on record in saying having TDD, specifically in RSpec where you have a context, and it block, it dumbs it down for me to better understand what that method is doing. So, when we're talking about productivity, like, my biggest complaint really is if this method is really complicated, I hate that it doesn't have comments. If you think it's complicated, either leave comments on there or have some gnarly, gnarly test that really breaks it down and tells you this is the context. This is the it block. This is the behavior. This is the [inaudible 23:30].\n\nAnd having really good tests has actually helped me better understand what the purpose of that method really was and the intention behind it. So, again, circling back [laughs] to productivity, I was better able to have, like, a better-defined picture that attuned on, like, the changes. And I felt safer doing it as a result.\n\nMATT: And writing good, clean code is much more productive than writing code that introduces bugs that you have to go back and fix.\n\nDAVID: Ooh, but in the first five minutes, it's slower, right? \n\nMATT: Oh, 100%\n\nDAVID: It's so much quicker, right? I can jam in a fix that solves the thing that, you know, it's like, oh, hey, look, even-numbered contracts are the ones that are violating the TCPA standard. So, I'm going to reject texting messages for even-numbered contracts. Fixed it! It took me 10 seconds. \n\nMIKE: [laughs]\n\nDAVID: There might be some maintenance later. Future me will hate me. \n\nMATT: Never [laughs]. \n\nEDDY: Justin, circling back [laughs] to the topic at hand, do you want to continue? \n\nJUSTIN: Well --\n\nDAVID: Actually, the reason we went...sorry. Sorry to jump on this again. I am actually steering towards you, Justin. The reason I brought up testing, in my particular bit, is that somebody reminded me on Twitter this week if they haven't seen the test fail, they assume that the test is wrong or hasn't worked. And so, this person has a habit that when they write a test, they make it fail every time. If they haven't seen it fail, they assume that the test is either not executing or not touching the code that's being exercised. \n\nAnd I don't always follow that habit, and I will get bitten by a test that seems to be passing, and then I will break the code. And the test continues passing, and I get very alarmed. And then, I get very good about following that habit for a while.\n\nMATT: Yeah. When I first learned how to do test-driven development, that was a requirement of the team. \n\nDAVID: It's a [inaudible 25:30]\n\nMATT: You know, we were programming, and we said, \"Okay, it's passing. Now let's make it fail.\" \n\nEDDY: If you make it fail, suddenly you have your unhappy path, right? \n\nDAVID: The old Red-Green-Refactor mantra was, you get to red first, then you get to green fast, then you refactor until the code is, you know, not a maintenance nightmare.\n\nMIKE: And I think that there's something there. I think that a lot of times we think, I need to test the thing, and so we're not very systematic about it. We say, okay, we'll start with a happy path, and then I'll start doing edge cases. And after that test passes, we think, okay, I've got pretty good coverage. Now, let me start covering the other things. And I think that that way of testing in this way that I've done it in the past, that I've changed over time, has some flaws. It really isn't structured in order to document your code. And we've talked about this in other podcasts. It's structured in order to help you maximize your efficiency in that moment to cover that specific part in the flaws.\n\nAnd instead, I like to approach my code and say, well, what are all the branches? And I usually like to test all the broken branches first. And if you do that, you have verified that, you know, all of your validation failures are actually failing out, and then your happy path is kind of the last piece you get to. It takes a little bit longer, but then you get full coverage. You get better documentation out of it and avoid a lot of that risk of like, oh yeah, the happy path test works when maybe that wasn't even testing anything. \n\nMATT: You're preventing downtime in the future. \n\nEDDY: I don't know if it's crazy. For me, I like to see green dots first. Like, it super, super, makes me a lot more enthused to write code. I joked about this on a previous podcast, like, green dots have become my favorite-colored dot.\n\nMATT: On that note, if you are doing test-driven development, it's going to fail first because your failure is what's driving your development. \n\nDAVID: And I don't think those are incompatible statements, by the way, or even what Mike was saying. Like, I still see it. In my head, it's all green dots, right? That green dot means that this is exercising the code and that it's passing. So, we get to red first so that I know it's executing the code then I make it pass. Now I get my green dot, and I get cookie. It's satisfy. It make it work. And testing the unhappy paths, those aren't red dots, right? Like, the unhappy path is you tried to save a username that was, you know, 4K long, and the database only holds 50 characters.\n\nThere must be a validation error that says, \"Name must be less than 50 characters.\" And if I save a 4k thing and it writes it and it doesn't raise a validation error, but it throws away [chuckles] 3.9k of the name because it only said, \"That's a fail,\" because it failed to validate, so you make the validation pass. And you get the green dot, and so it is; it's all green dots. At least in my head, it's all green dots.\n\nMIKE: Yeah. It's all green dots all the way, but you're testing all the edge cases either way. \n\nDAVID: Yes.\n\nMIKE: So, you don't have to write a test that doesn't cover that case and then have to go through the pain of seeing the red dot. What you do instead is you write a test that captures all the bad cases and make sure that those all show green. Like, make sure those failure cases actually happen. \n\nMATT: Let's take an integration test with MVC. First thing we may do is load up a model, right? But because we're doing test-driven development, that model doesn't exist. So, first run it's going to fail. Then, we go create our model. Next line, hey, we hit this endpoint in this controller. It then loads the model. We run it. It fails on that endpoint because it doesn't exist. It drives you step through step. And that's what I was trying to say, Eddy, is, sometimes, when we don't understand a domain, going about it in this manner helps us understand the domain but also makes it so we can work inside of that code without that full understanding.\n\nDAVID: The other thing that gets me thinking is, like, when we get a ticket that we have to work in the code, it doesn't say, \"Use a red-green or a red-black tree to sort the data in the database.\" You get tickets that say things like, \"Stop sending text messages to customers who have opted out via TCPA because that's against the law.\" There's nothing in the database that says, \"Don't break the law,\" right? And yet we will pull up code and, like, ultimately, the fix is going to be to add a where clause in the thing. When we do this, we need to join on the TCPA, you know, opt-ins or whatever, or however you can implement it. \n\nAnd we might be tempted to write a test to say, \"Are we checking the database for this one thing?\" But if you're starting with TDD, you start with a customer who has opted out and another customer who's opted in. And you try to send them both messages, and one of them should receive the message and one of them should not. And that's pure io. Now, it doesn't matter how it gets developed, right? It literally could be, \"Hey, there's this queue that we send to human operators who punch things in on a phone to call people, and that queue should not get the customer that opted out,\" or it could be a database query, or it could be there's a million ways to select data, right?\n\nMATT: Yeah, because you know your inputs and your outputs. \n\nDAVID: Right. When you get this thing, don't try to write a TDD of changing the way we filter from a list. You know, it's like, how am I going to reject on the MapReduce? No [laughs]. Start with your input. Start higher. Go up a level. \n\nEDDY: I kind of want to punt this to, like, individuals who weren't here in the last podcast. And I kind of want to get their perspectives so more tailored towards Matt, Tad, and Enrique. What are some of the habits that you typically gravitate to when you're stuck on something, and you're trying to get more productivity? Like, what are some of the things that you do, like, instinctively that get you more productive?\n\nTAD: Talk to someone else. A lot of times, if I just talk through it...like, you were talking about rubber duck earlier, Eddy, right? If I stop, talk through it, then, usually, I'll get some clues. I'm like oh, there's some variables I need to check, or, oh, there is where I might have gone wrong, right? Just talking it out, talking it through, even if they don't give me any feedback, is often helpful. \n\nMATT: For myself, I would say my first steps usually aren't reaching out unless I know someone has a context on the problem I'm trying to solve. But I do have things that I almost always do; one would be Prys. I love Pry, you know, ruby-specific, but debuggers, breakpoints. And then, I step through because, ultimately, if you're trying to solve a problem, you need to know where that problem is happening, and I will always time-box a problem, always.\n\nOne of the mistakes people make early on in their career is they don't want people to think they don't know something or they're inadequate, so it's a pride thing. Overcoming that and being able to reach out and ask questions will significantly help your process. Every day, I'm reaching out to people. It doesn't matter who it is. It doesn't matter what level someone is. Everyone has something to offer that we don't know. So, I think a good habit is asking questions and just being able to communicate those questions to your peers. \n\nJUSTIN: One other thing that I think is helpful is to...it's been mentioned several times before, but breaking down the problem such that if you are stuck on one particular thing or kind of a general thing, you're like, oh, okay, how do I break this down? And keep on breaking it down until you get to something you can solve.\n\nAnd then, by the time that you have perhaps identified, you know, okay, I can solve these five sub-steps, but I can't solve six, you've identified enough to bring it to somebody else who may have context. Because they'll probably ask you, \"Oh, did you try A, B, and C? \"And if you were able to break it down, you'll be able to go to them and say, \"Okay, here's my work so far. You know, I don't have any idea how to do this,\" But rather is, \"Oh, okay, here's the original problem. Here's what I've tried to solve it. Here's the progress I've made, but I'm stuck on this particular one,\" and just explain to them everything that you've done. \n\nAnd then, they'll be able to answer, \"Hey, did you try this?\" Or they might be able to answer, \"Hey, you're barking up a wrong tree.\" But it's also, you know, you combine that with all the other suggestions of time boxing and things like...you don't want to go too far down the wrong rabbit hole. So, there's a balance to be had there. But, you know, do your work and do your homework and try something. \n\nEDDY: Oh my gosh, I've never thought about timeboxing a problem [laughs]. That's so cool. Just to bring everyone kind of up to speed, Tad and I were pairing earlier today, right? And we were trying to figure something out. And he said, and it's kind of stuck with me even now, he's like, \"Okay, let's try to figure out this problem. But if we can't figure it out, we'll timebox it. We know how to fix it another way, but we don't like this other way. We're going to try to fix it this way instead, but we'll timebox it for, like, 10 minutes.\" If we can't figure it out in 10 minutes, suddenly, your productivity kind of starts spiraling down because you're still stuck on the same problem.\n\nSo, just saying, \"Okay, if in 10 minutes we can't figure this out, we still know the solution. We'll do the other solution as a fallback.\" But you're still moving forward on your problem, right? Oh my gosh, you know, timeboxing is so cool. I didn't think of that.\n\nMATT: [laughs]\n\nTAD: Because I was like, there's an elegant solution here if I could just find it, right? And there's a way that works, but it's kind of ugly. I'm like, \"Eddy, if I can't find the elegant solution, we're just going to...in five minutes, we'll stop and do the ugly thing instead.\" \n\nMATT: That's kind of a good segue into what else I was going to say, and that is stepping away. Oftentimes, just stepping away from a problem is a good idea. So, if you have an elegant solution in your head and you think this other one's sloppy and you implement it, step away. The elegant solution may come to you. You know, sometimes just kind of walking away from something, giving yourself a breather because we tend to get tunnel vision. And I think getting outside of that tunnel is extremely helpful.\n\nDAVID: I used to rock a standing desk, and I legit believe that the number one value of the standing desk...nothing to do with health or with any of that. The number one value of the standing desk was that I was much more likely to step away from the computer once every 30 to 60 minutes just to think about the problem. And it stopped me from fixating and tunnel visioning on a problem for two hours, three hours, five hours so many times.\n\nMATT: We want to solve problems. That's why we do what we do, right? And I think all of us tend to get tunnel vision and get stuck in these problems because we're so stubborn that we just want to solve them. And a lot of times, walking away for a few minutes can help do that.\n\nDAVID: I just realized that dovetails perfectly into Justin's habit thing that if you're standing up at a standing desk, it makes stepping away to switch from fast thinking to slow thinking, to tight focused to, like, spreading out to wider thinking, it makes it so that that's easy. It's attractive [laughs]. There's no start-up cost. You just take a step back, stretch your arm, and then just walk over to the window, right? Because there's no pushback, change state, stand up, deep breath. There's none of that big state change. You're already standing up. Just walk over the window and breathe. \n\nENRIQUE: I'm trying to Google what time box a problem means.\n\nDAVID: Oh. It means to decide in advance how much time you're going to spend on this. You draw a box on it on the calendar and basically say, \"We're going to work on this for half an hour.\" The value of this is you can say that, \"We've got a bad way to do it. We don't want to do it this way. But it's not worth spending 10 hours on to avoid this problem. If we can't solve this in 30 minutes, it's not worth solving.\" \n\nSo, you just draw a box around it on the calendar and say, \"We're going to work on this for 30 minutes. And if we're done, we're done, and if we're not, we're not.\" Or at the end of 30 minutes, you can say, \"We're really close. It's worth another 30 minutes.\" You can extend your time box. But, again, you stay boxed. You don't let your time become open. \n\nMATT: If I have a problem I don't know how to solve, because a lot of us are self-learners and we like to just figure things out ourselves, we say, \"Okay, I'm going to spend an hour trying to figure this out on my own. And if I don't have a solution, then I'm going to go talk to somebody else and reach out.\" \n\nEDDY: I love the fulfillment, though, that I get if I resolve the problem myself. Like, there is some sort of joy in myself, like, self-pleasure, where I'm just like, oh, I did it, right? Like, I was able to overcome that, and I found the solution that I was looking for. However, there's times where, like, I've been stuck in a problem for, like, an hour, reach out to someone who I know will have the answer and be like, \"Hey, I have this failing spec, and I can't figure this out, you know\" And they're like, \"Oh yeah, it's because you need to do this.\" And suddenly, I'm like, oh man, why didn't I see that before? But there's value to that because, like, that solution gets cemented in your brain much better because you struggled to find the solution much longer. \n\nMATT: I think a good habit, too, since we're talking about habits, is when you do finally reach out for answers and information, make it a point to understand why. Instead of just getting the solution, understand why it is the solution and how it is a solution. That way, the next time you run into a similar problem, you have the tools you need to be able to solve that problem. \n\nEDDY: Yeah, for me, I found that I need to struggle on that problem for a little bit longer so that I can better understand the issue so that when I do get the answer, I understand it more in-depth.\n\nMATT: Yeah, and --\n\nDAVID: I think it's useful to know in advance, do I want to use this solution to solve this thing in the world, or do I want to work on creating the solution? Sometimes I don't want to carve wood. Sometimes I want to build wood carving tools. And sometimes I would rather work on my software tooling than build software with my tooling. And so, knowing in advance, what do I want to do? \n\nLike, if I want to build the tooling, I don't want somebody else's help. I want to discover it myself. I'm in it for that joy. And if I go ask someone for the answer, I give up that joy. But if I just want to solve the problem so I can do another thing, every second I spend trying to find the solution is time not spent using the solution to get what I want. And knowing to switch hands and say, \"Oh, just give me the thing,\" right? \"Google, give me the answer. ChatGPT, give me the answer,\" because I just want to get on down the road to solving the thing. \n\nMATT: Yeah, I think sometimes, I mean, and we're in a business environment, so we do have to limit the time we spend on these problems. But if we're getting the answer, getting the solution, if we also get an understanding of how that solution was created and why that is the solution, then the next time we come around, that tool is in our toolbox. \n\nDAVID: We're not just in the business of producing software. We're in the business of producing programmers. That is one of the outputs of our system. And so, yeah, investing in figuring out the solution, definitely worth it.\n\nMATT: Yep, and everyone benefits from that: we as engineers, the company from the ability we create to be able to develop software and mentor others as they come on board and make them more efficient. It's a win-win. \n\nEDDY: I actually want to say something, and you all might laugh, but I stumbled upon this solution that helps me become more productive, and that is eating [laughs]. \n\nDAVID: No joke. Yes. How's your blood sugar? \n\nEDDY: I'm not kidding. I'm not kidding. Like, there's times where I'm just like, I've gotten up. I've gotten to my kitchen, gotten a snack, sit down for a little bit, come back up fed, you know, and I'm like, oh, yeah, that's the problem [laughs]. Eating, eating has helped me tremendously on my productivity.\n\nMATT: There's a reason they call it hangry. I'm the same way. If I go without eating, I can get snappy and -- \n\nDAVID: I worked with a guy years ago. The question \"Have you eaten?\" is on my list of questions to ask when nothing else is working. I actually have a list of things to ask when you're out of questions, and \"Have you eaten?\" is on there. I had a co-worker who was just grumbling, and he's wicked smart. He got a PhD in geophysics, and he's trying to solve a seismology vibrational problem in software. And I can hear him muttering and cursing, and he'd been doing this all afternoon. So, I was just like, \"Don, have you eaten?\" And he pauses, and his eyes get real big, and he's like, \"No,\" and I'm like, \"Get your stuff. We're going to get a cheeseburger.\"\n\nAnd part of it might have been the walk, part of it might have been stepping away from the computer, but by the time he had come back and his blood sugar was back up, he knew where to start the next piece of the software. So, you are bang on. Keep that question, Eddy. It will save your career.\n\n[chuckles]\n\nMATT: Rest is right there with it, too. \n\nDAVID: Rest. Yeah. \n\nMATT: You know, yesterday, Travis, one of our other engineers...you all know him, but our listeners may or may not. We were working on a problem together, and I was running on...I think it had approached about 36 hours of no sleep, and, you know, I started my day at about 5:00 a.m. yesterday, and it was going on the 13th hour of work for the day and 36 hours of no sleep. The simplest of problems become difficult. If you aren't rested, then that's a real thing.\n\nDAVID: Sometimes, the most productive thing you can do is get your head down for six hours. Yeah. \n\nMATT: Yeah, and I just finally I was talking to him, and I said, \"Travis, how about I hand this over to you? You drive because I just am not functioning at the moment.\"\n\nTAD: You've reminded me, you know, like a few weeks ago when we decided we're going to go for periodic walks around the office, and we fell out of that habit. \n\nEDDY: It's a great habit to have, I think, right? Like, it takes your mind away from, like, just being stuck at your computer for so long. And I hope, like, higher people don't hear this, but that is part of why I like going into the office. It's much easier to reach out to someone to the side and be like, \"Hey, Dave, question for you. I'm stuck in this problem. What would be your approach?\" And kind of, like, bang off ideas out of each other. Like, when you can do that, there is solutions to that. Or sometimes just going on a walk for a little bit, like we said earlier, right? So yeah, just like what Tad said. \n\nDAVID: I think the answer might be written on the mountain. Let's go look. Let's go out to the parking lot and look. \n\nMATT: Yeah, that encompasses the stepping away. And, obviously, exercise is healthy. It gets endorphins going that may not be present just from sitting at your desk. I don't think anyone can argue against taking the occasional break and doing that. It makes us perform better. \n\nEDDY: Enrique actually wrote something, and I kind of want to say it on record. He said going to the bathroom really helps getting yourself unstuck and being productive [laughs], take that as you will.\n\nMATT: And being tracked down by your CTO. \n\nEDDY: [laughs]\n\nDAVID: A little burst of adrenaline. Whoa, what? Getting up and going to the bathroom...I read a neurology study. They found that when you walk through a doorway, there is something neurologically that happens that causes, like, a refresh stripe to go through your brain. Like, it just passes through the neurons. \n\nAnd they think this is why you can stand up and walk into the room to get a thing, and when you get there, you can't remember what you were going to get. And it's because the part of your brain that's holding on to that attention, go get the thing, gets reset by that refresh wipe as you go through. So, yeah, weaponizing that for good is get up and go to the restroom room, you know, go down the hall. Go talk to a coworker. I need to wipe all of the wrong solutions that I'm holding on to in my head. I need to just power off. \n\nEDDY: Dave, I thought that was always a me problem. I thought, for me, I was just like, man, I think this is, like, early symptoms of, like, Alzheimer's or something. Like, how am I forgetting something so simple? And then, like, as other people, like, affirmed that it happens to them, too, suddenly, I'm like, oh, thank God I'm not the only one [laughs]. Like, other people have short attention spans also. \n\nMATT: We've been talking about all these habits. Just another quick one just for record is, taking notes and recording meetings. Giving yourself something that you can reference, I think is a good habit as well. Historically, I was never a note-taker. Just because of the things I'm responsible for and have to keep track of, I have become a very consistent note-taker, and it's been a really good habit and helped me out a lot in my day-to-day duties.\n\nEDDY: Matt, actually, this is really interesting because, like, I spoke with someone the other day, and they told me, \"Oh yeah, I'm a huge note-taker.\" And they're like, \"I can be on my computer, but I find myself getting a notebook and writing, like, with a physical piece of paper and a pen on my hand.\" And I'm like, \"Really?\" I'm like, \"Doesn't that take longer to jot stuff down? Because I'm sure you can type faster than you do write stuff down, right?\" And they're like, \"Oh, no, no, it's just, like, I've been groomed, you know, it's instilled in my childhood to take notes with a notebook. So, like, it's ingrained in my head, and so I'll do that, like, natively.\" And I'm like, \"That's interesting.\"\n\nMATT: I think for a lot of people, just on top of that, is, when you write something down, while you're writing it, you're also recalling that information, right? So, right there, you've heard the thing. You've written the thing and recalled the thing, and you're ingraining it into your memory.\n\nEDDY: Yeah, but that also happens when you're typing. I'd argue that it's –\n\nMATT: Yeah, yeah, sure, sure, but I just mean note-taking in general. I'm of the age where when I went to college, you took notes by hand. And I got really good at it for a while, but I don't write by hand often these days. Just having something to remind you and to recall and go back and reference is a really good habit because we all get so much information thrown at us so often that we can forget and lose things over time.\n\nDAVID: I took a speed writing class in high school back when typewriters existed. You'd take dictation very, very quickly, and your notes are sketchy. And it's trying to, like, what the heck did I write there? And I skipped words. But the very first thing you do after the dictation is you sit down and you transcribe your own notes to better notes. And then, you take your transcribed notes and you type them up, and that process of reviewing your own notes twice is hugely beneficial for memorizing.\n\nMATT: Yeah, and there you go. Just by the time you get to the end of that process, you have recalled that information, like, four times. You start to remember it all. \n\nEDDY: I was surprised when I first started, right? Like, my late high school years going into college, I'm like, how the heck are people able to write all this in a piece of paper and, like, recall everything that was said? And then, one of my teachers sat me down. He's like, \"Well, because they're not writing everything. They're just doing highlights of what was said,\" and highlight. I was like, holy cow, that just opened up, like [laughs], another realm. I'm like, yeah, you don't necessarily need to write the does, the ifs, and whens. You just do only the highlights of what the conversation was had but enough where you can recall. And suddenly, you become super efficient. \n\nDAVID: You start thinking about what is the objective of this? The biggest superpower for me in school was somebody said, \"When you're taking notes, if you were writing the test for this class, what questions would you write from what was given?\" And I turned in the sheet of my...I had the thing, and I had the questions that I wrote them down next to my notes. And the teacher actually pulled me aside and asked if I had...like, he didn't quite accuse me of cheating, but he wanted to know if I had been going through his desk because I had picked, like, 80% of the questions off of the test as a result.\n\nEDDY: [laughs] But suddenly, that's a good thing when you do TDD, right?\n\nDAVID: Mm-Hmm. Yeah. \n\nEDDY: [laughs]\n\nDAVID: Test-driven class note-taking. I like it. I like it. \n\nEDDY: Suddenly, your coverage is much higher because you practiced. \n\nDAVID: Yes. Oh, this has been a good round table chat. Thank you, guys, for coming. The one advantage of going so far afield when we invited Justin back for a part two is that now we can invite him back next week for a part three. Well, for a redo of part two.\n\nEDDY: [laughs]\n\nMATT: They always get a little off-topic, but I think that's the beauty of it, right? We segue, and we end up talking about useful information that I think everybody should have. \n\nEDDY: I've actually made a habit on going half to what we were initially talking about. Like, I don't mind going on tangents, you know, every once in a while because that's how our brain works, right? But, like, being cognitive, right? Or conscious and, like, going back to what the original topic of the conversation is. Because otherwise, you'll spiral out, and you'll talk about --\n\nMATT: I would argue today we did never really get away from the topic. \n\nDAVID: No, No. You can't predict what you're going to discover when you start synthesizing new ideas. And, like, Matt, you kept just, like, lightning striking my brain. And I'm like, I did not expect that to fall out of my head and in the podcast. And I'm like --\n\nMATT: [inaudible 50:56] [laughs]\n\nDAVID: Well, no. It's like you were saying things, and it was causing just things to just precipitate like I'd had all the pieces of an idea in my head for weeks. And then, you said that thing, and I'm like, oh, man. Or, like, Eddy, when you said unit tests, and I'm like, aha, it's behavioral, not implementation. Yeah, right on. \n\nEDDY: Well, David, this has been awesome, guys. Thank you so much.\n\nDAVID: This has been great. ","content_html":"This podcast episode from The Acima Developer Podcast crew dives into the concept of developer habits, focusing on how habits are formed and their importance in software development. The discussion begins with a recap of the previous episode, emphasizing the "four laws" of habit formation—making it obvious, attractive, easy, and satisfying—as presented by Justin. These principles are highlighted as foundational to acquiring and maintaining good habits that can significantly impact one's personal and professional life.
\n\nThe conversation shifts to personal experiences and practices that contribute to productivity and good habit formation in a software development context. Matt shares his perspective on taking ownership and how it has been pivotal in his career. He references the book "Extreme Ownership" by Jocko Willink, stressing the importance of accountability in software development. David expands on this, discussing how owning the success of a project often involves being open to feedback and adjustments, even if it means stepping back from one's own work.
\n\nThe latter part of the discussion delves into Test-Driven Development (TDD) and its role in productive software engineering practices. Eddy brings up the challenge of spending too much time refining projects instead of coding, questioning the productivity of such tasks. This leads to a row on the efficacy of TDD, with several participants, including Matt and Justin, defending its importance not just in writing quality code but also in understanding problems more deeply and fostering productivity. They argue that TDD, when properly applied, not only helps in reducing bugs but also in enhancing the developer's understanding of the codebase, ultimately leading to more productive coding practices.
\n\nTransciption
\n\nDAVID: Hello and welcome to the Acima Developer podcast. We are doing a part two on developer habits. Justin, you kicked us off last week. I'm going to pick on you again. Give us a quick summary on, like, what are the elements of a habit so that we can kind of just jump straight in. Last week, we spent most of the time talking about, like, why and how of habits, and we didn't get into too many specific engineering habits.
\n\nJUSTIN: Right. One of the main things is, and here I'm just going off a table of contents here that perhaps is a good, quick summary, there were four laws that kind of make up a good habit or how you can acquire a habit. And the four laws were: make it obvious, make it attractive, make it easy, and make it satisfying. All of those require perhaps a little bit more work than just the desire to do something. If you actually go through and do what's needed to follow those four laws, you are much more likely to actually acquire that habit and have it make a change in your life. That's, like, the two-minute summary.
\n\nDAVID: It's awesome.
\n\nJUSTIN: [laughs]
\n\nEDDY: I kind of want to, like, punt this to individuals who weren't present in our last just to kind of get, like, a fresh perspective (if you're okay with that, Dave) just to see, like, what other people's opinions are on what makes them more productive.
\n\nMATT: I'm happy to talk about it. For those of you who do not know who I am out in GV land, my name is Matt. I'm one of the engineering leads over here at Acima. For me, one of the most important things that has helped me form really good habits over my career is taking ownership. I think it's extremely important in this industry and, you know, just in life in general.
\n\nThere's a book, maybe some of you may or may not have read, called Extreme Ownership, written by Jocko Willink, and he was a Navy SEAL, I believe, platoon leader. And he's written a couple of books, but that one in particular really helped me. And the preface of it is that we just need to take accountability and ownership over all of the things that we're doing. And in software, part of that is not getting married to your code but having ownership of your code, have some pride in your code, take ownership of bugs, anything that arises with it. And I feel like that's going to help you write better software and think through your problems up front.
\n\nDAVID: I like to think of that by saying I want to take ownership of the success of the project. And sometimes, that means letting somebody rewrite my code or somebody push back on my design because cash flow doesn't care about your pretty, little design. Cash flow cares about whether or not a customer can get through the system. And so, when somebody pushes back on me, even if it chafes, I'm often very quick...and this might be an internalized habit, but I try to be very quick to say, "What do I really want here? Oh, this hurts, but it's getting me what I want." So yeah, I'm on board with this.
\n\nEDDY: So, I wanted to kind of throw something out there, especially for people who have more experience than I do. The past few weeks the project that I'm currently working on and one I'm involved in has required a bunch, a bunch, a bunch of requirements in order to finally get some work done and finally start writing some code.
\n\nHere's the thing, and here's kind of where my perspective lies is: refinement, at least for me at a high level, isn't productive. For me, I've always defined productivity as how much code you're pumping out, right? Because those are the metrics. Those are what really define you as you doing your work. So, if most of your time is consumed on refining a project, for example, can you really, at a high level, consider that a productivity effort, and does that really help? Can you constitute as that? Is it kind of, like, a gray area between you...it's a given. In order for you to be productive, you need to have something defined in order for you to work, right? So, I feel like I know the answer, but I want to get people's opinions when it comes to productivity.
\n\nJUSTIN: Like, a classic bad metric is lines of code. I could be super productive. I could just sit with my hands on my keyboard and just churn out code, but that doesn't necessarily mean anything, right? Like, it has to be quality code that meets demand or does something, right? Like, you can't just say lines of code or how much code I've written. I think if you measure that way, you're going to end up going the wrong direction.
\n\nDAVID: Goodhart's law says, "When a good measure becomes a goal, it ceases to be a good measure."
\n\nMATT: Yeah, I think refinements are every bit as important as the actual code you're writing. When we get requirements, one of the key things about refining this work with the engineers is making sure they have a good understanding of the problem. Without a good understanding of a problem, you can't solve a problem. And if you front-load your work with a good refinement, make sure that your requirements are defined, and clear, and concise, you're going to write good code.
\n\nIt's just like test-driven development, right? If we're writing our tests first with a good understanding of the problem and a good understanding of the outcome, that almost writes our code for us. Versus if we're doing that after we're writing the code, then we're writing tests to pass against the code we just wrote, which is kind of contrary to what we really want to accomplish. Because we don't know if that code we just wrote is meeting the requirements exactly as defined, whereas a good written test will.
\n\nDAVID: Mm-hmm. You end up writing the test to follow the code, and if the code is sort of a sideways implementation of what you thought the card was going to do, the test will then become a sideways implementation of the following of it, right? But if you start with the TDD, you're like, no, this is what it needs to do. You also ran into the thing of like, oh, the code is hard to test, and that's because you wrote the code first. If you had started with the test, the code would be easy to test because it would have to follow the test.
\n\nEDDY: I have a caveat to that, Dave, and I think...I spoke with Tad about TDD a few weeks ago. And I told him, I'm like, "How is it possible for you to write a unit test for something, you know, that you don't even know how you're going to write the code for?" So, it makes it extremely difficult to, like, set up all the instance doubles and all of the mock data and all of the stub data that you need. You don't even know where you're reaching, where you're looking, right?
\n\nAnd so, to me, I feel like it's more like a skeleton TDD, where it's like, cool, I can probably get my get, or my it blocks and my context set up the way I think they should be, but that's as far as I've gotten, as far as TDD. I've never actually implemented anything and then wrote the code to pass it if that makes sense.
\n\nDAVID: You said one word at the start of that paragraph, and I knew...I'm like, yep, you're headed down the wrong trouser leg of these pants: unit test. A unit test is how you assert that this tiny, little piece satisfies what the whole should do. That's where TDD starts. You write a test to say, "Does the whole thing behave correctly?" Then you start breaking down into the pieces, and then you write unit tests against those. You don't write a unit test to say, "Does this have a callback on the database before save?" until you have something higher up that says, "Hey, when I do this, it updates this other thing." And so, you come out of...it's a multi-layer approach.
\n\nEDDY: Right. So, I had a misconception of what [inaudible 07:58] was, right? And so, like [laughs], when I spoke to Tad, I was like, "Oh, gotcha, gotcha. So, you're not writing all the branches," right?
\n\nDAVID: Right.
\n\nEDDY: Like, making those branches pass. You're essentially doing, like, this is the happy path.
\n\nDAVID: Eddy, I want to sidebar with you afterwards and bang out this idea because you just sparked an amazing thought in my head. And poor Justin is just waiting for us to talk about habits [laughter]. But you just sparked an amazing thought in my head, which is, I think a lot of people push back on TDD because they're like, well, I wrote the code, and then the testing was dumb and stupid, and hard, and after the fact. And they look at TDD as write the dumb, stupid, after-the-fact test before writing the code. It's not going to work.
\n\nIt's like, you have to write something different first, and then you're like, oh, if we were just doing that, right? But yeah, I just realized that, yeah, if you see all this stuff, all the baggage that testing and awkward tests are, if you just move that ahead and try to do the awkward testing first, it's much harder to do that. Why would you do that?
\n\nENRIQUE: Basically, TDD is it's like a good practice when you have a domain knowledge, what you're doing. Because sometimes, for example, here at Acima, it's been the first time where I work with mocks instead of intensively writing the database when you write specs and start with specs. For someone like me in this context, when I don't know anything about the domain, and I don't know anything about how things are mocked, it is really, really hard. I really need to go into the UI, understand what is going on, go into the controllers, and see that everything is working correctly then I write specs.
\n\nMATT: Yeah. Back to your refinement comment, Eddy, if you have a really good understanding of the problem and we're writing stories properly and breaking them down to a level at which I feel a story should be broken down, you don't have to have a whole lot of domain knowledge. You just need to know what's coming in and what you expect out, and if you have that understanding, you can write a test.
\n\nAnd you don't have to write the entire test for it to be TDD, right? You know what's going to happen first, so you write that piece of your test. And you should run it, and it should fail. So, you implement that piece, and then you go to the next step. Let's write the next step in the test for it. And you can just step through it that way. And that actually, in my opinion, makes it so you don't require as much domain knowledge to be able to write software in a big application.
\n\nDAVID: For me, the secret is to go up a level and identify the behavior that the system should follow. That you can test in a very generic way. It's like, oh, when these things go in, they need to come out sorted. Now you go write a unit test that says, "Oh, I need you to call the sort method," or "I need you to sort it in the database," or "I need to use a B-tree," right? But the behavior is: it should be sorted when we're done, that if I pass in A, C, B, I should get A, B, C out. And how we got from A, C, B to...right? Who knows? We could split the text and pass it through...who knows, right? That's the thing.
\n\nAnd I think if you start your TDD with, okay, I need to mock out the database SQL query with an expect an order clause so that it will sort, oof, that's not test first. That's [chuckles]...Tad will call me on this one. That's [inaudible 11:27], which is test after I thought up the implementation, but before I wrote it [laughter].
\n\nMATT: So, and I think that's a good habit to form, right? TDD is going to help us write better code and more accurate to the actual requirement.
\n\nTAD: I think when you start out, you're right. You get something, and you're like, I don't really know how to do this. I don't know what this code is going to be, right? And I know, for me, a lot of times, step one is kind of poke around and brainstorm and kind of look [laughs] at where I'm putting the code and what's going on there. But that could be tests, too, right? Like, if I'm exploring the code and I'm testing, I'm like, what does this gem do? What could this code look like? What's the environment that this feature is going to be written in? I could easily write a test that kind of sets that up for me to poke around in.
\n\nJUSTIN: One of the things I'm picking up here from TDD, and I've done limited TDD, I'm not as good at it as I would hope, but just if you generalize it to kind of, like, a habit, I think it's worth recognizing that any or most good habits that you think are good habits when you start out at them, you're going to suck.
\n\nAnd it is something that you have to realize you may need to push yourself, or do other incentives, or try a different strategy to do the thing to be able to actually make that habit stick. If one thing isn't working for you, recognize that, and then try another thing, or try a different strategy, or talk to people, all of those things. You know, seek out help that helps you, you know, get you closer to where you're going to try to get to the habit.
\n\nMATT: Yeah, good habits are hard to form, right? There's a reason that millions of people make a New Year's resolution that they're going to exercise this year. And then, the gyms are totally packed for about three weeks or so. And then they just fall off because good habits are hard to form. And they're worth it though. The effort is worth it.
\n\nEDDY: Since we've been talking a little about TDD, and I kind of want to stay on track a little bit, would you go as far as to say that TDD will make you more productive? Assuming you've honed the skill, and it's just, like, second nature. And you're just like, cool, I'm going to do TDD, and that's it. Like, would you compare someone who is more senior, who's already acclimated doing TDD, and categorize that essentially as, yeah, that makes me more productive than just running the...or banging out of the code first?
\n\nJUSTIN: TDD itself is like a combination of a bunch of different things, like breaking down problems, knowing what your target is, you know, all those things kind of add into like, hey, I'm good at TDD now.
\n\nMATT: Yeah, so look at it from this perspective: if I'm writing accurate tests on a problem that I understand, the likelihood of me introducing a bug into the codebase is much, much lower. So, from a productivity perspective, I would say if I'm introducing bugs into the code because I'm not testing and I don't understand the problems that I'm trying to solve, that is significantly dropping my productivity because I'm going to have to go back to it or someone is and fix it, which is going to take even more time. It's going to take debug time, tracking things down, and then, on top of that, coding time. So, if you can avoid all of those things by writing good tests upfront and solving that problem, I would 100% say that yes, it is going to increase your productivity.
\n\nDAVID: I think a lot of people push back on TDD because they're like, I'm not sure how I'm going to solve this problem, so how am I going to test it? This is really percolating; this idea of TDD is not test after but backwards in time. If you go up a level and figure out what is it that I'm trying to solve, that's the thing that you test and that you can do in advance, and then you go down slow. And then, when you go down a level, you have to write a unit test that say, "Does this code do the...?" Yeah.
\n\nYou guys have fried my brain here. I'm, like, smoking neurons as well as we speak and, like, trying to get my head wrapped around this idea. What I will say is, if I don't know how to solve something, TDD lets me come at it from above and sketch in and say, "You must satisfy this to make this happen." Where, if you are expecting to come up from underneath of, like, well, I'm going to build a thing that combines this, and then recurses into that, and then calls this query over here, and then; eventually, I have a thing that does the thing in the end, TDD sucks when you're trying to do that. That much more suits the write it, test it, write it, test it, write it, test it.
\n\nAnd there your unit tests are, like, regression specs. They make sure that the next three things that you do don't break the first thing that you did, where, for me, TDD gets out in front. I was talking with Tad about this earlier in the week. I wrote a spec, and then I wrote the code. And the spec was just there to help me keep my thinking straight and make sure that it would do the thing. And when I was done, I had a spec that did not explain what the code was trying to do. And it duplicated a lot of the, like, external stuff that really wasn't useful, and it forced a database hit, which made the thing very, very slow.
\n\nAnd after we had the whole thing written out, the spec was superfluous. It was useless. It was not a really good regression test. It was just going to be a maintenance nightmare. So, I wrote the test. I got the code working, and then I deleted the test and I pushed up the PR. And Tad called me on it because I did it on two PRs. And the second one, he's like, "Where's the test for this?" And I'm like, "Oh, that actually was a good test. I shouldn't have gotten rid..."
\n\nThe first one was just a database scope, and, like, to test that in Rails, you're going to duplicate Rails, and it was kind of useless. And there's not really a clean way to just say, "This scope should exist." So, anything outside of that was just duplicating. Oh, I kind of start to receive a message chain, but yeah, the arguments could be all over the map.
\n\nMATT: To be able to do this, right, you need to know what is your expected input, and what's your expected output. It doesn't need to dictate your implementation. So, it's not going to write good code for you, but it is going to solve your problem, and it's going to prevent you from breaking things when you make choices.
\n\nDAVID: Yeah. You just touched on a really key distinction there, Matt. You have to know what your inputs and your outputs are. When we come at these tests, and we're like, "This testing is hard," it's because we're coming at from the other side, and we're saying, okay, I should expect this model to receive the message chain of dot where, dot order, dot...you try constructing the ActiveRecord query, which is all implementation, right? It's all pure implementation, and we're trying to mock and stub that out. And you're standing at the wrong end of the code for TDD when you do that. Man, I feel a blog post coming on. Remember blogs? Three people on the call are like, "No," [laughter].
\n\nEDDY: Dave, [inaudible 18:27] might actually have something that's really interesting. And you said test-driven development allows you to come at it from a different perspective, right?
\n\nDAVID: Mm-hmm.
\n\nEDDY: Like, at a higher level, then we're acclimated [inaudible 18:36]. I want to say something about that. And there's a concept, you know, that is pretty notorious around the tech industry, especially for programmers, and it's called rubber ducking debugging. And I've associated writing tests...I used to not like it, especially doing RSpec because the DSL is crazy, right? But, like, once you, like, really narrow it down, it actually caught...I've caught myself actually approaching the problem differently. For me, it's sort of like a rubber duck, where I'm able to express it in a different way that I wasn't looking at it before, so a new perspective.
\n\nNow, we're talking about productivity. That is a prime example. Now, I need to test my code, but my code isn't working. How am I going to set it up? And then, suddenly, the setup is like, oh, that's why it's not working [laughs], right? And you're able to go through it line by line in a different angle, right? So, when we're talking about productivity, I think TDD, in a sense, at least I have some experience with it getting me unstuck, right? Because it's able to provide a different perspective.
\n\nSo, I do kind of want to go on record and say hey, I don't hate TDD. I've seen the benefits on why we do it, right? And it's keeping ourselves in check. And it's also a way to solidify the code that we wrote is on purpose [laughs] and that we truly understand it.
\n\nMATT: Well, right. And it's up to the engineers to figure out the middle, right? And, again, it can't dictate good implementation, but it prevents you from breaking your inputs and outputs. And as long as you know those things, test-driven development is absolutely relevant.
\n\nDAVID: Yeah. Matt, you're feeding my brain hamster. It is not an input or an output to assert that ActiveRecord receives this convoluted message chain, right? That's implementation support to make your test go a certain way. And this is the kind of spec that we don't do in our code a lot because we have a very large test base, and we're always trying to speed it up, and we've had productivity hits from trying to talk to the database.
\n\nBut, like, when you have a thing that says, "Hey, I'm going to write this kind of contract and this other kind of contract. And I'm going to assert that when I call this thing, I get the first contract and not the other one," and that's all handled by database stuff. That's stuff that we would be tempted to stub out the ActiveRecord query and da da da. And that's very implementation-specific. And those are not inputs and outputs, right? The inputs were I had these two contracts, one was even, and one was odd, or one was red and one was blue. And when I ask it, "Give me blue contracts," I need to make sure I got the blue one, and not the red one. And that's input-output. And now it doesn't matter.
\n\nEddy is frantically waving, "Mike's on the call. Mike's on the call."
\n\nMATT: [laughs]
\n\nDAVID: Welcome, Mike. We were just talking about...well, today on the Acima Developers podcast; we are baiting and switching Justin on his habits stuff. We let him give a two-minute introduction on habits, and then we went down the rabbit hole of TDD and testing. Next week, we'll talk about ADHD and bicycles, which reminds me of a story about bicycles.
\n\nEDDY: To be fair, Mike, we also have circled back, and we were able to kind of deduce that TDD really does help with productivity.
\n\nMATT: I think it would be hard to argue that it isn't a good habit if you're doing it properly.
\n\nMIKE: You touched on something there: if you're doing it properly. There is actually some debate in the community about how religiously you should follow TDD. I think there are circumstances, particularly when I'm doing more exploration and generally within existing code, where I might not write TDD first. But then, again, sometimes it's for sure great to have a test, right? And you can use the test to see if something works. You can actually use the test to, you know, test that interface to see if it works. There may be some personal application there, but in general, TDD, while it may take a little overhead up front, leads to a reasonably performant process and generally leads to stability, right? Predictably, which is always a good thing.
\n\nEDDY: Can I just go ahead and also go on record in saying having TDD, specifically in RSpec where you have a context, and it block, it dumbs it down for me to better understand what that method is doing. So, when we're talking about productivity, like, my biggest complaint really is if this method is really complicated, I hate that it doesn't have comments. If you think it's complicated, either leave comments on there or have some gnarly, gnarly test that really breaks it down and tells you this is the context. This is the it block. This is the behavior. This is the [inaudible 23:30].
\n\nAnd having really good tests has actually helped me better understand what the purpose of that method really was and the intention behind it. So, again, circling back [laughs] to productivity, I was better able to have, like, a better-defined picture that attuned on, like, the changes. And I felt safer doing it as a result.
\n\nMATT: And writing good, clean code is much more productive than writing code that introduces bugs that you have to go back and fix.
\n\nDAVID: Ooh, but in the first five minutes, it's slower, right?
\n\nMATT: Oh, 100%
\n\nDAVID: It's so much quicker, right? I can jam in a fix that solves the thing that, you know, it's like, oh, hey, look, even-numbered contracts are the ones that are violating the TCPA standard. So, I'm going to reject texting messages for even-numbered contracts. Fixed it! It took me 10 seconds.
\n\nMIKE: [laughs]
\n\nDAVID: There might be some maintenance later. Future me will hate me.
\n\nMATT: Never [laughs].
\n\nEDDY: Justin, circling back [laughs] to the topic at hand, do you want to continue?
\n\nJUSTIN: Well --
\n\nDAVID: Actually, the reason we went...sorry. Sorry to jump on this again. I am actually steering towards you, Justin. The reason I brought up testing, in my particular bit, is that somebody reminded me on Twitter this week if they haven't seen the test fail, they assume that the test is wrong or hasn't worked. And so, this person has a habit that when they write a test, they make it fail every time. If they haven't seen it fail, they assume that the test is either not executing or not touching the code that's being exercised.
\n\nAnd I don't always follow that habit, and I will get bitten by a test that seems to be passing, and then I will break the code. And the test continues passing, and I get very alarmed. And then, I get very good about following that habit for a while.
\n\nMATT: Yeah. When I first learned how to do test-driven development, that was a requirement of the team.
\n\nDAVID: It's a [inaudible 25:30]
\n\nMATT: You know, we were programming, and we said, "Okay, it's passing. Now let's make it fail."
\n\nEDDY: If you make it fail, suddenly you have your unhappy path, right?
\n\nDAVID: The old Red-Green-Refactor mantra was, you get to red first, then you get to green fast, then you refactor until the code is, you know, not a maintenance nightmare.
\n\nMIKE: And I think that there's something there. I think that a lot of times we think, I need to test the thing, and so we're not very systematic about it. We say, okay, we'll start with a happy path, and then I'll start doing edge cases. And after that test passes, we think, okay, I've got pretty good coverage. Now, let me start covering the other things. And I think that that way of testing in this way that I've done it in the past, that I've changed over time, has some flaws. It really isn't structured in order to document your code. And we've talked about this in other podcasts. It's structured in order to help you maximize your efficiency in that moment to cover that specific part in the flaws.
\n\nAnd instead, I like to approach my code and say, well, what are all the branches? And I usually like to test all the broken branches first. And if you do that, you have verified that, you know, all of your validation failures are actually failing out, and then your happy path is kind of the last piece you get to. It takes a little bit longer, but then you get full coverage. You get better documentation out of it and avoid a lot of that risk of like, oh yeah, the happy path test works when maybe that wasn't even testing anything.
\n\nMATT: You're preventing downtime in the future.
\n\nEDDY: I don't know if it's crazy. For me, I like to see green dots first. Like, it super, super, makes me a lot more enthused to write code. I joked about this on a previous podcast, like, green dots have become my favorite-colored dot.
\n\nMATT: On that note, if you are doing test-driven development, it's going to fail first because your failure is what's driving your development.
\n\nDAVID: And I don't think those are incompatible statements, by the way, or even what Mike was saying. Like, I still see it. In my head, it's all green dots, right? That green dot means that this is exercising the code and that it's passing. So, we get to red first so that I know it's executing the code then I make it pass. Now I get my green dot, and I get cookie. It's satisfy. It make it work. And testing the unhappy paths, those aren't red dots, right? Like, the unhappy path is you tried to save a username that was, you know, 4K long, and the database only holds 50 characters.
\n\nThere must be a validation error that says, "Name must be less than 50 characters." And if I save a 4k thing and it writes it and it doesn't raise a validation error, but it throws away [chuckles] 3.9k of the name because it only said, "That's a fail," because it failed to validate, so you make the validation pass. And you get the green dot, and so it is; it's all green dots. At least in my head, it's all green dots.
\n\nMIKE: Yeah. It's all green dots all the way, but you're testing all the edge cases either way.
\n\nDAVID: Yes.
\n\nMIKE: So, you don't have to write a test that doesn't cover that case and then have to go through the pain of seeing the red dot. What you do instead is you write a test that captures all the bad cases and make sure that those all show green. Like, make sure those failure cases actually happen.
\n\nMATT: Let's take an integration test with MVC. First thing we may do is load up a model, right? But because we're doing test-driven development, that model doesn't exist. So, first run it's going to fail. Then, we go create our model. Next line, hey, we hit this endpoint in this controller. It then loads the model. We run it. It fails on that endpoint because it doesn't exist. It drives you step through step. And that's what I was trying to say, Eddy, is, sometimes, when we don't understand a domain, going about it in this manner helps us understand the domain but also makes it so we can work inside of that code without that full understanding.
\n\nDAVID: The other thing that gets me thinking is, like, when we get a ticket that we have to work in the code, it doesn't say, "Use a red-green or a red-black tree to sort the data in the database." You get tickets that say things like, "Stop sending text messages to customers who have opted out via TCPA because that's against the law." There's nothing in the database that says, "Don't break the law," right? And yet we will pull up code and, like, ultimately, the fix is going to be to add a where clause in the thing. When we do this, we need to join on the TCPA, you know, opt-ins or whatever, or however you can implement it.
\n\nAnd we might be tempted to write a test to say, "Are we checking the database for this one thing?" But if you're starting with TDD, you start with a customer who has opted out and another customer who's opted in. And you try to send them both messages, and one of them should receive the message and one of them should not. And that's pure io. Now, it doesn't matter how it gets developed, right? It literally could be, "Hey, there's this queue that we send to human operators who punch things in on a phone to call people, and that queue should not get the customer that opted out," or it could be a database query, or it could be there's a million ways to select data, right?
\n\nMATT: Yeah, because you know your inputs and your outputs.
\n\nDAVID: Right. When you get this thing, don't try to write a TDD of changing the way we filter from a list. You know, it's like, how am I going to reject on the MapReduce? No [laughs]. Start with your input. Start higher. Go up a level.
\n\nEDDY: I kind of want to punt this to, like, individuals who weren't here in the last podcast. And I kind of want to get their perspectives so more tailored towards Matt, Tad, and Enrique. What are some of the habits that you typically gravitate to when you're stuck on something, and you're trying to get more productivity? Like, what are some of the things that you do, like, instinctively that get you more productive?
\n\nTAD: Talk to someone else. A lot of times, if I just talk through it...like, you were talking about rubber duck earlier, Eddy, right? If I stop, talk through it, then, usually, I'll get some clues. I'm like oh, there's some variables I need to check, or, oh, there is where I might have gone wrong, right? Just talking it out, talking it through, even if they don't give me any feedback, is often helpful.
\n\nMATT: For myself, I would say my first steps usually aren't reaching out unless I know someone has a context on the problem I'm trying to solve. But I do have things that I almost always do; one would be Prys. I love Pry, you know, ruby-specific, but debuggers, breakpoints. And then, I step through because, ultimately, if you're trying to solve a problem, you need to know where that problem is happening, and I will always time-box a problem, always.
\n\nOne of the mistakes people make early on in their career is they don't want people to think they don't know something or they're inadequate, so it's a pride thing. Overcoming that and being able to reach out and ask questions will significantly help your process. Every day, I'm reaching out to people. It doesn't matter who it is. It doesn't matter what level someone is. Everyone has something to offer that we don't know. So, I think a good habit is asking questions and just being able to communicate those questions to your peers.
\n\nJUSTIN: One other thing that I think is helpful is to...it's been mentioned several times before, but breaking down the problem such that if you are stuck on one particular thing or kind of a general thing, you're like, oh, okay, how do I break this down? And keep on breaking it down until you get to something you can solve.
\n\nAnd then, by the time that you have perhaps identified, you know, okay, I can solve these five sub-steps, but I can't solve six, you've identified enough to bring it to somebody else who may have context. Because they'll probably ask you, "Oh, did you try A, B, and C? "And if you were able to break it down, you'll be able to go to them and say, "Okay, here's my work so far. You know, I don't have any idea how to do this," But rather is, "Oh, okay, here's the original problem. Here's what I've tried to solve it. Here's the progress I've made, but I'm stuck on this particular one," and just explain to them everything that you've done.
\n\nAnd then, they'll be able to answer, "Hey, did you try this?" Or they might be able to answer, "Hey, you're barking up a wrong tree." But it's also, you know, you combine that with all the other suggestions of time boxing and things like...you don't want to go too far down the wrong rabbit hole. So, there's a balance to be had there. But, you know, do your work and do your homework and try something.
\n\nEDDY: Oh my gosh, I've never thought about timeboxing a problem [laughs]. That's so cool. Just to bring everyone kind of up to speed, Tad and I were pairing earlier today, right? And we were trying to figure something out. And he said, and it's kind of stuck with me even now, he's like, "Okay, let's try to figure out this problem. But if we can't figure it out, we'll timebox it. We know how to fix it another way, but we don't like this other way. We're going to try to fix it this way instead, but we'll timebox it for, like, 10 minutes." If we can't figure it out in 10 minutes, suddenly, your productivity kind of starts spiraling down because you're still stuck on the same problem.
\n\nSo, just saying, "Okay, if in 10 minutes we can't figure this out, we still know the solution. We'll do the other solution as a fallback." But you're still moving forward on your problem, right? Oh my gosh, you know, timeboxing is so cool. I didn't think of that.
\n\nMATT: [laughs]
\n\nTAD: Because I was like, there's an elegant solution here if I could just find it, right? And there's a way that works, but it's kind of ugly. I'm like, "Eddy, if I can't find the elegant solution, we're just going to...in five minutes, we'll stop and do the ugly thing instead."
\n\nMATT: That's kind of a good segue into what else I was going to say, and that is stepping away. Oftentimes, just stepping away from a problem is a good idea. So, if you have an elegant solution in your head and you think this other one's sloppy and you implement it, step away. The elegant solution may come to you. You know, sometimes just kind of walking away from something, giving yourself a breather because we tend to get tunnel vision. And I think getting outside of that tunnel is extremely helpful.
\n\nDAVID: I used to rock a standing desk, and I legit believe that the number one value of the standing desk...nothing to do with health or with any of that. The number one value of the standing desk was that I was much more likely to step away from the computer once every 30 to 60 minutes just to think about the problem. And it stopped me from fixating and tunnel visioning on a problem for two hours, three hours, five hours so many times.
\n\nMATT: We want to solve problems. That's why we do what we do, right? And I think all of us tend to get tunnel vision and get stuck in these problems because we're so stubborn that we just want to solve them. And a lot of times, walking away for a few minutes can help do that.
\n\nDAVID: I just realized that dovetails perfectly into Justin's habit thing that if you're standing up at a standing desk, it makes stepping away to switch from fast thinking to slow thinking, to tight focused to, like, spreading out to wider thinking, it makes it so that that's easy. It's attractive [laughs]. There's no start-up cost. You just take a step back, stretch your arm, and then just walk over to the window, right? Because there's no pushback, change state, stand up, deep breath. There's none of that big state change. You're already standing up. Just walk over the window and breathe.
\n\nENRIQUE: I'm trying to Google what time box a problem means.
\n\nDAVID: Oh. It means to decide in advance how much time you're going to spend on this. You draw a box on it on the calendar and basically say, "We're going to work on this for half an hour." The value of this is you can say that, "We've got a bad way to do it. We don't want to do it this way. But it's not worth spending 10 hours on to avoid this problem. If we can't solve this in 30 minutes, it's not worth solving."
\n\nSo, you just draw a box around it on the calendar and say, "We're going to work on this for 30 minutes. And if we're done, we're done, and if we're not, we're not." Or at the end of 30 minutes, you can say, "We're really close. It's worth another 30 minutes." You can extend your time box. But, again, you stay boxed. You don't let your time become open.
\n\nMATT: If I have a problem I don't know how to solve, because a lot of us are self-learners and we like to just figure things out ourselves, we say, "Okay, I'm going to spend an hour trying to figure this out on my own. And if I don't have a solution, then I'm going to go talk to somebody else and reach out."
\n\nEDDY: I love the fulfillment, though, that I get if I resolve the problem myself. Like, there is some sort of joy in myself, like, self-pleasure, where I'm just like, oh, I did it, right? Like, I was able to overcome that, and I found the solution that I was looking for. However, there's times where, like, I've been stuck in a problem for, like, an hour, reach out to someone who I know will have the answer and be like, "Hey, I have this failing spec, and I can't figure this out, you know" And they're like, "Oh yeah, it's because you need to do this." And suddenly, I'm like, oh man, why didn't I see that before? But there's value to that because, like, that solution gets cemented in your brain much better because you struggled to find the solution much longer.
\n\nMATT: I think a good habit, too, since we're talking about habits, is when you do finally reach out for answers and information, make it a point to understand why. Instead of just getting the solution, understand why it is the solution and how it is a solution. That way, the next time you run into a similar problem, you have the tools you need to be able to solve that problem.
\n\nEDDY: Yeah, for me, I found that I need to struggle on that problem for a little bit longer so that I can better understand the issue so that when I do get the answer, I understand it more in-depth.
\n\nMATT: Yeah, and --
\n\nDAVID: I think it's useful to know in advance, do I want to use this solution to solve this thing in the world, or do I want to work on creating the solution? Sometimes I don't want to carve wood. Sometimes I want to build wood carving tools. And sometimes I would rather work on my software tooling than build software with my tooling. And so, knowing in advance, what do I want to do?
\n\nLike, if I want to build the tooling, I don't want somebody else's help. I want to discover it myself. I'm in it for that joy. And if I go ask someone for the answer, I give up that joy. But if I just want to solve the problem so I can do another thing, every second I spend trying to find the solution is time not spent using the solution to get what I want. And knowing to switch hands and say, "Oh, just give me the thing," right? "Google, give me the answer. ChatGPT, give me the answer," because I just want to get on down the road to solving the thing.
\n\nMATT: Yeah, I think sometimes, I mean, and we're in a business environment, so we do have to limit the time we spend on these problems. But if we're getting the answer, getting the solution, if we also get an understanding of how that solution was created and why that is the solution, then the next time we come around, that tool is in our toolbox.
\n\nDAVID: We're not just in the business of producing software. We're in the business of producing programmers. That is one of the outputs of our system. And so, yeah, investing in figuring out the solution, definitely worth it.
\n\nMATT: Yep, and everyone benefits from that: we as engineers, the company from the ability we create to be able to develop software and mentor others as they come on board and make them more efficient. It's a win-win.
\n\nEDDY: I actually want to say something, and you all might laugh, but I stumbled upon this solution that helps me become more productive, and that is eating [laughs].
\n\nDAVID: No joke. Yes. How's your blood sugar?
\n\nEDDY: I'm not kidding. I'm not kidding. Like, there's times where I'm just like, I've gotten up. I've gotten to my kitchen, gotten a snack, sit down for a little bit, come back up fed, you know, and I'm like, oh, yeah, that's the problem [laughs]. Eating, eating has helped me tremendously on my productivity.
\n\nMATT: There's a reason they call it hangry. I'm the same way. If I go without eating, I can get snappy and --
\n\nDAVID: I worked with a guy years ago. The question "Have you eaten?" is on my list of questions to ask when nothing else is working. I actually have a list of things to ask when you're out of questions, and "Have you eaten?" is on there. I had a co-worker who was just grumbling, and he's wicked smart. He got a PhD in geophysics, and he's trying to solve a seismology vibrational problem in software. And I can hear him muttering and cursing, and he'd been doing this all afternoon. So, I was just like, "Don, have you eaten?" And he pauses, and his eyes get real big, and he's like, "No," and I'm like, "Get your stuff. We're going to get a cheeseburger."
\n\nAnd part of it might have been the walk, part of it might have been stepping away from the computer, but by the time he had come back and his blood sugar was back up, he knew where to start the next piece of the software. So, you are bang on. Keep that question, Eddy. It will save your career.
\n\n[chuckles]
\n\nMATT: Rest is right there with it, too.
\n\nDAVID: Rest. Yeah.
\n\nMATT: You know, yesterday, Travis, one of our other engineers...you all know him, but our listeners may or may not. We were working on a problem together, and I was running on...I think it had approached about 36 hours of no sleep, and, you know, I started my day at about 5:00 a.m. yesterday, and it was going on the 13th hour of work for the day and 36 hours of no sleep. The simplest of problems become difficult. If you aren't rested, then that's a real thing.
\n\nDAVID: Sometimes, the most productive thing you can do is get your head down for six hours. Yeah.
\n\nMATT: Yeah, and I just finally I was talking to him, and I said, "Travis, how about I hand this over to you? You drive because I just am not functioning at the moment."
\n\nTAD: You've reminded me, you know, like a few weeks ago when we decided we're going to go for periodic walks around the office, and we fell out of that habit.
\n\nEDDY: It's a great habit to have, I think, right? Like, it takes your mind away from, like, just being stuck at your computer for so long. And I hope, like, higher people don't hear this, but that is part of why I like going into the office. It's much easier to reach out to someone to the side and be like, "Hey, Dave, question for you. I'm stuck in this problem. What would be your approach?" And kind of, like, bang off ideas out of each other. Like, when you can do that, there is solutions to that. Or sometimes just going on a walk for a little bit, like we said earlier, right? So yeah, just like what Tad said.
\n\nDAVID: I think the answer might be written on the mountain. Let's go look. Let's go out to the parking lot and look.
\n\nMATT: Yeah, that encompasses the stepping away. And, obviously, exercise is healthy. It gets endorphins going that may not be present just from sitting at your desk. I don't think anyone can argue against taking the occasional break and doing that. It makes us perform better.
\n\nEDDY: Enrique actually wrote something, and I kind of want to say it on record. He said going to the bathroom really helps getting yourself unstuck and being productive [laughs], take that as you will.
\n\nMATT: And being tracked down by your CTO.
\n\nEDDY: [laughs]
\n\nDAVID: A little burst of adrenaline. Whoa, what? Getting up and going to the bathroom...I read a neurology study. They found that when you walk through a doorway, there is something neurologically that happens that causes, like, a refresh stripe to go through your brain. Like, it just passes through the neurons.
\n\nAnd they think this is why you can stand up and walk into the room to get a thing, and when you get there, you can't remember what you were going to get. And it's because the part of your brain that's holding on to that attention, go get the thing, gets reset by that refresh wipe as you go through. So, yeah, weaponizing that for good is get up and go to the restroom room, you know, go down the hall. Go talk to a coworker. I need to wipe all of the wrong solutions that I'm holding on to in my head. I need to just power off.
\n\nEDDY: Dave, I thought that was always a me problem. I thought, for me, I was just like, man, I think this is, like, early symptoms of, like, Alzheimer's or something. Like, how am I forgetting something so simple? And then, like, as other people, like, affirmed that it happens to them, too, suddenly, I'm like, oh, thank God I'm not the only one [laughs]. Like, other people have short attention spans also.
\n\nMATT: We've been talking about all these habits. Just another quick one just for record is, taking notes and recording meetings. Giving yourself something that you can reference, I think is a good habit as well. Historically, I was never a note-taker. Just because of the things I'm responsible for and have to keep track of, I have become a very consistent note-taker, and it's been a really good habit and helped me out a lot in my day-to-day duties.
\n\nEDDY: Matt, actually, this is really interesting because, like, I spoke with someone the other day, and they told me, "Oh yeah, I'm a huge note-taker." And they're like, "I can be on my computer, but I find myself getting a notebook and writing, like, with a physical piece of paper and a pen on my hand." And I'm like, "Really?" I'm like, "Doesn't that take longer to jot stuff down? Because I'm sure you can type faster than you do write stuff down, right?" And they're like, "Oh, no, no, it's just, like, I've been groomed, you know, it's instilled in my childhood to take notes with a notebook. So, like, it's ingrained in my head, and so I'll do that, like, natively." And I'm like, "That's interesting."
\n\nMATT: I think for a lot of people, just on top of that, is, when you write something down, while you're writing it, you're also recalling that information, right? So, right there, you've heard the thing. You've written the thing and recalled the thing, and you're ingraining it into your memory.
\n\nEDDY: Yeah, but that also happens when you're typing. I'd argue that it's –
\n\nMATT: Yeah, yeah, sure, sure, but I just mean note-taking in general. I'm of the age where when I went to college, you took notes by hand. And I got really good at it for a while, but I don't write by hand often these days. Just having something to remind you and to recall and go back and reference is a really good habit because we all get so much information thrown at us so often that we can forget and lose things over time.
\n\nDAVID: I took a speed writing class in high school back when typewriters existed. You'd take dictation very, very quickly, and your notes are sketchy. And it's trying to, like, what the heck did I write there? And I skipped words. But the very first thing you do after the dictation is you sit down and you transcribe your own notes to better notes. And then, you take your transcribed notes and you type them up, and that process of reviewing your own notes twice is hugely beneficial for memorizing.
\n\nMATT: Yeah, and there you go. Just by the time you get to the end of that process, you have recalled that information, like, four times. You start to remember it all.
\n\nEDDY: I was surprised when I first started, right? Like, my late high school years going into college, I'm like, how the heck are people able to write all this in a piece of paper and, like, recall everything that was said? And then, one of my teachers sat me down. He's like, "Well, because they're not writing everything. They're just doing highlights of what was said," and highlight. I was like, holy cow, that just opened up, like [laughs], another realm. I'm like, yeah, you don't necessarily need to write the does, the ifs, and whens. You just do only the highlights of what the conversation was had but enough where you can recall. And suddenly, you become super efficient.
\n\nDAVID: You start thinking about what is the objective of this? The biggest superpower for me in school was somebody said, "When you're taking notes, if you were writing the test for this class, what questions would you write from what was given?" And I turned in the sheet of my...I had the thing, and I had the questions that I wrote them down next to my notes. And the teacher actually pulled me aside and asked if I had...like, he didn't quite accuse me of cheating, but he wanted to know if I had been going through his desk because I had picked, like, 80% of the questions off of the test as a result.
\n\nEDDY: [laughs] But suddenly, that's a good thing when you do TDD, right?
\n\nDAVID: Mm-Hmm. Yeah.
\n\nEDDY: [laughs]
\n\nDAVID: Test-driven class note-taking. I like it. I like it.
\n\nEDDY: Suddenly, your coverage is much higher because you practiced.
\n\nDAVID: Yes. Oh, this has been a good round table chat. Thank you, guys, for coming. The one advantage of going so far afield when we invited Justin back for a part two is that now we can invite him back next week for a part three. Well, for a redo of part two.
\n\nEDDY: [laughs]
\n\nMATT: They always get a little off-topic, but I think that's the beauty of it, right? We segue, and we end up talking about useful information that I think everybody should have.
\n\nEDDY: I've actually made a habit on going half to what we were initially talking about. Like, I don't mind going on tangents, you know, every once in a while because that's how our brain works, right? But, like, being cognitive, right? Or conscious and, like, going back to what the original topic of the conversation is. Because otherwise, you'll spiral out, and you'll talk about --
\n\nMATT: I would argue today we did never really get away from the topic.
\n\nDAVID: No, No. You can't predict what you're going to discover when you start synthesizing new ideas. And, like, Matt, you kept just, like, lightning striking my brain. And I'm like, I did not expect that to fall out of my head and in the podcast. And I'm like --
\n\nMATT: [inaudible 50:56] [laughs]
\n\nDAVID: Well, no. It's like you were saying things, and it was causing just things to just precipitate like I'd had all the pieces of an idea in my head for weeks. And then, you said that thing, and I'm like, oh, man. Or, like, Eddy, when you said unit tests, and I'm like, aha, it's behavioral, not implementation. Yeah, right on.
\n\nEDDY: Well, David, this has been awesome, guys. Thank you so much.
\n\nDAVID: This has been great.
","summary":"","date_published":"2024-04-10T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/cbc02627-2a80-4134-b936-ee60e155108a.mp3","mime_type":"audio/mpeg","size_in_bytes":31543887,"duration_in_seconds":3089}]},{"id":"8474100f-d236-4cb2-a387-adc8f17c2897","title":"Episode 42: Habits","url":"https://acima-development.fireside.fm/42","content_text":"In this episode of the Acima Developers podcast, the panel talks about the intricacies of habit formation within the context of software engineering, sparked by Justin's interest in James Clear's Atomic Habits. Justin brings up how Clear's work resonated with his desire to become a better engineer and begins by identifying Clear's four laws of habit formation: making it obvious, attractive, easy, and satisfying.\n\nThe conversation unravels how these laws intersect with software development practices. For instance, making a habit obvious could involve placing reminders or tools in clear view to prompt action. The notion of attractiveness is discussed in terms of reframing mindsets towards habits, such as viewing challenges as opportunities rather than chores. Making habits easy is touched upon with examples like simplifying tasks to remove barriers to starting, while the aspect of making them satisfying involves setting up rewards and tracking progress to reinforce positive behavior.\n\nPersonal anecdotes and professional experiences shared by the panel highlight the application of these principles in their work as engineers, such as leveraging gamification to make tedious tasks more engaging or adopting meditative approaches to problem-solving. The significance of environmental and social factors, like changing one's surroundings or engaging with communities of practice, is also discussed as a means of supporting habit formation.\n\nTranscript:\n\nDAVID: Good afternoon and welcome to the Acima developers podcast. We have got a really fun panel and topic. It's kind of exciting today to talk about habits. We've got Eddy, and Mike, and Ramses, and we also have Justin on. Justin was the one who asked about this. I'm just going to hand this over to you. You've picked up something, and it prompted a question. I'm just going to hand you the mic.\n\nJUSTIN: All right. Well, I don't know if I really deserve it for that much, but we'll go over what I was thinking of. So, I was listening to a podcast, The Peter Attia podcast. He's a great guy who does some very involved podcasts that are often, you know, several hours long. But one of the ones that he has was with an author by the name of James Clear who wrote Atomic Habits. This is a book that came out a couple of years ago, like, in 2018, I think. 2017? \n\nIn it, he talks about how to basically make habits that help you and break habits that hinder you. He doesn't necessarily talk about the exact habits that people want to do other than kind of, like, the obvious ones. But it was kind of an interesting conversation around how we make habits and how those habits help define who we are. And then, he goes into, like, how we define ourselves or how we want to define ourselves, how important that is in our lives if we want to lead a fulfilling life. \n\nAnd he goes in and talks about if you want to be a better person, you have to define that better person. And then, you have to think about the things that that better person does. And by doing those things, you know, that makes a new definition of who you are. And so, a good example was like, a habit that you're trying to do is eat better. And so, rather than saying, \"I'm on a diet. I'm trying to stop eating these certain foods,\" you say, \"I'm a healthy person, and I'm going to eat healthy food.\" And there's kind of an interesting distinction there. But this is kind of a long-winded answer to, like, a developer podcast.\n\nDAVID: No, it's good. We do that here.\n\nJUSTIN: [laughs] But tying it back to this, I was thinking about, I want to be a better engineer. I want to be a great engineer. What are the things that I can do? What habits can I make that define me or that can define me as a great engineer? The question I want to bring to the group is like, what are the habits that people have that they've found help make them great engineers?\n\nDAVID: That is fantastic. I had told you in the pre-call that I hadn't read Atomic Habits, that I had come at this from the other one. But James Clear he's the guy that played baseball, right? And he had, like, a career-ending injury in high school?\n\nJUSTIN: Yeah.\n\nDAVID: And then he picked every behavior performance, behavioral habit that was holding him back or that he needed to work on. And he ended up captaining the college baseball team?\n\nJUSTIN: Yeah, basically, he kicked butt. He actually has a couple of laws in his book, the four laws that help define how to make a habit, and we can go into those a little later. I don't want to necessarily make the podcast about that, but we can go into that later. \n\nDAVID: We certainly can, like, maybe, like, survey them a little bit. I have started Atomic Habits. I think I got to the part where he was talking about his bio, and I'm like, yeah, get to the meat. So yeah, so I came at this from reading The Power of Habit by Charles Duhigg and Tiny Habits by BJ Fogg. It's like an email list.\n\nJUSTIN: [laughs]\n\nDAVID: This will date me a little bit. This is, like, 2009 kind of thing. But do we want to take just a real quick minute and touch on these things? I don't want to spend, like, a thesis defense on all of these things. But if you want, I can have you throw out the four things that you're thinking of because I want to make sure we cover the topic the way you're looking at it. I don't want to just turn it into the Dave Brady show and say, \"Oh, let's talk about dopamine, and motivation, and da da da,\" unless that's where you wanted to go with this.\n\nJUSTIN: Those all come into it. So, why don't I talk about these four laws, and then we can kind of discuss those items? And then, we can go into, like, some specific software engineering habits. \n\nDAVID: Fantastic. \n\nJUSTIN: Law number one is make it obvious. So, make whatever you're trying to do make it very very obvious about what you're trying to do. He goes into different strategies for identifying and creating cues to make and break habits, so things that are very, very obvious. \n\nEDDY: Can you elaborate on number one on what you mean by make it obvious? So, for example, if you're trying to achieve something, it should be easily explainable to someone. Is that sort of what you mean by obvious, or? \n\nJUSTIN: Yeah. So, what I mean is, like, if you have a goal of reading books, of reading specific books, put them right in front of you. Put them on your nightstand. Put them on your pillow. Don't hide them. If you're reading them on your Kindle, you know, put them on your home screen, or something like that, or put goals. Put things that will remind you to do the thing. \n\nAnother good example is if you want to eat fruit every day, put fruit around in front of you, hopefully, in front of the potato chips [laughs], such that you see the thing that you want to do. And another one, if we were to tie it back to programming, well, actually, let's wait, [laughs]. Let's wait on that. But first, law number one, make it obvious. \n\nDAVID: My 10-second take on that is that I want to get better at guitar, and I have a couple of guitars. And I hung my guitar on the wall, and it is about four feet away, and it never gets played, which is why my other guitar is literally on the floor in arm's reach, where I literally don't have to even lean over to pick it up.\n\nEDDY: I do want to say that maybe making it obvious, putting it in front of you, does attribute to using it, right? And this might be part of the other topics you want to talk about, like, with your points. But I have found that putting it in front of you, and giving you arm's reach, at least for me, it didn't really help. What really helped I was exposing myself with individuals who already did what I wanted to achieve. \n\nDAVID: Ooh. Modeling behavior.\n\nEDDY: So, for example, if I wanted to read more often, then I'd join a club with individuals who would read on a daily habit. That sort of motivates me to kind of follow the crowd. And it is not just applicable for reading books, like, in general, you know. \n\nDAVID: I think that actually dovetails into...I'm not sure how Clear...Fogg does motivation and trigger are two of his things, and the motivation is that. I bet that's the make it attractive that you were about to say. \n\nJUSTIN: Yeah, exactly. The make it attractive, however you do it, you need to make it something that you want to do. And you can incentivize yourself various ways into doing it. You can bundle it together within a reward. You can make it a habit, some sort of ritual that you do every day. You can put social incentives around it. So, do it with a buddy, or do it with a group. \n\nThe other thing he mentions is, like, reframe your mindset, so rather than saying, \"I have to do this every day,\" say, \"I get to do this every day.\" And getting to do it is, you know, making it more attractive in your mind. So, those are the kind of examples on the attractive side. \n\nEDDY: I'm curious if maybe I'm getting ahead of the topics here, but, like, how do you get over the hurdle of wanting to read when you don't have the motivation to read, right? Like, that's really the key, right? \n\nJUSTIN: Yeah. So, all four of these laws are designed to help you get over that hurdle because they go into, like, the theory a little bit behind habits. Like, what makes a person get bad habits, and what makes a person get good habits? They brought up a lot about smoking because, obviously, smoking is not the best thing to do. But you have to recognize that smoking is a very in-the-moment reward. Like, you get that nicotine hit. You might get the habit of doing it. You get the social if you're, like, going out and smoking with somebody. \n\nSo, there's a lot of immediate rewards to smoking that makes it easy to fall into that habit. If you think about it, the long-term consequences of smoking are really pretty bad. That's why these laws are designed to help you overcome the short-term attractiveness of bad habits and help you realize the long-term benefits of habits.\n\nAnother example kind of going the other direction is exercising. When you start an exercise program, you know, for the first couple of weeks, you're, like, feeling like crap. You're like, oh, my body is not designed to move that way anymore, or you're always sleepy, or you have aches and pains that you never had. And so, all of those things prevent you, like, short-term prevents you from wanting to do that exercising. But the long-term things really help you out a lot. And so, these four laws help you do the long-term.\n\nEDDY: I was actually going to interject a little bit here and say maybe I'm just wired differently than most people because I actually have the opposite effect when I start working out. I'm like, oh yeah, two-three weeks in, I'm like, I have good rhythm. I feel amazing. I'm super motivated, you know. And then comes the big fall of, like, I don't want to get out of bed. I hate getting up at 5:00 in the morning. I hate eating healthy, you know, and, like, just, I sort of, like, spiral then.\n\nDAVID: There's a novelty effect that is especially exacerbated if you have ADHD, where doing something new is ten times more rewarding than doing what you've been doing. \n\nEDDY: Exactly. Change of habits.\n\nMIKE: There's something related to this. You mentioned smoking. I wanted to share, but I'd have to go look up the source. But there was some research done by a woman, and this is relevant because this was done in, like, the 60s. And her research was ignored because she was a woman until it was very clearly verified, and she was vindicated. And she was right, way ahead of her time. But I can't remember her name, so I'd have to go look it up. \n\nShe did research about soldiers returning home from Vietnam, and a lot of them came back with a heroin addiction. And she was researching, and what she found was that soldiers who quit before they came back from Vietnam to the United States were usually able to stay clean, which is almost unheard of in addiction. Because if you're addicted, you're addicted. But the soldiers who got clean in Vietnam and then came to the United States were able to stay clean. But those soldiers who came back and used while in the United States were not able to stay clean.\n\nDAVID: Oh wow. \n\nMIKE: And this is, I think, really connected to this idea of habits because if you can change your environment...and, usually, we can't go from being a soldier in wartime to, you know, a civilian life, and that's such a dramatic life change that most of us can't pull that off. But there are things that we can often do to change our environment, to fundamentally reshape the way that we do things. Put the fruit in front, for example. And she found that that was critical, that something even as extreme as heroin addiction, which is, you know, known to be very problematic, could be overcome if you are able to change your environment. \n\nSo, not just give up the bad habit but couple that with a lifestyle change, you know, dramatic. When I say lifestyle change, a life change, right? You know, going from one set of habits to another, and I think that some of these fundamental shifts really need that kind of change in mindset. You say, \"Well, I'm going to do this different.\" And the way that you make it happen is by living that different life, and if that's the life that you're living, it becomes this new routine. You know, you've established a new identity almost. \n\nJUSTIN: Absolutely. \n\nDAVID: Those were the first two, Justin. What were the other two? \n\nJUSTIN: So, law number three is make it easy. And this talks a little bit about the two-minute rule, and now we're getting to the parts that I haven't read yet [laughs]. But what I believe this is, is, like, make it so that you can start doing your new habit within two minutes, so whether that means having a gym in your home or whatever new habit you have is not, like, a whole bunch of prep work or friction that you have to work your way through before you can start doing the new thing. \n\nDAVID: I had heard the two-minute rule expressed in another way, which was, it was part of, like, making it tiny and accessible. And I may have misunderstood this. The version of the two-minute rule that I had heard was make it something that you can commit to just do it for two minutes, and then you give yourself an out. And so, it's part of the, like, how do I make this less painful, right? It's like, nobody wants to get an exercise program. That's too big. \n\nJUSTIN: Oh no, yeah. \n\nDAVID: That's too much work. \n\nJUSTIN: Yeah, I think you're right, actually. I think you're right.\n\nDAVID: But, like, I can walk for two minutes and then turn around and come back. And then, I've just walked, and that's all I've done. \n\nEDDY: You know, a really easy way to achieve that is to just get a dog [laughs]. \n\nDAVID: You'd think that, but I also have a wife. \n\nEDDY: [laughs].\n\nDAVID: And so, she's the responsible adult.\n\nJUSTIN: Yeah, I think you're right as well. Now that I looked a little farther into it, I was like, oh yeah, you're right. So yeah, doing it within two minutes. It mentions that it, like, overcomes procrastination and laziness that you could do it within that time period. I kind of question about that. But like I said, I haven't gotten that far in the book yet, so...\n\nEDDY: I guess I have a question. Is [inaudible 13:53] the moment that it crosses your mind that you should do it or the moment that you established when you want to do it and do it within those two minutes? Because I'll go on record in saying that I have a really short attention span. So, I can have, like, a really good idea and be like, oh yeah, I should really go get some food [laughs]. If I don't do it exactly within, like, seconds that I think about it, I won't do it. \n\nJUSTIN: So, in here, I just saw another example. It talks about a famous writer called Anthony Trollope, who I've never heard of before, but he published quite a bit. Instead of measuring his progress based on the completion of chapters of books, Trollope measured his progress in 15-minute increments. He set a goal of 250 words every 15 minutes. And he continued that pattern for three hours each day. So, it was, you know, rather than writing a chapter a day or something like that, he shrunk his goal from writing 3 hours a day to writing 250 words in 15 minutes. And that very measurable small goal allowed him to feel a sense of accomplishment every 15 minutes. And it helped move him throughout the day. \n\nEDDY: That's interesting, right? Because I want to say anytime I've always wanted to read a book, I felt awkward leaving it in the middle of the chapter. Instinctively, we want to get to the end of the chapter, so it's, like, a really neat way the way the author intended. \n\nI do want to add something, though. My wife and I tried something different the other day. It's kind of interesting. We'll, instead of finishing a whole episode, we'll watch half the episode and then stop, pick up on that half episode, and leech over to the next episode, and that way, you know, you're stopping abruptly halfway in the episode every day. And then, it doesn't leave you with the sensation of, ah, what happens next? You know --\n\nDAVID: Cliffhanger.\n\nEDDY: So, it's easier to stop, right? \n\nDAVID: Wow. That is the most psychopathic thing I think I've ever heard you say, stopping in the middle [laughter]. That's amazing. That's amazing. \n\nEDDY: But it works, right? \n\nDAVID: Yeah, yeah, no, it's, yeah. \n\nEDDY: Because instinctively, what we want to do is finish. Like, I think we just want to finish whatever we started, and leaving it like that or leaving things unfinished is kind of uncomfortable. But you get over the habit of binge-watching, you know, and you're able to control your habits much easier because it's much easier to tune off, you know, when it's something boring. \n\nDAVID: Related to the two-minute rule, BJ Fogg's Tiny Habits, he dials that up to 11. When he says tiny, he's like, think two-second rule. For him, the definition of a good habit is I want to get better at guitar. When I walk into my office and I see my guitar, I'm going to pick it up, and I'm going to play one note. That is literally the thing that you write up. This is what I will commit to do. \n\nAnd now it's so small that as a commitment, it's like, oh, I don't have to grapple with my fear of failure as a musician. I just have to play the one note, and whether the note sounds good or bad, I can do it. You can just take things smaller. And this is like what you're saying, Eddy, where, like, sometimes it gets too big and too painful. One way to move the teeter-totter is to just make it smaller and smaller and smaller and smaller without grinding too much into it. \n\nBut there's a bunch of stuff that I was reading up on dopamine, and it talks about, like, the writing 250 words in 15 minutes. I've had times where it's been I'm going to intentionally focus, and I'm going to write one sentence. And then, I'm going to step back, and I'm going to look at the sentence I wrote and go, \"Yes, I wrote a sentence.\" And then, I'm going to step in and say, \"I'm going to write one sentence,\" and it's this winch.\n\nAnd you look at it, and you think that's not going to be satisfying. One sentence doesn't mean anything. And that's how you poison yourself. That's how you talk yourself into this; oh, it's my whole writing career that's at stake because I've discounted that. Because guess what? That whole writing career is based on one sentence, and then another sentence, and then another sentence. \n\nEDDY: You know, early, early, early on in my career when I wanted to penetrate the industry, I read something, or someone told me, I don't remember, but it resonated with me forever. And they basically said, \"Starve yourself from dopening.\" Let me elaborate a little bit on that. And you probably have heard this. But instinctively, what we want to do is we want to reach out to a phone, you know, and browse, whatever, play a game, read something, go through the social media, whatever, you know, and, like, you're inducing your brain with dopamine. You're rewarding it, essentially.\n\nDAVID: Rewarding yourself for doing nothing.\n\nEDDY: For nothing, exactly. And there is a limit to how much your brain, and I'm paraphrasing here, obviously, but there's a limit to how much dopamine your brain gets. And if you starve yourself for those rewards and instead go cold turkey and just don't do it, you'll prioritize the things that you want to achieve first. And then, you reward yourself, you know, with getting on your phone, as an example. And it's just an easier way to kind of manipulate your habits.\n\nDAVID: Yeah. The small slicing on the dopamine, the trick that you're trying to get into, is to trick yourself into—you write the sentence. And this is going to sound stupid, but I've literally done this this month—where I hate exercising. I'm just not built for it. And I was walking down the street, and I literally looked at my neighbor's tree, and I said, \"I'm going to walk that far on the sidewalk.\" And as soon as I got there, I'm like, okay, yay, I did it. Good. Next tree, literally 15 feet. I'm going to walk to that one. \n\nIt's tiny, and it's stupid, but you're conditioning yourself to get that little, tiny hit of dopamine from chasing the task rather than completing the task. You want to move. If you focus on getting the reward, you'll actually drive yourself into a negative cycle, where it'll actually taper out. And if you focus on the pursuit of the task, you drive it into where all of a sudden, it's the chasing that gets after it that you enjoy. You don't enjoy winning the marathon. You enjoy grinding through, you know, pounding through mile 17, like I know anything about this. I'm literally talking a minute ago about walking from one tree to the next. \n\nJUSTIN: [laughs].\n\nDAVID: You know, but finishing the program is less exciting to me than it is to just bashing out one more module, one more function, one more refactoring. It's very satisfying to me. Okay, Justin, bring us home. What was the fourth one?\n\nJUSTIN: The fourth one is make it satisfying, and by that, he has a couple of examples of using reinforcement rewards. So, once you've completed your habit, have, you know, some sort of reward. \n\nNext one is habit tracking, you know, writing down in your journal or, you know, recording your exercise by a Fitbit or some other exercise tracker. \n\nNumber three is accountability partnerships, so doing your reward and working with somebody and letting them know that you did it. And it gives you a sense of accountability that you are working with somebody to accomplish something together. \n\nAnd then, finally, gamify the process, which is, you know, doing some sort of competition that incentivizes you to complete, you know, the new habit that you're trying to do.\n\nEDDY: Justin, I can't stress enough the tracking part of it. I'm sure all of you have heard, to a degree, P90X. One of the quotes that's said in one of those episodes is track, track, track. And, like, the way he kind of related to that is, if you don't track your progress on what you're doing, then how do you know you're getting better? Write it in a notebook. Write it in a whiteboard. It doesn't matter.\n\nBecause let's say, for example, your first week, you can only do one push-up. So, you go on the whiteboard, and you go, cool, this week, one push-up, right? The following week, you can look at that, and you're like, cool, I started with only being able to do one push-up. Now I did two, right? So, now you're able to contrast, and you're able to see easily the progress, your achievement. And so, being able to track your progress really helps to keep motivated, and I can't stress that enough. \n\nThere are times where we want to achieve something and, like, we feel unmotivated because we don't realize how far we've actually come because we're too busy looking at the actual ambition, you know, that we wanted to achieve, but we're completely lacking all the steps that we took already.\n\nDAVID: Tracking is key. I had a boss years and years ago who said...he was like six foot six, and he loved playing basketball, and I was not a very competitive person; I'm still not. But he was trying to explain to me the notion of competition, and he basically said, \"If you're not keeping score, why play?\" He didn't want to see other people lose, but he wanted to rack up the highest score possible. And he loved it when he had somebody who forced him to score well in order to play. So, it was a very positive style of competition, but he was very enthusiastically competitive about a lot of things. \n\nDovetailing on that, Goodhart's Law, I think, is what it's called, which is when a metric becomes a goal, it ceases to be a good metric. But the reverse of this is when you gamify something, some things we try to reach an objective, and the goal is to get the objective and win and finish. And other times the objective is to keep the game going, keep it playing, keep it moving for as far as you can. And when you gamify something, you're kind of weaponizing the opposite of Goodhart's Law. You're basically saying, \"Oh, I got two points. I got three points. I did this.\" \n\nCircling around to Justin, because we spent half our time talking about what this is, and I feel like it's important.\n\nJUSTIN: [laughs].\n\nDAVID: But, like, segueing into, like, engineering habits, like, we have, you know, multiple websites that keep track of how many pull requests we've opened, and how many reviews we've done, and how many lines of code we've turned in. All of these we know they are bunk metrics for code quality and how good your project is and all that stuff. But as a scoreboard for gamifying something, it's very satisfying.\n\nJUSTIN: [laughs]\n\nDAVID: And that keeps you playing the game, and that makes you get better. And that indirectly causes the code quality to go up and the satisfaction to go up. Very, very interesting. \n\nEDDY: I don't think that kind of works for me, though, Dave. I'm not competitive by nature -- \n\nDAVID: Neither am I.\n\nEDDY: I'm okay with losing, and I'm comfortable with it. \n\nDAVID: Yes. \n\nEDDY: But some people utterly are distraught by the idea of, like, I cannot lose, and if I lose, I hate myself [laughs]. \n\nDAVID: Yeah. Yeah. And I am not that at all. But I am not immune to the pleasure of seeing the line go up when I measure something. \n\nJUSTIN: I think it's interesting how you don't have this one-size-fits-all solution. I think the emphasis here is do what works for you. If gamify works for you, gamify it. If, you know, small rewards work for you...we're trying to follow these four laws, but at the same time, there's lots of ways that we can accomplish them.\n\nDAVID: There's developers that I've worked with who you can set your watch to them. They show up at 8:00 o'clock. They pound out a thousand lines of code. They go home at 5:00, day in day out. And they're just machines. And that is not me. I am very much not somebody to mark time on a clock. And I felt really bad about it until somebody pointed out. They were like, \"Dude, when you see a rabbit run across the field, you are off like a shot, and we don't see you for three days.\" \n\nJUSTIN: [laughs].\n\nDAVID: And I'm like, yeah, I will tear off after that field, and my wife will be like, \"I guess I'll see you Tuesday.\" And then, Tuesday, she's like, \"Will I see you Tuesday?\" I need more fingers than the fingers of one hand to count the number of places I have worked at where I took a sleeping bag to work because I was in the habit of sleeping under my desk to do, like, a 36-hour rotation multiple times. That's my privilege and the way my family grew up. I had that time and a wife that was willing to support that and no kids at home. But it was an opportunity to do some very, very hard work, and I did it, and that was me chasing after rabbits.\n\nSo, if there's blood in the water, I go full shark mode. I try to bait the hook with something bloody and fresh and like, ooh, let's go do this thing. And I try to be compassionate with myself when 8:00 o'clock rolls around in the morning, and I'm like, I can't. I can't. It's just, ah, you know. I try to get the steadiness back in. And meanwhile, I lean on the guy on the team who, at 5:01, he's not around to answer the phone because he did what works for him, right? He marked his time. You need both kinds of people. You need dragon slayers, and you need bear skinners. \n\nThere is something that you touched on, Justin, and it circles back on the dopamine thing. Charles Duhigg wrote The Power of Habit. There's two books by that name, by the way, so Charles Duhigg is the one that I really liked. They were studying housewives. They put cameras in the bedroom to film them cleaning the room. And there were some wives who...this study was from the 60s, so it's necessarily very sexist.\n\nJUSTIN: [laughs].\n\nDAVID: But there were these housewives who kept an immaculately spotless bedroom, and there were housewives who struggled. And they asked them to just go in and clean, and make the bed, and da da da da. And one of the researchers, he's like...I want to give this guy just the biggest hug in the world because one of the researchers noticed a very subtle thing. It was like, if you blink, you miss it, but once you see it, you can't unsee it.\n\nThe wives who were very, very organized they would come in. They would make the bed, and after they make the bed, they would step back and they would just look at it for just a second. And then they would walk out. What they're doing is they're charging up the dopamine. They're basically doing the I did a thing. I made a clean spot. Go me. This is awesome. This is what I want. That's part of, like, the make it satisfying. So, jumping finally into engineering habits. \n\nJUSTIN: [laughs].\n\nDAVID: I don't know if this is [inaudible 27:24] be a graphic. I'll throw one out, and then I'll ask you guys what yours are. But I have a hook that when I want to push up a pull request, literally, there's a script called git cram, and it crams the PR into the server and tracks it and says, \"I want to open a PR on this.\" And the last thing that git cram does is it puts a message in pretty colored font that says, \"Did you run RuboCop?\" \n\nJUSTIN: [laughs].\n\nDAVID: I always forget to run RuboCop. And I hate RuboCop because it's very much of, you know, organized. We're going to do this organization, whether it makes the code readable or not. I don't know if I can ever be friends with B Batsov. That's the guy who maintains RuboCop. But when I see that sign, I crack open RuboCop, and I just look for the stuff that's low-hanging fruit, and I just do one or two. Maybe I do the dash a and do all the low-hanging fruit. \n\nThen I step back and go, oh, that is actually nicer. I do like this. I made a clean spot. And I might stop there. Half the time, I stop there and say, \"You know what? The rest of this is legacy code, and changing that's really tricky.\" And I don't want to fight that dragon right now.\" But other times, I'm like, \"Ooh, I'm on a roll. I'm going to finish this.\" And then, you get to that magical time when you run RuboCop, and you get a green dot. \n\nI don't know if the code is truly more readable, but I've got a, and, again, that's, like, the Goodhart's Law. As a metric, it doesn't mean the code is perfect, but I do have something that I've gamified. And I've got a green dot on the board, and that makes me very, very happy.\n\nJUSTIN: And I think it's interesting because you mentioned the green dot, and I don't think that's a mistake at all that green dots are all over the place where it says that you are doing something good. You got green dots when your unit tests pass. You got green dots when you push something that is all clean and everything. And so, that green is just like, hey, I just did something, and it feeds a little jolt of dopamine that you're happy, and that makes you happy. \n\nDAVID: Yeah. There was a phrase going around in the noughties: test infected. And people in the Agile community, especially, were banding this, \"Oh, I'm test-infected. I want to write tests. I want to do unit testing.\" And the hallmark of this is you get addicted to the green bar. \n\nJUSTIN: [laughs].\n\nDAVID: And it's real. I have, like, physically felt uncomfortable because I had not seen a green bar in a long time. People who have paired with me know that I have colored lights, a light strip over on the wall. And when I run my specs, they turn blue, and when it finishes, that whole light strip on the wall over my desk turns red or green.\n\nJUSTIN: Wow.\n\nDAVID: And it is very, very satisfying. People that I work with they don't pay attention to that. They don't track it and do the, \"Ooh, that's good,\" or \"Oh, that's bad.\" You get blind to it. You don't focus on what the output of your specs are. And so, you don't notice you've got pending specs, and you've got warnings, and you've got errors. You just ignore them. You're like, yeah, whatever, specs, whatever. And I'm over here going, that turns the spec output yellow! Yellow is not green! It's...no! Don't do that! \n\nJUSTIN: [laughs].\n\nDAVID: I feel bad! You know, and everyone's like, \"Dave, calm down. What are you freaking out about?\" I'm like, \"I need my green specs! I need green dots.\"\n\nJUSTIN: All the methodologies that are out there to help us be more productive and things like that, how much that feeds back into these habit-forming things. We talked about the habits of breaking the thing that we want to do down into smaller and smaller parts. That kind of rolls right into breaking our stories down into more manageable stories where we can get that shot of dopamine that we completed a thing within a day or something like that, rather than trying to work on this new feature that's one story for a week or two weeks, or something like that. Having that tighter cycle benefits us in so many ways. And it kind of rolls right into this habit-forming that we have talked about. \n\nDAVID: Absolutely. Absolutely. There are a whole bunch of habits that I have that somehow got filed into the banks of my brain as Engineering Discipline: Capital E, capital D. And it was before I knew what habits were. It was just like, if I'm a good engineer, I have to do these things. If there is a holy first commandment of engineering discipline is, do not commit code that you have not run the tests on. And it is very rare, not impossible, that it happens. It's very rare that when I push a pull request up to GitHub, Jenkins pulls it down and runs it. It's very rare that CI fails on me. \n\nAnd when it does fail, half the time, it's because of a flaky test or something in the system broke rather than what I did, and it's because I'm religious about it. And when I find myself in a spot where I can't run my tests the way I want, or I'm working on something that I can't lock down, and I get the computer to tell me, \"Yes, this does what we think it does,\" first of all, I get very, very anxious. And secondly, my compromise, my fallback engineering discipline is I commit myself to chiseling away at whatever is stopping me from being able to run my tests.\n\nSo, on the team that I'm on, if you run any test suite with database-seeded data, it takes 90 seconds to start up the test, and if you've got ADHD, that's awful. I'm in the kitchen making a sandwich. I'm talking to Liz. I'm at the grocery store picking up a soda pop. And, like, wait a minute, how did I literally end up across town? I'm supposed to be running my test. \n\nJUSTIN: [laughs].\n\nDAVID: So, I figured out how to chisel away the tests so that they don't depend on the seeds. And I will run my tests without the seed thing on. And I was pairing with a programmer earlier this week who shall remain nameless to protect me from the innocent. They did bin/rspec. \n\nAnd he leaned back and he said, \"Now we wait for a minute and a half.\" And I'm like, \"Do you have spec seed turned on in your bash profile?\" And he said, \"Yep.\" And I said, \"You don't run your tests unless you have to. And you run them at the very end, and you run big, long steps before you...\" And he's like, \"How do you know all this?\" And I'm like, \"Because your tests hurt you. And it's like, do they have to hurt this much?\" So, that might be an engineering habit of if something hurts, try to fix it. If you can't fix it, chip at it. Just knock a piece of it. \n\nPower of Habit from Duhigg was recommended to me by Amy Hoy, and she did an online entrepreneurial class called 30x500 that I took and I really, really enjoyed. And one of the concepts she talks about is she calls it the winch. And the idea is you can succeed with just an inch of progress if you can make an inch and not lose it—if you can winch yourself forward just a little teeny tiny bit. \n\nSo, that makes you want to step back and say, if I work on this, am I slapping at it, and then I turn away, and it just comes back and goes back to rest? Because if that's the problem, I've got to pick it up. I've got to carry it across the lawn and set it down, or I can't make any progress because it's going to blow back and forth. \n\nBut if I can find something and lock it down, like git cram, for example, that little thing, that is an actual script on my computer in my path. And it just does git push and git set origin and track and then, you know, display the message. And when I first did it, all it did was push and do a track. There wasn't anything else to it, and it just kind of winched forward from there. I have a bin repo up on GitHub that's just all my public stuff that I put on all my machines. There's, like, 200 scripts in there now that I've built over 15 years. \n\nJUSTIN: [laughs].\n\nDAVID: I'm really proud of Git RuboCop because I type Git space Rubocop, and it runs RuboCop on the files that have changed since I last diverged from master, which, okay, that's not that hard to do. That's just RuboCop and a list of files—getting that list of files. I wrote another script called Git files changed that will tell you what changed, little, tiny thing. It makes the job easier, and then you come back to it. \n\nYou do have to be careful not to spend 40 hours gaining that one inch on something that your product owner doesn't need because that can cost you your job, and eventually, it will cost you your career. You have to learn how do I take five minutes on this and gain two hours down the road? There's an old xkcd comic about how long it takes you to do something versus how much time it saves you, versus how many times a day or week that you run this thing. It's just a chart, and it tells you this is how long before it will pay off.\n\nAnd at the end of the chart, it's like, this is going to take ten years to pay off because you run this once a year, and you spent 40 hours saving 2 minutes on it. You spent 2 hours on it, but you run it 30 times a day, and you only save 2 seconds, but that's going to pay off in, like, three weeks. And you're like, hmm, interesting. What are some things that you guys do that's down at the habit level that you don't have to think about; you don't have to summon this force of energy to tackle? You're just like, oh yeah, I got to do the thing. \n\nMIKE: One thing that's been on my mind as we've been talking about this, you know, there's all these little tricks we can do, and there's some utility to them. And sometimes, maybe you're not going to feel like it [laughs]. There's maybe two related things that I'm thinking of connected to this. So, I'm going to follow this thread first. I ran cross country in high school. For everybody's who's done that, it just hurts. \n\nJUSTIN: [laughs].\n\nMIKE: I'm just going to [inaudible 36:11]. And, actually, I had somebody tell me, a fellow cross country team member, that long-distance running is mostly about pain management. You know, the people who are really good at it get really good at tolerating pain and, you know, learning to kind of segment that off in their brain. And I thought, oh, that's interesting. I don't know how I feel about that [laughter]. I'm not vouching for the truth of that. It's actually not quite my point. My point is that if you think about what's happening to you physically, it's not necessarily fun. There are some, you know, endorphins that come from it that are nice. \n\nBut I loved it, not because I necessarily loved the pain that I was going through [chuckles]. And I wasn't particularly good either, by the way. I started the team late. I remember my first race I got last place [laughter]. Don't think of me as a great runner. I got better, but, you know, never great, but I just loved running around outside. I got to run around outside. The sense of capturing the beauty and awe of the world around me still sticks with me. I loved doing that. \n\nI noticed that Justin's profile image looked like he was hiking somewhere [laughter]. You know, hiking is not necessarily different. You go up there because you want to experience that beauty, you know, have some awe, some sense of being in something bigger than yourself. And it's related to the idea of a flow state. You know, people tend to become really successful when they are not immediately aware of what they're doing, but instead, they feel, like, one with the work.\n\nAnd similar to the hiking, to the running, doing something deliberately to be meditative, and developing that sense of meditative immersion, you might think, well, I can't develop that. But I think we can. It's something that you practice. It's like other things that you can work on. You don't necessarily go into the day looking for that hit of dopamine, or endorphins, or whatever it is. Instead, if you go in just as kind of an open slate, like, what am I going to experience [laughs]? It kind of washes over you. Rather than value judgments to your experience, instead, treat that experience as an adventure. \n\nAnd that subtle mindset shift it takes some work. It doesn't just happen, but it can change the way that you approach your work. That is one habit, I think, that has benefited me a lot is developing that kind of mindset that I can be there. I can have...the world is on fire [laughs]. Things are broken [laughs]. This is...I want to be cautious here. I'm not saying that we should be in an abusive or in a deliberately bad situation. \n\nHowever, developing the ability to consciously put yourself in that situation and say, \"Well, you know, this does matter to me. I want to provide for myself and my family. This is something I want to be doing.\" Then you can make a conscious choice to put yourself in that situation and go through all of the fiery arrows coming at you and find it fascinating, you know, and see it as, like I say, an adventure. \n\nAnd that particular approach works for me far better than being competitive. I don't really care if I win, but that sense of adventure, that sense of awe at the world around me is satisfying or is motivating in a way that nothing else can be. When everything else is bad, which sometimes it will be, if I can do it anyway because I've chosen to have this experience, it changes my mindset. And that's something that has, I think, helped me a lot. \n\nAnd a minor point, honestly: getting exercise when I can helps me to be a developer. It just helps your mind work better. All the tricks we talked about help with exercise. You know, help [inaudible 39:38] with somebody, go out with my kids, helps a lot. But even more so, developing that different mindset about the work, I think, is a big deal. \n\nDAVID: There's a thing that resonates so strong with me with what you just said. I can't remember where I heard it. I want to say it might have been Jordan Peterson. The comment that they made was bearing your cross is only bearable if it's meaningful. Otherwise, it's just a hell that you have to go through. The world's on fire, and people are upset, and there's money being lost, and people are screaming, and dah, dah, dah, dah, dah. And you're just in there going, \"I'm providing for my family.\" I don't know if I said this on the podcast. I know I've said this to you before, Mike, that sometimes the good money is to be found by shoveling crap out of a latrine. \n\nJUSTIN: [laughs].\n\nDAVID: And I have reached a point in my career where I can get down in that stinky, smelly, awful, terrible, and I don't think too much about what I'm up to my hips in. I just start shoveling because I know I'm making a clean spot. I'm making a clean hole that we can get some work done and get some, you know, some stuff done. So, yeah, you're not down there going, \"Oh, yay. Look at all this smelly poop on my shovel.\" No, it's, I'm making a clean spot. Every bit I lift is one tiny, little bit of poo out of this hole. That's what we go after.\n\nThe competition thing, like I said, I'm not competitive against other humans. Like, I can't stand to see other people be sad or be frustrated. But, for me, watching the number go up, like, the gamifying, so I will compete with myself. And so, I think it's important to find what is it that makes you tick?\n\nI've worked with you, Mike, enough to know that you have, like, a very meditative presence to things. And I can picture you just standing in the garden watching the azaleas and thinking, I need to prune the grapes back. I hate being outdoors. I hate plants. I'm allergic to anything if it's got chlorophyll in it. And I was like, what an awful way to do it. And I can see you in that environment going, the sun is shining. There's a beautiful breeze. There's a ton of work to do. And that's not what I'm here about. I'm here about this moment, this meditative moment that I can be present in. So, we've gone around the horn quite a bit. Are there any other tricks and hacks? \n\nJUSTIN: I mean, we spent a lot of time kind of defining what makes a good habit or how to have a good habit. I almost, like, want to have a part two of this podcast that, like, goes more into the good habits. \n\nDAVID: I'm realizing, like, one of the...I talked about my bin folder, and I thought, well, that's stupid. It's so small that nobody will care about it and value it, and I realized I've got a thousand of these little things. I have alarms on my phone. I have an alarm on my phone that tells me to check my alarms. I'm not kidding when I say that. \n\nJUSTIN: [laughs]\n\nDAVID: And what it is, like, I have time blindness. I can sit down at the computer. There's Slack, and there's email. There's a problem; there's a bug, da da da da da. [inaudible 42:20] is going off. And all of a sudden, it's 1:30 in the afternoon, and I haven't checked email, and there's a hot message on Slack that somebody's been trying to get a hold...right? So, I've got a checklist. It's like a pilot's checklist for flying a plane of: check this, sign in. You know, we have four different single sign-in thing, which is, you know, increasingly erroneously named single. We have four SO, I guess. \n\nSign into all four systems, then, you know, go do this. And that means you have to hit this one system that you don't normally do, which, oh, yes, I need to log in there. I need to check to see if I've got any trainings outstanding in our online training stuff. And it's on a checklist. The training thing is a good example. If I don't have an alarm on my clock to remind me to check, the only way I get my trainings done is when I literally start getting emails from the legal department saying, \"We're about to be out of compliance because not all our people are trained,\" and you are that people.\n\nJUSTIN: [laughs].\n\nDAVID: Oh, okay yeah. So yeah, I probably got a dozen of these that I realize are now probably too small. On the larger side of things, there's a couple of people that I've talked to in the past like Dan [SP] Cub is somebody who comes to mind. He's kind of a minor luminary, moderate luminary, not minor. He's moderately famous in the Ruby community.\n\nHe mindfully and intentfully writes experiments, you know, hypothesis. I'm going to try this, and I'm going to document and capture. And he will have, like, five code experiments running every week, and I've stolen that from him. And so, like, this week, I'm trying a thing where I write a test that's useful to me, and then I delete it. And I push it up. \n\nAnd I just got feedback from a co-worker going, \"Where are the tests?\" And I'm like, \"Yeah, they weren't any good.\" Maybe I should write some good ones. But it's an experiment, right? Try and...and the habit is try and experiment. Justin, I think you're right. I think a follow-up on this would be really, really good. I feel like we're getting to a good close for this one. Any final thoughts out the door?\n\nEDDY: I will say the thing that attributes to success, at least for me, was getting compensated for it. Like, that made loads of difference [laughter]. Circling back to development, right? Like, you can tell someone, \"Yeah, if you have the discipline, you can teach yourself.\" But what they don't really understand is it's a full-time gig, you know, doing that without any sort of compensation. And so, you're doing two full-time jobs or a full-time job and a part-time job. And it's really hard to continue to keep stabbing and stabbing and stabbing when you're not getting paid for it, right?\n\nDAVID: Yeah. \n\nEDDY: So, I will go on record to say if someone, you know, was trying to get good habits to penetrate the career, you know, and, like, establish some sort of status in development, getting into something, you know, that's remotely close to what you're trying to do really, really, really, really, really aids, you know, in success.\n\nDAVID: There's a whole thing we could dive into about career-adjacent activities, where you can expose yourself to an environment where somebody taps you on the shoulder and say, \"Hey, do you want to come play with us?\" And it's just blind luck. It's not blind luck. You sat down in the lunchroom next to the people doing the thing that you wanted to do.\n\nEDDY: Exactly. And, like, that can be applied to anything in life. Like, you want to get really good at basketball. You want to join the NBA. You know, you have to be comfortable doing that for hours and hours, for months and months without getting paid. Same thing, like; I feel like the surge of YouTube is a huge example. Like, if you're a YouTuber and you're like, \"Oh yeah, I want to monopolize, and I want to make money.\" [laughs] But what they don't understand, you know, is that people who found success in that platform did it and grinded for years.\n\nDAVID: For two years before they broke a thousand viewers, yeah.\n\nEDDY: Exactly. \n\nDAVID: Chris Williamson and Evan and Katelyn are two people that are really, really big that I like watching right now. And both of them talked about: we did this for years and no payoff. And it's interesting that they said they didn't do it investing in their future. They did it because they're like, this is the grind. We're going to get on this. This is going to be the grind that we're going to be on, and we're going to do this. And they focused on just do the grind. \n\nDon't focus on the reward because the reward is going to hit, and it's going to be pale. You're going to be like, I did all that for this? No, you did all that in order to spend two years of your life on a thing that you can now look back and say, \"I'm two years older, and I have all these things behind me.\" Cultivate that itch to learn something, and that'll keep you up at night reading programming books. \n\nEDDY: [inaudible 46:43] compensation, like I'm saying. I can't stress enough how much value that helps [laughs] that provides, you know, the success. \n\nDAVID: I'll throw this out as my closing thought on it, regarding compensation. I've always had an itch to learn. My wife was very frustrated. We were not making much money, and I was buying very expensive books, like, $100, $150-books in 1990 money, so, like, $50 books back then was a lot of money. And my wife just shook her head. She's like, \"I would be mad, except that you read them, and so I can't complain.\" \n\nJUSTIN: [laughs]\n\nDAVID: And I got into Perl programming, like, in 1999 or so. And in 2002, my Perl number was, like, three, I think? I'd never met Larry Wall, and I had never been asked to maintain the Perl tarball. Like, nobody knew who I was, but if you had a Perl question, I knew the answer. \n\nAnd I had a co-worker that came over to me, and he says, \"Hey, how do you get the length of an array in Perl?\" And I'm like, \"Oh, it's...\" and I gave him the line noise string of like, you know, pounds, dollars, you know, whatever it is to do that in Perl. \"And hey, how do you do a file X?\" \"Oh, it's this.\" \"Hey, how do I check for a range of things in Perl?\" \"Oh, it's this operator.\" \"Well, how...\" \n\nAnd about the 10th time he asked me a question, I'm literally writing code, and I don't even...I'm just like, \"Oh, it's this,\" and I keep typing. And I wasn't aware that I was doing it until he stopped and he goes, \"Do you just know everything about Perl?\" And I'm like, \"What? What?\" I have been glowing and coasting on that compliment for 20 years [laughter]. That happened in 2000, 23 years. That happened in Y2K, and I'm still happy. I was so startled. I'm like, oh my gosh, I'm not any smarter. You just asked questions that I knew the answers to, which turned out to be all of them. \n\nEDDY: I do want to say, though, that the outcome could have been not drastically different but, like, you could have had a different outcome had you been given those books to you versus you having skin in the game and investing hundreds of dollars, right?\n\nDAVID: Yeah. For me, that is the key difference between being invested in the payoff, in the reward, versus being about the grind. It's like, I'm going to do this. I'm going to put this effort in. You say compensation, and I'm 100% on board for compensation in the sense of I'm going to get myself on a payroll because then it's part of the grind. It's like early salary negotiations for me where it's like, well, I can tell that this number is bigger than that number, and I like the line to go up. That is a motivating thing. \n\nEDDY: I typically when someone...because I've had people who have said, \"Hey, well, how do you attribute your success?\" And I say, quote, unquote, \"Success,\" because, like, that's very subjective. But, like, there's people who do aspire, like, doing something that Ramsey and I have done, where we have been able to penetrate something without prior experience. And typically, my go-to advice has always been grind, discipline, and spending money on resources. And they're like, \"Oh, I don't know if I want to spend money on it.\" Like, if you spend money on something, suddenly, you're invested [laughs]. \n\nDAVID: And I would call that investment. I had a co-worker years ago who had 13 children. And we were talking about something, and I had stayed up all night reading about it. And I'm like, \"You're not reading about this in the office. How do you have time to have read about this?\" And he's like, \"I get up at 4:00 o'clock in the morning, and I have about an hour where it's quiet.\" And so, I'm like, \"Okay, so you're a lot more focused because you've only got an hour before all hell breaks loose and pandemonium breaks loose in your house.\" And he's like, \"Yeah, so I use that hour very intentionally.\" \n\nAnd we were comparing notes and I'm like, \"Yeah, you're getting about three times the efficiency because you're investing a resource that, for you, is so much more scarce.\" It'd be like, you and I go into the bookstore, and I buy a book for $50, and you buy the same book. But you have to pay $750 for it. \n\nEDDY: Huge. \n\nDAVID: One of us is going to read that book cover to cover and then eat the cover. \n\nEDDY: [laughs]\n\nDAVID: Ah, this was a good talk. I do want to carry this on again. Everyone listening, thank you for coming. This was awesome. I'm looking forward to talking about this again. \n\nEDDY: Let's do a part two. ","content_html":"In this episode of the Acima Developers podcast, the panel talks about the intricacies of habit formation within the context of software engineering, sparked by Justin's interest in James Clear's Atomic Habits. Justin brings up how Clear's work resonated with his desire to become a better engineer and begins by identifying Clear's four laws of habit formation: making it obvious, attractive, easy, and satisfying.
\n\nThe conversation unravels how these laws intersect with software development practices. For instance, making a habit obvious could involve placing reminders or tools in clear view to prompt action. The notion of attractiveness is discussed in terms of reframing mindsets towards habits, such as viewing challenges as opportunities rather than chores. Making habits easy is touched upon with examples like simplifying tasks to remove barriers to starting, while the aspect of making them satisfying involves setting up rewards and tracking progress to reinforce positive behavior.
\n\nPersonal anecdotes and professional experiences shared by the panel highlight the application of these principles in their work as engineers, such as leveraging gamification to make tedious tasks more engaging or adopting meditative approaches to problem-solving. The significance of environmental and social factors, like changing one's surroundings or engaging with communities of practice, is also discussed as a means of supporting habit formation.
\n\nTranscript:
\n\nDAVID: Good afternoon and welcome to the Acima developers podcast. We have got a really fun panel and topic. It's kind of exciting today to talk about habits. We've got Eddy, and Mike, and Ramses, and we also have Justin on. Justin was the one who asked about this. I'm just going to hand this over to you. You've picked up something, and it prompted a question. I'm just going to hand you the mic.
\n\nJUSTIN: All right. Well, I don't know if I really deserve it for that much, but we'll go over what I was thinking of. So, I was listening to a podcast, The Peter Attia podcast. He's a great guy who does some very involved podcasts that are often, you know, several hours long. But one of the ones that he has was with an author by the name of James Clear who wrote Atomic Habits. This is a book that came out a couple of years ago, like, in 2018, I think. 2017?
\n\nIn it, he talks about how to basically make habits that help you and break habits that hinder you. He doesn't necessarily talk about the exact habits that people want to do other than kind of, like, the obvious ones. But it was kind of an interesting conversation around how we make habits and how those habits help define who we are. And then, he goes into, like, how we define ourselves or how we want to define ourselves, how important that is in our lives if we want to lead a fulfilling life.
\n\nAnd he goes in and talks about if you want to be a better person, you have to define that better person. And then, you have to think about the things that that better person does. And by doing those things, you know, that makes a new definition of who you are. And so, a good example was like, a habit that you're trying to do is eat better. And so, rather than saying, "I'm on a diet. I'm trying to stop eating these certain foods," you say, "I'm a healthy person, and I'm going to eat healthy food." And there's kind of an interesting distinction there. But this is kind of a long-winded answer to, like, a developer podcast.
\n\nDAVID: No, it's good. We do that here.
\n\nJUSTIN: [laughs] But tying it back to this, I was thinking about, I want to be a better engineer. I want to be a great engineer. What are the things that I can do? What habits can I make that define me or that can define me as a great engineer? The question I want to bring to the group is like, what are the habits that people have that they've found help make them great engineers?
\n\nDAVID: That is fantastic. I had told you in the pre-call that I hadn't read Atomic Habits, that I had come at this from the other one. But James Clear he's the guy that played baseball, right? And he had, like, a career-ending injury in high school?
\n\nJUSTIN: Yeah.
\n\nDAVID: And then he picked every behavior performance, behavioral habit that was holding him back or that he needed to work on. And he ended up captaining the college baseball team?
\n\nJUSTIN: Yeah, basically, he kicked butt. He actually has a couple of laws in his book, the four laws that help define how to make a habit, and we can go into those a little later. I don't want to necessarily make the podcast about that, but we can go into that later.
\n\nDAVID: We certainly can, like, maybe, like, survey them a little bit. I have started Atomic Habits. I think I got to the part where he was talking about his bio, and I'm like, yeah, get to the meat. So yeah, so I came at this from reading The Power of Habit by Charles Duhigg and Tiny Habits by BJ Fogg. It's like an email list.
\n\nJUSTIN: [laughs]
\n\nDAVID: This will date me a little bit. This is, like, 2009 kind of thing. But do we want to take just a real quick minute and touch on these things? I don't want to spend, like, a thesis defense on all of these things. But if you want, I can have you throw out the four things that you're thinking of because I want to make sure we cover the topic the way you're looking at it. I don't want to just turn it into the Dave Brady show and say, "Oh, let's talk about dopamine, and motivation, and da da da," unless that's where you wanted to go with this.
\n\nJUSTIN: Those all come into it. So, why don't I talk about these four laws, and then we can kind of discuss those items? And then, we can go into, like, some specific software engineering habits.
\n\nDAVID: Fantastic.
\n\nJUSTIN: Law number one is make it obvious. So, make whatever you're trying to do make it very very obvious about what you're trying to do. He goes into different strategies for identifying and creating cues to make and break habits, so things that are very, very obvious.
\n\nEDDY: Can you elaborate on number one on what you mean by make it obvious? So, for example, if you're trying to achieve something, it should be easily explainable to someone. Is that sort of what you mean by obvious, or?
\n\nJUSTIN: Yeah. So, what I mean is, like, if you have a goal of reading books, of reading specific books, put them right in front of you. Put them on your nightstand. Put them on your pillow. Don't hide them. If you're reading them on your Kindle, you know, put them on your home screen, or something like that, or put goals. Put things that will remind you to do the thing.
\n\nAnother good example is if you want to eat fruit every day, put fruit around in front of you, hopefully, in front of the potato chips [laughs], such that you see the thing that you want to do. And another one, if we were to tie it back to programming, well, actually, let's wait, [laughs]. Let's wait on that. But first, law number one, make it obvious.
\n\nDAVID: My 10-second take on that is that I want to get better at guitar, and I have a couple of guitars. And I hung my guitar on the wall, and it is about four feet away, and it never gets played, which is why my other guitar is literally on the floor in arm's reach, where I literally don't have to even lean over to pick it up.
\n\nEDDY: I do want to say that maybe making it obvious, putting it in front of you, does attribute to using it, right? And this might be part of the other topics you want to talk about, like, with your points. But I have found that putting it in front of you, and giving you arm's reach, at least for me, it didn't really help. What really helped I was exposing myself with individuals who already did what I wanted to achieve.
\n\nDAVID: Ooh. Modeling behavior.
\n\nEDDY: So, for example, if I wanted to read more often, then I'd join a club with individuals who would read on a daily habit. That sort of motivates me to kind of follow the crowd. And it is not just applicable for reading books, like, in general, you know.
\n\nDAVID: I think that actually dovetails into...I'm not sure how Clear...Fogg does motivation and trigger are two of his things, and the motivation is that. I bet that's the make it attractive that you were about to say.
\n\nJUSTIN: Yeah, exactly. The make it attractive, however you do it, you need to make it something that you want to do. And you can incentivize yourself various ways into doing it. You can bundle it together within a reward. You can make it a habit, some sort of ritual that you do every day. You can put social incentives around it. So, do it with a buddy, or do it with a group.
\n\nThe other thing he mentions is, like, reframe your mindset, so rather than saying, "I have to do this every day," say, "I get to do this every day." And getting to do it is, you know, making it more attractive in your mind. So, those are the kind of examples on the attractive side.
\n\nEDDY: I'm curious if maybe I'm getting ahead of the topics here, but, like, how do you get over the hurdle of wanting to read when you don't have the motivation to read, right? Like, that's really the key, right?
\n\nJUSTIN: Yeah. So, all four of these laws are designed to help you get over that hurdle because they go into, like, the theory a little bit behind habits. Like, what makes a person get bad habits, and what makes a person get good habits? They brought up a lot about smoking because, obviously, smoking is not the best thing to do. But you have to recognize that smoking is a very in-the-moment reward. Like, you get that nicotine hit. You might get the habit of doing it. You get the social if you're, like, going out and smoking with somebody.
\n\nSo, there's a lot of immediate rewards to smoking that makes it easy to fall into that habit. If you think about it, the long-term consequences of smoking are really pretty bad. That's why these laws are designed to help you overcome the short-term attractiveness of bad habits and help you realize the long-term benefits of habits.
\n\nAnother example kind of going the other direction is exercising. When you start an exercise program, you know, for the first couple of weeks, you're, like, feeling like crap. You're like, oh, my body is not designed to move that way anymore, or you're always sleepy, or you have aches and pains that you never had. And so, all of those things prevent you, like, short-term prevents you from wanting to do that exercising. But the long-term things really help you out a lot. And so, these four laws help you do the long-term.
\n\nEDDY: I was actually going to interject a little bit here and say maybe I'm just wired differently than most people because I actually have the opposite effect when I start working out. I'm like, oh yeah, two-three weeks in, I'm like, I have good rhythm. I feel amazing. I'm super motivated, you know. And then comes the big fall of, like, I don't want to get out of bed. I hate getting up at 5:00 in the morning. I hate eating healthy, you know, and, like, just, I sort of, like, spiral then.
\n\nDAVID: There's a novelty effect that is especially exacerbated if you have ADHD, where doing something new is ten times more rewarding than doing what you've been doing.
\n\nEDDY: Exactly. Change of habits.
\n\nMIKE: There's something related to this. You mentioned smoking. I wanted to share, but I'd have to go look up the source. But there was some research done by a woman, and this is relevant because this was done in, like, the 60s. And her research was ignored because she was a woman until it was very clearly verified, and she was vindicated. And she was right, way ahead of her time. But I can't remember her name, so I'd have to go look it up.
\n\nShe did research about soldiers returning home from Vietnam, and a lot of them came back with a heroin addiction. And she was researching, and what she found was that soldiers who quit before they came back from Vietnam to the United States were usually able to stay clean, which is almost unheard of in addiction. Because if you're addicted, you're addicted. But the soldiers who got clean in Vietnam and then came to the United States were able to stay clean. But those soldiers who came back and used while in the United States were not able to stay clean.
\n\nDAVID: Oh wow.
\n\nMIKE: And this is, I think, really connected to this idea of habits because if you can change your environment...and, usually, we can't go from being a soldier in wartime to, you know, a civilian life, and that's such a dramatic life change that most of us can't pull that off. But there are things that we can often do to change our environment, to fundamentally reshape the way that we do things. Put the fruit in front, for example. And she found that that was critical, that something even as extreme as heroin addiction, which is, you know, known to be very problematic, could be overcome if you are able to change your environment.
\n\nSo, not just give up the bad habit but couple that with a lifestyle change, you know, dramatic. When I say lifestyle change, a life change, right? You know, going from one set of habits to another, and I think that some of these fundamental shifts really need that kind of change in mindset. You say, "Well, I'm going to do this different." And the way that you make it happen is by living that different life, and if that's the life that you're living, it becomes this new routine. You know, you've established a new identity almost.
\n\nJUSTIN: Absolutely.
\n\nDAVID: Those were the first two, Justin. What were the other two?
\n\nJUSTIN: So, law number three is make it easy. And this talks a little bit about the two-minute rule, and now we're getting to the parts that I haven't read yet [laughs]. But what I believe this is, is, like, make it so that you can start doing your new habit within two minutes, so whether that means having a gym in your home or whatever new habit you have is not, like, a whole bunch of prep work or friction that you have to work your way through before you can start doing the new thing.
\n\nDAVID: I had heard the two-minute rule expressed in another way, which was, it was part of, like, making it tiny and accessible. And I may have misunderstood this. The version of the two-minute rule that I had heard was make it something that you can commit to just do it for two minutes, and then you give yourself an out. And so, it's part of the, like, how do I make this less painful, right? It's like, nobody wants to get an exercise program. That's too big.
\n\nJUSTIN: Oh no, yeah.
\n\nDAVID: That's too much work.
\n\nJUSTIN: Yeah, I think you're right, actually. I think you're right.
\n\nDAVID: But, like, I can walk for two minutes and then turn around and come back. And then, I've just walked, and that's all I've done.
\n\nEDDY: You know, a really easy way to achieve that is to just get a dog [laughs].
\n\nDAVID: You'd think that, but I also have a wife.
\n\nEDDY: [laughs].
\n\nDAVID: And so, she's the responsible adult.
\n\nJUSTIN: Yeah, I think you're right as well. Now that I looked a little farther into it, I was like, oh yeah, you're right. So yeah, doing it within two minutes. It mentions that it, like, overcomes procrastination and laziness that you could do it within that time period. I kind of question about that. But like I said, I haven't gotten that far in the book yet, so...
\n\nEDDY: I guess I have a question. Is [inaudible 13:53] the moment that it crosses your mind that you should do it or the moment that you established when you want to do it and do it within those two minutes? Because I'll go on record in saying that I have a really short attention span. So, I can have, like, a really good idea and be like, oh yeah, I should really go get some food [laughs]. If I don't do it exactly within, like, seconds that I think about it, I won't do it.
\n\nJUSTIN: So, in here, I just saw another example. It talks about a famous writer called Anthony Trollope, who I've never heard of before, but he published quite a bit. Instead of measuring his progress based on the completion of chapters of books, Trollope measured his progress in 15-minute increments. He set a goal of 250 words every 15 minutes. And he continued that pattern for three hours each day. So, it was, you know, rather than writing a chapter a day or something like that, he shrunk his goal from writing 3 hours a day to writing 250 words in 15 minutes. And that very measurable small goal allowed him to feel a sense of accomplishment every 15 minutes. And it helped move him throughout the day.
\n\nEDDY: That's interesting, right? Because I want to say anytime I've always wanted to read a book, I felt awkward leaving it in the middle of the chapter. Instinctively, we want to get to the end of the chapter, so it's, like, a really neat way the way the author intended.
\n\nI do want to add something, though. My wife and I tried something different the other day. It's kind of interesting. We'll, instead of finishing a whole episode, we'll watch half the episode and then stop, pick up on that half episode, and leech over to the next episode, and that way, you know, you're stopping abruptly halfway in the episode every day. And then, it doesn't leave you with the sensation of, ah, what happens next? You know --
\n\nDAVID: Cliffhanger.
\n\nEDDY: So, it's easier to stop, right?
\n\nDAVID: Wow. That is the most psychopathic thing I think I've ever heard you say, stopping in the middle [laughter]. That's amazing. That's amazing.
\n\nEDDY: But it works, right?
\n\nDAVID: Yeah, yeah, no, it's, yeah.
\n\nEDDY: Because instinctively, what we want to do is finish. Like, I think we just want to finish whatever we started, and leaving it like that or leaving things unfinished is kind of uncomfortable. But you get over the habit of binge-watching, you know, and you're able to control your habits much easier because it's much easier to tune off, you know, when it's something boring.
\n\nDAVID: Related to the two-minute rule, BJ Fogg's Tiny Habits, he dials that up to 11. When he says tiny, he's like, think two-second rule. For him, the definition of a good habit is I want to get better at guitar. When I walk into my office and I see my guitar, I'm going to pick it up, and I'm going to play one note. That is literally the thing that you write up. This is what I will commit to do.
\n\nAnd now it's so small that as a commitment, it's like, oh, I don't have to grapple with my fear of failure as a musician. I just have to play the one note, and whether the note sounds good or bad, I can do it. You can just take things smaller. And this is like what you're saying, Eddy, where, like, sometimes it gets too big and too painful. One way to move the teeter-totter is to just make it smaller and smaller and smaller and smaller without grinding too much into it.
\n\nBut there's a bunch of stuff that I was reading up on dopamine, and it talks about, like, the writing 250 words in 15 minutes. I've had times where it's been I'm going to intentionally focus, and I'm going to write one sentence. And then, I'm going to step back, and I'm going to look at the sentence I wrote and go, "Yes, I wrote a sentence." And then, I'm going to step in and say, "I'm going to write one sentence," and it's this winch.
\n\nAnd you look at it, and you think that's not going to be satisfying. One sentence doesn't mean anything. And that's how you poison yourself. That's how you talk yourself into this; oh, it's my whole writing career that's at stake because I've discounted that. Because guess what? That whole writing career is based on one sentence, and then another sentence, and then another sentence.
\n\nEDDY: You know, early, early, early on in my career when I wanted to penetrate the industry, I read something, or someone told me, I don't remember, but it resonated with me forever. And they basically said, "Starve yourself from dopening." Let me elaborate a little bit on that. And you probably have heard this. But instinctively, what we want to do is we want to reach out to a phone, you know, and browse, whatever, play a game, read something, go through the social media, whatever, you know, and, like, you're inducing your brain with dopamine. You're rewarding it, essentially.
\n\nDAVID: Rewarding yourself for doing nothing.
\n\nEDDY: For nothing, exactly. And there is a limit to how much your brain, and I'm paraphrasing here, obviously, but there's a limit to how much dopamine your brain gets. And if you starve yourself for those rewards and instead go cold turkey and just don't do it, you'll prioritize the things that you want to achieve first. And then, you reward yourself, you know, with getting on your phone, as an example. And it's just an easier way to kind of manipulate your habits.
\n\nDAVID: Yeah. The small slicing on the dopamine, the trick that you're trying to get into, is to trick yourself into—you write the sentence. And this is going to sound stupid, but I've literally done this this month—where I hate exercising. I'm just not built for it. And I was walking down the street, and I literally looked at my neighbor's tree, and I said, "I'm going to walk that far on the sidewalk." And as soon as I got there, I'm like, okay, yay, I did it. Good. Next tree, literally 15 feet. I'm going to walk to that one.
\n\nIt's tiny, and it's stupid, but you're conditioning yourself to get that little, tiny hit of dopamine from chasing the task rather than completing the task. You want to move. If you focus on getting the reward, you'll actually drive yourself into a negative cycle, where it'll actually taper out. And if you focus on the pursuit of the task, you drive it into where all of a sudden, it's the chasing that gets after it that you enjoy. You don't enjoy winning the marathon. You enjoy grinding through, you know, pounding through mile 17, like I know anything about this. I'm literally talking a minute ago about walking from one tree to the next.
\n\nJUSTIN: [laughs].
\n\nDAVID: You know, but finishing the program is less exciting to me than it is to just bashing out one more module, one more function, one more refactoring. It's very satisfying to me. Okay, Justin, bring us home. What was the fourth one?
\n\nJUSTIN: The fourth one is make it satisfying, and by that, he has a couple of examples of using reinforcement rewards. So, once you've completed your habit, have, you know, some sort of reward.
\n\nNext one is habit tracking, you know, writing down in your journal or, you know, recording your exercise by a Fitbit or some other exercise tracker.
\n\nNumber three is accountability partnerships, so doing your reward and working with somebody and letting them know that you did it. And it gives you a sense of accountability that you are working with somebody to accomplish something together.
\n\nAnd then, finally, gamify the process, which is, you know, doing some sort of competition that incentivizes you to complete, you know, the new habit that you're trying to do.
\n\nEDDY: Justin, I can't stress enough the tracking part of it. I'm sure all of you have heard, to a degree, P90X. One of the quotes that's said in one of those episodes is track, track, track. And, like, the way he kind of related to that is, if you don't track your progress on what you're doing, then how do you know you're getting better? Write it in a notebook. Write it in a whiteboard. It doesn't matter.
\n\nBecause let's say, for example, your first week, you can only do one push-up. So, you go on the whiteboard, and you go, cool, this week, one push-up, right? The following week, you can look at that, and you're like, cool, I started with only being able to do one push-up. Now I did two, right? So, now you're able to contrast, and you're able to see easily the progress, your achievement. And so, being able to track your progress really helps to keep motivated, and I can't stress that enough.
\n\nThere are times where we want to achieve something and, like, we feel unmotivated because we don't realize how far we've actually come because we're too busy looking at the actual ambition, you know, that we wanted to achieve, but we're completely lacking all the steps that we took already.
\n\nDAVID: Tracking is key. I had a boss years and years ago who said...he was like six foot six, and he loved playing basketball, and I was not a very competitive person; I'm still not. But he was trying to explain to me the notion of competition, and he basically said, "If you're not keeping score, why play?" He didn't want to see other people lose, but he wanted to rack up the highest score possible. And he loved it when he had somebody who forced him to score well in order to play. So, it was a very positive style of competition, but he was very enthusiastically competitive about a lot of things.
\n\nDovetailing on that, Goodhart's Law, I think, is what it's called, which is when a metric becomes a goal, it ceases to be a good metric. But the reverse of this is when you gamify something, some things we try to reach an objective, and the goal is to get the objective and win and finish. And other times the objective is to keep the game going, keep it playing, keep it moving for as far as you can. And when you gamify something, you're kind of weaponizing the opposite of Goodhart's Law. You're basically saying, "Oh, I got two points. I got three points. I did this."
\n\nCircling around to Justin, because we spent half our time talking about what this is, and I feel like it's important.
\n\nJUSTIN: [laughs].
\n\nDAVID: But, like, segueing into, like, engineering habits, like, we have, you know, multiple websites that keep track of how many pull requests we've opened, and how many reviews we've done, and how many lines of code we've turned in. All of these we know they are bunk metrics for code quality and how good your project is and all that stuff. But as a scoreboard for gamifying something, it's very satisfying.
\n\nJUSTIN: [laughs]
\n\nDAVID: And that keeps you playing the game, and that makes you get better. And that indirectly causes the code quality to go up and the satisfaction to go up. Very, very interesting.
\n\nEDDY: I don't think that kind of works for me, though, Dave. I'm not competitive by nature --
\n\nDAVID: Neither am I.
\n\nEDDY: I'm okay with losing, and I'm comfortable with it.
\n\nDAVID: Yes.
\n\nEDDY: But some people utterly are distraught by the idea of, like, I cannot lose, and if I lose, I hate myself [laughs].
\n\nDAVID: Yeah. Yeah. And I am not that at all. But I am not immune to the pleasure of seeing the line go up when I measure something.
\n\nJUSTIN: I think it's interesting how you don't have this one-size-fits-all solution. I think the emphasis here is do what works for you. If gamify works for you, gamify it. If, you know, small rewards work for you...we're trying to follow these four laws, but at the same time, there's lots of ways that we can accomplish them.
\n\nDAVID: There's developers that I've worked with who you can set your watch to them. They show up at 8:00 o'clock. They pound out a thousand lines of code. They go home at 5:00, day in day out. And they're just machines. And that is not me. I am very much not somebody to mark time on a clock. And I felt really bad about it until somebody pointed out. They were like, "Dude, when you see a rabbit run across the field, you are off like a shot, and we don't see you for three days."
\n\nJUSTIN: [laughs].
\n\nDAVID: And I'm like, yeah, I will tear off after that field, and my wife will be like, "I guess I'll see you Tuesday." And then, Tuesday, she's like, "Will I see you Tuesday?" I need more fingers than the fingers of one hand to count the number of places I have worked at where I took a sleeping bag to work because I was in the habit of sleeping under my desk to do, like, a 36-hour rotation multiple times. That's my privilege and the way my family grew up. I had that time and a wife that was willing to support that and no kids at home. But it was an opportunity to do some very, very hard work, and I did it, and that was me chasing after rabbits.
\n\nSo, if there's blood in the water, I go full shark mode. I try to bait the hook with something bloody and fresh and like, ooh, let's go do this thing. And I try to be compassionate with myself when 8:00 o'clock rolls around in the morning, and I'm like, I can't. I can't. It's just, ah, you know. I try to get the steadiness back in. And meanwhile, I lean on the guy on the team who, at 5:01, he's not around to answer the phone because he did what works for him, right? He marked his time. You need both kinds of people. You need dragon slayers, and you need bear skinners.
\n\nThere is something that you touched on, Justin, and it circles back on the dopamine thing. Charles Duhigg wrote The Power of Habit. There's two books by that name, by the way, so Charles Duhigg is the one that I really liked. They were studying housewives. They put cameras in the bedroom to film them cleaning the room. And there were some wives who...this study was from the 60s, so it's necessarily very sexist.
\n\nJUSTIN: [laughs].
\n\nDAVID: But there were these housewives who kept an immaculately spotless bedroom, and there were housewives who struggled. And they asked them to just go in and clean, and make the bed, and da da da da. And one of the researchers, he's like...I want to give this guy just the biggest hug in the world because one of the researchers noticed a very subtle thing. It was like, if you blink, you miss it, but once you see it, you can't unsee it.
\n\nThe wives who were very, very organized they would come in. They would make the bed, and after they make the bed, they would step back and they would just look at it for just a second. And then they would walk out. What they're doing is they're charging up the dopamine. They're basically doing the I did a thing. I made a clean spot. Go me. This is awesome. This is what I want. That's part of, like, the make it satisfying. So, jumping finally into engineering habits.
\n\nJUSTIN: [laughs].
\n\nDAVID: I don't know if this is [inaudible 27:24] be a graphic. I'll throw one out, and then I'll ask you guys what yours are. But I have a hook that when I want to push up a pull request, literally, there's a script called git cram, and it crams the PR into the server and tracks it and says, "I want to open a PR on this." And the last thing that git cram does is it puts a message in pretty colored font that says, "Did you run RuboCop?"
\n\nJUSTIN: [laughs].
\n\nDAVID: I always forget to run RuboCop. And I hate RuboCop because it's very much of, you know, organized. We're going to do this organization, whether it makes the code readable or not. I don't know if I can ever be friends with B Batsov. That's the guy who maintains RuboCop. But when I see that sign, I crack open RuboCop, and I just look for the stuff that's low-hanging fruit, and I just do one or two. Maybe I do the dash a and do all the low-hanging fruit.
\n\nThen I step back and go, oh, that is actually nicer. I do like this. I made a clean spot. And I might stop there. Half the time, I stop there and say, "You know what? The rest of this is legacy code, and changing that's really tricky." And I don't want to fight that dragon right now." But other times, I'm like, "Ooh, I'm on a roll. I'm going to finish this." And then, you get to that magical time when you run RuboCop, and you get a green dot.
\n\nI don't know if the code is truly more readable, but I've got a, and, again, that's, like, the Goodhart's Law. As a metric, it doesn't mean the code is perfect, but I do have something that I've gamified. And I've got a green dot on the board, and that makes me very, very happy.
\n\nJUSTIN: And I think it's interesting because you mentioned the green dot, and I don't think that's a mistake at all that green dots are all over the place where it says that you are doing something good. You got green dots when your unit tests pass. You got green dots when you push something that is all clean and everything. And so, that green is just like, hey, I just did something, and it feeds a little jolt of dopamine that you're happy, and that makes you happy.
\n\nDAVID: Yeah. There was a phrase going around in the noughties: test infected. And people in the Agile community, especially, were banding this, "Oh, I'm test-infected. I want to write tests. I want to do unit testing." And the hallmark of this is you get addicted to the green bar.
\n\nJUSTIN: [laughs].
\n\nDAVID: And it's real. I have, like, physically felt uncomfortable because I had not seen a green bar in a long time. People who have paired with me know that I have colored lights, a light strip over on the wall. And when I run my specs, they turn blue, and when it finishes, that whole light strip on the wall over my desk turns red or green.
\n\nJUSTIN: Wow.
\n\nDAVID: And it is very, very satisfying. People that I work with they don't pay attention to that. They don't track it and do the, "Ooh, that's good," or "Oh, that's bad." You get blind to it. You don't focus on what the output of your specs are. And so, you don't notice you've got pending specs, and you've got warnings, and you've got errors. You just ignore them. You're like, yeah, whatever, specs, whatever. And I'm over here going, that turns the spec output yellow! Yellow is not green! It's...no! Don't do that!
\n\nJUSTIN: [laughs].
\n\nDAVID: I feel bad! You know, and everyone's like, "Dave, calm down. What are you freaking out about?" I'm like, "I need my green specs! I need green dots."
\n\nJUSTIN: All the methodologies that are out there to help us be more productive and things like that, how much that feeds back into these habit-forming things. We talked about the habits of breaking the thing that we want to do down into smaller and smaller parts. That kind of rolls right into breaking our stories down into more manageable stories where we can get that shot of dopamine that we completed a thing within a day or something like that, rather than trying to work on this new feature that's one story for a week or two weeks, or something like that. Having that tighter cycle benefits us in so many ways. And it kind of rolls right into this habit-forming that we have talked about.
\n\nDAVID: Absolutely. Absolutely. There are a whole bunch of habits that I have that somehow got filed into the banks of my brain as Engineering Discipline: Capital E, capital D. And it was before I knew what habits were. It was just like, if I'm a good engineer, I have to do these things. If there is a holy first commandment of engineering discipline is, do not commit code that you have not run the tests on. And it is very rare, not impossible, that it happens. It's very rare that when I push a pull request up to GitHub, Jenkins pulls it down and runs it. It's very rare that CI fails on me.
\n\nAnd when it does fail, half the time, it's because of a flaky test or something in the system broke rather than what I did, and it's because I'm religious about it. And when I find myself in a spot where I can't run my tests the way I want, or I'm working on something that I can't lock down, and I get the computer to tell me, "Yes, this does what we think it does," first of all, I get very, very anxious. And secondly, my compromise, my fallback engineering discipline is I commit myself to chiseling away at whatever is stopping me from being able to run my tests.
\n\nSo, on the team that I'm on, if you run any test suite with database-seeded data, it takes 90 seconds to start up the test, and if you've got ADHD, that's awful. I'm in the kitchen making a sandwich. I'm talking to Liz. I'm at the grocery store picking up a soda pop. And, like, wait a minute, how did I literally end up across town? I'm supposed to be running my test.
\n\nJUSTIN: [laughs].
\n\nDAVID: So, I figured out how to chisel away the tests so that they don't depend on the seeds. And I will run my tests without the seed thing on. And I was pairing with a programmer earlier this week who shall remain nameless to protect me from the innocent. They did bin/rspec.
\n\nAnd he leaned back and he said, "Now we wait for a minute and a half." And I'm like, "Do you have spec seed turned on in your bash profile?" And he said, "Yep." And I said, "You don't run your tests unless you have to. And you run them at the very end, and you run big, long steps before you..." And he's like, "How do you know all this?" And I'm like, "Because your tests hurt you. And it's like, do they have to hurt this much?" So, that might be an engineering habit of if something hurts, try to fix it. If you can't fix it, chip at it. Just knock a piece of it.
\n\nPower of Habit from Duhigg was recommended to me by Amy Hoy, and she did an online entrepreneurial class called 30x500 that I took and I really, really enjoyed. And one of the concepts she talks about is she calls it the winch. And the idea is you can succeed with just an inch of progress if you can make an inch and not lose it—if you can winch yourself forward just a little teeny tiny bit.
\n\nSo, that makes you want to step back and say, if I work on this, am I slapping at it, and then I turn away, and it just comes back and goes back to rest? Because if that's the problem, I've got to pick it up. I've got to carry it across the lawn and set it down, or I can't make any progress because it's going to blow back and forth.
\n\nBut if I can find something and lock it down, like git cram, for example, that little thing, that is an actual script on my computer in my path. And it just does git push and git set origin and track and then, you know, display the message. And when I first did it, all it did was push and do a track. There wasn't anything else to it, and it just kind of winched forward from there. I have a bin repo up on GitHub that's just all my public stuff that I put on all my machines. There's, like, 200 scripts in there now that I've built over 15 years.
\n\nJUSTIN: [laughs].
\n\nDAVID: I'm really proud of Git RuboCop because I type Git space Rubocop, and it runs RuboCop on the files that have changed since I last diverged from master, which, okay, that's not that hard to do. That's just RuboCop and a list of files—getting that list of files. I wrote another script called Git files changed that will tell you what changed, little, tiny thing. It makes the job easier, and then you come back to it.
\n\nYou do have to be careful not to spend 40 hours gaining that one inch on something that your product owner doesn't need because that can cost you your job, and eventually, it will cost you your career. You have to learn how do I take five minutes on this and gain two hours down the road? There's an old xkcd comic about how long it takes you to do something versus how much time it saves you, versus how many times a day or week that you run this thing. It's just a chart, and it tells you this is how long before it will pay off.
\n\nAnd at the end of the chart, it's like, this is going to take ten years to pay off because you run this once a year, and you spent 40 hours saving 2 minutes on it. You spent 2 hours on it, but you run it 30 times a day, and you only save 2 seconds, but that's going to pay off in, like, three weeks. And you're like, hmm, interesting. What are some things that you guys do that's down at the habit level that you don't have to think about; you don't have to summon this force of energy to tackle? You're just like, oh yeah, I got to do the thing.
\n\nMIKE: One thing that's been on my mind as we've been talking about this, you know, there's all these little tricks we can do, and there's some utility to them. And sometimes, maybe you're not going to feel like it [laughs]. There's maybe two related things that I'm thinking of connected to this. So, I'm going to follow this thread first. I ran cross country in high school. For everybody's who's done that, it just hurts.
\n\nJUSTIN: [laughs].
\n\nMIKE: I'm just going to [inaudible 36:11]. And, actually, I had somebody tell me, a fellow cross country team member, that long-distance running is mostly about pain management. You know, the people who are really good at it get really good at tolerating pain and, you know, learning to kind of segment that off in their brain. And I thought, oh, that's interesting. I don't know how I feel about that [laughter]. I'm not vouching for the truth of that. It's actually not quite my point. My point is that if you think about what's happening to you physically, it's not necessarily fun. There are some, you know, endorphins that come from it that are nice.
\n\nBut I loved it, not because I necessarily loved the pain that I was going through [chuckles]. And I wasn't particularly good either, by the way. I started the team late. I remember my first race I got last place [laughter]. Don't think of me as a great runner. I got better, but, you know, never great, but I just loved running around outside. I got to run around outside. The sense of capturing the beauty and awe of the world around me still sticks with me. I loved doing that.
\n\nI noticed that Justin's profile image looked like he was hiking somewhere [laughter]. You know, hiking is not necessarily different. You go up there because you want to experience that beauty, you know, have some awe, some sense of being in something bigger than yourself. And it's related to the idea of a flow state. You know, people tend to become really successful when they are not immediately aware of what they're doing, but instead, they feel, like, one with the work.
\n\nAnd similar to the hiking, to the running, doing something deliberately to be meditative, and developing that sense of meditative immersion, you might think, well, I can't develop that. But I think we can. It's something that you practice. It's like other things that you can work on. You don't necessarily go into the day looking for that hit of dopamine, or endorphins, or whatever it is. Instead, if you go in just as kind of an open slate, like, what am I going to experience [laughs]? It kind of washes over you. Rather than value judgments to your experience, instead, treat that experience as an adventure.
\n\nAnd that subtle mindset shift it takes some work. It doesn't just happen, but it can change the way that you approach your work. That is one habit, I think, that has benefited me a lot is developing that kind of mindset that I can be there. I can have...the world is on fire [laughs]. Things are broken [laughs]. This is...I want to be cautious here. I'm not saying that we should be in an abusive or in a deliberately bad situation.
\n\nHowever, developing the ability to consciously put yourself in that situation and say, "Well, you know, this does matter to me. I want to provide for myself and my family. This is something I want to be doing." Then you can make a conscious choice to put yourself in that situation and go through all of the fiery arrows coming at you and find it fascinating, you know, and see it as, like I say, an adventure.
\n\nAnd that particular approach works for me far better than being competitive. I don't really care if I win, but that sense of adventure, that sense of awe at the world around me is satisfying or is motivating in a way that nothing else can be. When everything else is bad, which sometimes it will be, if I can do it anyway because I've chosen to have this experience, it changes my mindset. And that's something that has, I think, helped me a lot.
\n\nAnd a minor point, honestly: getting exercise when I can helps me to be a developer. It just helps your mind work better. All the tricks we talked about help with exercise. You know, help [inaudible 39:38] with somebody, go out with my kids, helps a lot. But even more so, developing that different mindset about the work, I think, is a big deal.
\n\nDAVID: There's a thing that resonates so strong with me with what you just said. I can't remember where I heard it. I want to say it might have been Jordan Peterson. The comment that they made was bearing your cross is only bearable if it's meaningful. Otherwise, it's just a hell that you have to go through. The world's on fire, and people are upset, and there's money being lost, and people are screaming, and dah, dah, dah, dah, dah. And you're just in there going, "I'm providing for my family." I don't know if I said this on the podcast. I know I've said this to you before, Mike, that sometimes the good money is to be found by shoveling crap out of a latrine.
\n\nJUSTIN: [laughs].
\n\nDAVID: And I have reached a point in my career where I can get down in that stinky, smelly, awful, terrible, and I don't think too much about what I'm up to my hips in. I just start shoveling because I know I'm making a clean spot. I'm making a clean hole that we can get some work done and get some, you know, some stuff done. So, yeah, you're not down there going, "Oh, yay. Look at all this smelly poop on my shovel." No, it's, I'm making a clean spot. Every bit I lift is one tiny, little bit of poo out of this hole. That's what we go after.
\n\nThe competition thing, like I said, I'm not competitive against other humans. Like, I can't stand to see other people be sad or be frustrated. But, for me, watching the number go up, like, the gamifying, so I will compete with myself. And so, I think it's important to find what is it that makes you tick?
\n\nI've worked with you, Mike, enough to know that you have, like, a very meditative presence to things. And I can picture you just standing in the garden watching the azaleas and thinking, I need to prune the grapes back. I hate being outdoors. I hate plants. I'm allergic to anything if it's got chlorophyll in it. And I was like, what an awful way to do it. And I can see you in that environment going, the sun is shining. There's a beautiful breeze. There's a ton of work to do. And that's not what I'm here about. I'm here about this moment, this meditative moment that I can be present in. So, we've gone around the horn quite a bit. Are there any other tricks and hacks?
\n\nJUSTIN: I mean, we spent a lot of time kind of defining what makes a good habit or how to have a good habit. I almost, like, want to have a part two of this podcast that, like, goes more into the good habits.
\n\nDAVID: I'm realizing, like, one of the...I talked about my bin folder, and I thought, well, that's stupid. It's so small that nobody will care about it and value it, and I realized I've got a thousand of these little things. I have alarms on my phone. I have an alarm on my phone that tells me to check my alarms. I'm not kidding when I say that.
\n\nJUSTIN: [laughs]
\n\nDAVID: And what it is, like, I have time blindness. I can sit down at the computer. There's Slack, and there's email. There's a problem; there's a bug, da da da da da. [inaudible 42:20] is going off. And all of a sudden, it's 1:30 in the afternoon, and I haven't checked email, and there's a hot message on Slack that somebody's been trying to get a hold...right? So, I've got a checklist. It's like a pilot's checklist for flying a plane of: check this, sign in. You know, we have four different single sign-in thing, which is, you know, increasingly erroneously named single. We have four SO, I guess.
\n\nSign into all four systems, then, you know, go do this. And that means you have to hit this one system that you don't normally do, which, oh, yes, I need to log in there. I need to check to see if I've got any trainings outstanding in our online training stuff. And it's on a checklist. The training thing is a good example. If I don't have an alarm on my clock to remind me to check, the only way I get my trainings done is when I literally start getting emails from the legal department saying, "We're about to be out of compliance because not all our people are trained," and you are that people.
\n\nJUSTIN: [laughs].
\n\nDAVID: Oh, okay yeah. So yeah, I probably got a dozen of these that I realize are now probably too small. On the larger side of things, there's a couple of people that I've talked to in the past like Dan [SP] Cub is somebody who comes to mind. He's kind of a minor luminary, moderate luminary, not minor. He's moderately famous in the Ruby community.
\n\nHe mindfully and intentfully writes experiments, you know, hypothesis. I'm going to try this, and I'm going to document and capture. And he will have, like, five code experiments running every week, and I've stolen that from him. And so, like, this week, I'm trying a thing where I write a test that's useful to me, and then I delete it. And I push it up.
\n\nAnd I just got feedback from a co-worker going, "Where are the tests?" And I'm like, "Yeah, they weren't any good." Maybe I should write some good ones. But it's an experiment, right? Try and...and the habit is try and experiment. Justin, I think you're right. I think a follow-up on this would be really, really good. I feel like we're getting to a good close for this one. Any final thoughts out the door?
\n\nEDDY: I will say the thing that attributes to success, at least for me, was getting compensated for it. Like, that made loads of difference [laughter]. Circling back to development, right? Like, you can tell someone, "Yeah, if you have the discipline, you can teach yourself." But what they don't really understand is it's a full-time gig, you know, doing that without any sort of compensation. And so, you're doing two full-time jobs or a full-time job and a part-time job. And it's really hard to continue to keep stabbing and stabbing and stabbing when you're not getting paid for it, right?
\n\nDAVID: Yeah.
\n\nEDDY: So, I will go on record to say if someone, you know, was trying to get good habits to penetrate the career, you know, and, like, establish some sort of status in development, getting into something, you know, that's remotely close to what you're trying to do really, really, really, really, really aids, you know, in success.
\n\nDAVID: There's a whole thing we could dive into about career-adjacent activities, where you can expose yourself to an environment where somebody taps you on the shoulder and say, "Hey, do you want to come play with us?" And it's just blind luck. It's not blind luck. You sat down in the lunchroom next to the people doing the thing that you wanted to do.
\n\nEDDY: Exactly. And, like, that can be applied to anything in life. Like, you want to get really good at basketball. You want to join the NBA. You know, you have to be comfortable doing that for hours and hours, for months and months without getting paid. Same thing, like; I feel like the surge of YouTube is a huge example. Like, if you're a YouTuber and you're like, "Oh yeah, I want to monopolize, and I want to make money." [laughs] But what they don't understand, you know, is that people who found success in that platform did it and grinded for years.
\n\nDAVID: For two years before they broke a thousand viewers, yeah.
\n\nEDDY: Exactly.
\n\nDAVID: Chris Williamson and Evan and Katelyn are two people that are really, really big that I like watching right now. And both of them talked about: we did this for years and no payoff. And it's interesting that they said they didn't do it investing in their future. They did it because they're like, this is the grind. We're going to get on this. This is going to be the grind that we're going to be on, and we're going to do this. And they focused on just do the grind.
\n\nDon't focus on the reward because the reward is going to hit, and it's going to be pale. You're going to be like, I did all that for this? No, you did all that in order to spend two years of your life on a thing that you can now look back and say, "I'm two years older, and I have all these things behind me." Cultivate that itch to learn something, and that'll keep you up at night reading programming books.
\n\nEDDY: [inaudible 46:43] compensation, like I'm saying. I can't stress enough how much value that helps [laughs] that provides, you know, the success.
\n\nDAVID: I'll throw this out as my closing thought on it, regarding compensation. I've always had an itch to learn. My wife was very frustrated. We were not making much money, and I was buying very expensive books, like, $100, $150-books in 1990 money, so, like, $50 books back then was a lot of money. And my wife just shook her head. She's like, "I would be mad, except that you read them, and so I can't complain."
\n\nJUSTIN: [laughs]
\n\nDAVID: And I got into Perl programming, like, in 1999 or so. And in 2002, my Perl number was, like, three, I think? I'd never met Larry Wall, and I had never been asked to maintain the Perl tarball. Like, nobody knew who I was, but if you had a Perl question, I knew the answer.
\n\nAnd I had a co-worker that came over to me, and he says, "Hey, how do you get the length of an array in Perl?" And I'm like, "Oh, it's..." and I gave him the line noise string of like, you know, pounds, dollars, you know, whatever it is to do that in Perl. "And hey, how do you do a file X?" "Oh, it's this." "Hey, how do I check for a range of things in Perl?" "Oh, it's this operator." "Well, how..."
\n\nAnd about the 10th time he asked me a question, I'm literally writing code, and I don't even...I'm just like, "Oh, it's this," and I keep typing. And I wasn't aware that I was doing it until he stopped and he goes, "Do you just know everything about Perl?" And I'm like, "What? What?" I have been glowing and coasting on that compliment for 20 years [laughter]. That happened in 2000, 23 years. That happened in Y2K, and I'm still happy. I was so startled. I'm like, oh my gosh, I'm not any smarter. You just asked questions that I knew the answers to, which turned out to be all of them.
\n\nEDDY: I do want to say, though, that the outcome could have been not drastically different but, like, you could have had a different outcome had you been given those books to you versus you having skin in the game and investing hundreds of dollars, right?
\n\nDAVID: Yeah. For me, that is the key difference between being invested in the payoff, in the reward, versus being about the grind. It's like, I'm going to do this. I'm going to put this effort in. You say compensation, and I'm 100% on board for compensation in the sense of I'm going to get myself on a payroll because then it's part of the grind. It's like early salary negotiations for me where it's like, well, I can tell that this number is bigger than that number, and I like the line to go up. That is a motivating thing.
\n\nEDDY: I typically when someone...because I've had people who have said, "Hey, well, how do you attribute your success?" And I say, quote, unquote, "Success," because, like, that's very subjective. But, like, there's people who do aspire, like, doing something that Ramsey and I have done, where we have been able to penetrate something without prior experience. And typically, my go-to advice has always been grind, discipline, and spending money on resources. And they're like, "Oh, I don't know if I want to spend money on it." Like, if you spend money on something, suddenly, you're invested [laughs].
\n\nDAVID: And I would call that investment. I had a co-worker years ago who had 13 children. And we were talking about something, and I had stayed up all night reading about it. And I'm like, "You're not reading about this in the office. How do you have time to have read about this?" And he's like, "I get up at 4:00 o'clock in the morning, and I have about an hour where it's quiet." And so, I'm like, "Okay, so you're a lot more focused because you've only got an hour before all hell breaks loose and pandemonium breaks loose in your house." And he's like, "Yeah, so I use that hour very intentionally."
\n\nAnd we were comparing notes and I'm like, "Yeah, you're getting about three times the efficiency because you're investing a resource that, for you, is so much more scarce." It'd be like, you and I go into the bookstore, and I buy a book for $50, and you buy the same book. But you have to pay $750 for it.
\n\nEDDY: Huge.
\n\nDAVID: One of us is going to read that book cover to cover and then eat the cover.
\n\nEDDY: [laughs]
\n\nDAVID: Ah, this was a good talk. I do want to carry this on again. Everyone listening, thank you for coming. This was awesome. I'm looking forward to talking about this again.
\n\nEDDY: Let's do a part two.
","summary":"","date_published":"2024-03-27T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/8474100f-d236-4cb2-a387-adc8f17c2897.mp3","mime_type":"audio/mpeg","size_in_bytes":32297866,"duration_in_seconds":3053}]},{"id":"37f9ad43-2b8a-4fb8-b18b-ae25b5a4a159","title":"Episode 41: Code Reviews","url":"https://acima-development.fireside.fm/41","content_text":"In this episode of The Acima Development Podcast, host Mike Challis introduces a discussion on code reviews by drawing an analogy between creating music and coding while sharing personal stories about feedback in musical endeavors to illustrate the importance of constructive criticism. These anecdotes highlight the parallels between receiving feedback on creative projects, like music, and technical work, such as code, emphasizing how both require openness to feedback for improvement.\n\nThe conversation then goes into the specifics of code reviews, highlighting their value in the software development process and how code reviews are akin to collaborations in music, where input from multiple contributors often leads to a superior output. The panelists explore the nuances of effective code reviews, including the balance between too many and too few contributors, the importance of automation in enforcing style guidelines, and the value of comments within the review process to provide context and facilitate understanding.\n\nThe episode concludes with a deep dive into the best practices for conducting code reviews, addressing the challenges of pushback, the significance of understanding the reviewer's perspective, and strategies for ensuring constructive and efficient feedback. The conversation also touches on the importance of security considerations during the review process and the potential pitfalls of approving changes prematurely.\n\nTranscript:\n\nMIKE: Hello, and welcome to another episode of the Acima Development podcast. I'm Mike, and I'll be hosting today. Here we have with us Eddy, Justin, and Kyle who've been with us before. And we are going to be talking about code reviews. I like to start with a story, and I'm going to do that. \n\nSometime recently, we talked about music and about how there's often overlap between people who make music and people who write code. I'm going to build on that a little bit. I like to write music. I sometimes just write music for fun. I do stuff my kids like [laughs]. Their favorite song is something I did; it was just kind of a personal challenge. You know the video game Plants vs. Zombies? \n\nJUSTIN: Mm-hmm.\n\nMIKE: I [laughs] listened to the soundtrack of that, and I thought, if I were to write the soundtrack, what would I do? And I wrote a song that kind of captured my take on it. And my kids love it. That's the one they ask me to play most [laughter]. So, I feel pretty good about that. They are honest judges. And, you know, they do, you know, they give me commentary on it. And sometimes there's a situation like that, and sometimes there's something a little bit more formal. \n\nA serious example: I had a friend who passed away a few years ago, and they asked me to do an arrangement for her funeral. And I got together with the woman who was going to be singing. I did an arrangement, and I brought it to the singer, and she gave me feedback. And she said, \"Well, you know, I think that there's too much build in the second verse, and I think we should move that to the third verse.\" And, honestly, she was right [laughs] in kind of every respect. She had the feedback that was necessary in order to improve that arrangement, you know, for something that we both cared about. That's really relevant, and that's not the only time that's happened. \n\nI've got some friends that got a high schooler who's in...he does a lot of singing and drama. He's involved in a lot of those things. And I've done something with him before, too. Once again, I gave it to the singer. He came back with feedback and said, \"Well, you know, I think we should change this. I think the melody is a little too repetitive. And I think if it went up here instead of down, that'd be better.\" And he was right. It made a genuine improvement to the structure of the music I put together. \n\nI think that this story is really instructive. It's a review of something creative that is not in code, but it has many of the same characteristics as what we do in code, sometimes anybody who creates something. There's an intro to a song by a musician, like, a soul singer. She says [chuckles], \"You know, remember, I'm an artist. I'm sensitive [laughs]. So, we feel that way, you know.\" Like, I'm an artist. I make this beautiful, perfect thing. And we think, well, you know, if anybody is giving me any feedback about this, they're criticizing my personal character and saying that I'm just not good enough. It's a really dangerous thing, both for ourselves and our art, I think, to start thinking that way. \n\nIt doesn't matter really how brilliant we think we are [laughs], and maybe we are. You know, maybe you have beautiful art that you create. Getting feedback on what you've created allows you to see it from a different perspective. We are all limited by the scope of what we can see with our own perspective. And seeing something from somebody else's perspective can help open up new views into something that may be wonderful. \n\nYou may have built something that's truly good. And when an eager collaborator is coming to work with you, they're not interested in tearing you down. They're interested in helping you make it better and in helping you achieve your vision. And they can say, \"You know, I think that you were trying to do this. I don't think you quite got there,\" and help you better accomplish your purpose that you had initially. That framing, for me, for reviews is extremely helpful.\n\nNow, we're going to be talking about code reviews, you know, that's perhaps more technical, maybe [laughs], than some of the stuff that comes from other creative endeavors, but it has many of the same characteristics. We're trying to solve a problem. And getting that second pair of eyes can help us solve the problem better in many cases. Also, the collaborator, in general, and if you're not doing this, you're doing it wrong [laughs], is trying to help you accomplish your purpose, not to tear you down, but to just help you do it better. And that second pair of eyes, that sounding board, is extremely helpful. So, that's the framing I wanted to start with. Does anybody have any thoughts about that? \n\nJUSTIN: It's interesting because you see a lot of people that do great work, like, artists or whatever, all by themselves. And then they get together with somebody, and they do a collaboration. And some of the best music comes out of collaborations. And it's like, a couple of my favorite songs have, like, a lead artist, and then they have some lesser-known artist that is coming in and doing a riff or something like that. But you can tell that they meshed together their ideas and just made something so much better. \n\nIf you think about music these days, it's not just, you know, people don't just, like, or most of the time, they don't just slam something down, and it's done. It is a work of months and months and months, and they're tweaking every little thing. If you get somebody else in on that, it makes that tweaking move much faster because you have somebody else that you're brainstorming with to solve the problem. And I personally like pair programming a lot because we are talking about code reviews in this. But the pair programming part it's like an ongoing code review as you go in and solve the issue that you're doing together. We can talk about pair programming later, but those are my thoughts on that. \n\nEDDY: As a band, you know, the more people that collaborate, it's an interesting dynamic because I associate that the more people you have in the pot, the slower it moves because you have more opinions. And so, because music is pretty subjective, the productivity does go down slightly, you know, the more people have input, kind of similar to the code, right? Like, if you're a single code developer [inaudible 05:52] to reviewers, the amount of feedback you get is much lower than if you have five or six people looking into these code changes, right?\n\nJUSTIN: Yeah, I think there's definitely a point of diminishing returns as you add more people to it. That's a pretty steep curve [laughs], and so... \n\nMIKE: You have bands with a couple of people. You have bands with three people. Four are pretty common. Very rarely do you have, like, 20. You've got like, what, Lynyrd Skynyrd, I don't know [laughter]. There's some crazy bands that have huge numbers of people, sort of a collective. But usually, you know, you just have a few because there's the limits, right? There's limits to what you can collaborate together on successfully. \n\nJUSTIN: Though I do love big band music. Give me a good, big band. But, at that point, it's like you have a conductor that is leading the show. Maybe the comparison breaks down a little bit there, but anyway. \n\nMIKE: Well, it's interesting. I mean, I was thinking similar. If you have a jazz combo, you know, a small jazz group, then there's a lot of room for creativity, and they can work together. When you get to the big band, you have a composer, right [laughs]? You have somebody who writes out the music, writes out the lead sheets, and gives it to people. It just changes the way you work. \n\nYou know, kind of going back to this idea that there's value in getting the collaborators–when we write code, it's very much common practice in the industry to have a code review or maybe pair programming, as Justin said, which is kind of a live code review, or you're collaborating in real-time, which is another way of providing value, right [chuckles]? Real-time collaboration provides many of the same benefits. It's normal industry to have a code review. \n\nThere are a few different purposes that could be proposed for that code review and that are sometimes used, and some of them, I think, have different value than others. For example, if you're sending some code over to code review and the primary feedback you get is stylistic, then I think that was a wasted opportunity [chuckles]. To say that again, I think that is a wasted opportunity. \n\nThere are automated tools in probably the language that they're using; if they're not, it would surprise me [chuckles]. There are automated tools in the language that you are using that can enforce style guidelines. And you can download the style guidelines from the internet and use what some big company uses and have a standard on your team. And you can make some tweaks to that. But the automated tool can enforce, you know, whether you use tabs versus spaces. It can enforce what your quotes look like. If you're having arguments about that, then I think you've got a more fundamental problem. \n\nThe place that we should start when you're working with the team is choosing the conventions that you're going to use, and that should just be the baseline, you know, that's the foundation. And if those come up in reviews, that means that somebody has either ignored those rules, and that's a different issue [chuckles], or you really haven't gotten consensus on your convention, and you need to go back to revisit the convention. So, I say this one more time, you know, I don't think that that is a valuable use of a code review.\n\nTo go to the music example, if you're a guitarist, you probably don't want somebody to say, \"Well, no, I think you should pull out a trumpet.\" \"What? [laughs] I don't know what you're talking about. We're a band that does not have trumpets.\" That's not what you're there for. But if somebody says, \"Hey, you know, I think you could change the rhythm on your riff,\" that's a different kind of comment. It's commenting about the structure of what you've created in a way that is meaningful. The style should just be a given going in. Anybody have thoughts on that particular idea?\n\nKYLE: I kind of agree, even the system's code that we have, you know, using Terraform, and I know that a lot of other languages have similar formatting tools, right? We've kind of just agreed, you know, we're going to use the Terraform format command. That is a quote, unquote \"reviewer\" per se in the steps in our PR, right? It's going to go through, and it will decline and say that we've failed if we haven't remembered to run that. \n\nBut then that keeps us all in line, especially where we're kind of cross-ecosystem, where some of us are running Mac, some of us are running Windows. And we avoid some of that, you know, line ending white space type issue, so that keeps us in line. And then the actual reviewers themselves they're looking at functionality of what we're actually creating the PR for rather than how does it look. \n\nMIKE: Yeah, yeah. Absolutely. And you're not wasting your time [laughs].\n\nKYLE: No. \n\nMIKE: You're not wasting your time haggling over details that have been decided. If it can be automated, it probably should be. We're developers. We tell the computers what to do for us [laughs]. And they can take away some of our work. \n\nEDDY: Would you agree, Mike, that getting an approval without any comments or \"Looks good to me\" would be just as bad as a wasted opportunity for stylistic comments?\n\nMIKE: That's a great question, a loaded question [laughter] because I think we've all probably thrown an LGTM or something similar onto a review. I think it opens up a broader question, actually, and something I wanted to talk a little bit about. Have any of you read the book, The Phoenix Project? It is classic in the industry and helped give birth to the DevOps movement. So, well, I'm going to strongly recommend it. I've read it multiple times. It consolidates a lot of research into a novel so that you get a really [laughter] enjoyable novel that's noted, right? It gives you references as to where a lot of this material came from. \n\nBut one of the key themes of that book is that batch size matters. Let me explain that. There's a surprising amount of parallel between software development and physical goods manufacturing, whether it be cars or, you know, I'll say cars [laughs], the manufacturer of automobiles. And a lot of times, people say, \"Well, no, I'm an artist. I read through this creative work.\" There's really nothing in line because, you know, I have to invent stuff all the time. \n\nAnd certainly, there are differences, but in aggregate, you take a step far back enough, you're looking at people who are building things. At a high level, that is largely predictable. You can measure it, and you can streamline it, and you can do things to improve the process. And one of the things that is really bad for physical world manufacturing is large batch size. \n\nFor example, if you've got a, like, a powder coating station, and you have to have a thousand parts to go through that powder coating station, because otherwise you're wasting the resources of a big booth, then you have to wait for all of those thousand parts to be made every time you pass it through. So, you have an enforced stop in your process in order to wait for the material to pile up before you send it through. So, if you were to stand up on a catwalk up above the floor, you'd see this big pile of stuff in front of a powder coating. You could see that just at a glance that, wow, there is a bottleneck in my process right there. We can't let anything through until it's all ready. \n\nAnd one thing that you can do to improve that on the assembly line is to rework your machinery so that you could have a continuous flow. So, if you could build a powder coating system that could take one part at a time, you know, you'd be required to rebuild the machining, but it would get rid of that dead spot. It'd get rid of that bottleneck in your process and reveal where the next bottleneck possibly was. But it would allow you to have continuous flow. \n\nSo, if your car, if you think about cars, if you have a bunch of auto bodies stacked up, well, that's hard to stack them up, right? How do you stack a bunch of auto bodies? It uses up space. It uses up mental energy. There's a lot of labor that goes into a large batch. And if you can reduce that batch size to a very small one, then a lot of that labor goes away. Sometimes, we think, well, I want to make sure my reviewer doesn't waste their time. So, I'm going to make sure I put a lot of code together, and I'm going to give it to them all at once. \n\nAnd I think that that way of thinking is usually in error because it ignores those other costs: the cognitive costs of trying to understand a great, big change, the time costs of waiting for weeks, maybe, to have this change go through, where you could have had incremental changes, where you're putting up pieces of code during all that time and getting value out of it.\n\nThis is kind of a long answer to your question, Eddy. But this batch size, I think, is critical because if you rework your process so that small changes are going through regularly, it may be that your code changes are so obvious that somebody's going to look at them and say, \"Oh yeah, well, of course, that works [laughter]. I really don't have anything to say because there's nothing left to talk about.\" \n\nBut that doesn't mean the conversation didn't happen because it took a lot of refinement ahead of time, earlier up that assembly line, right? Earlier in the process when you were planning out the work you were going to do when you broke it out into stories. That means that you already had those conversations as to what should be happening. \n\nSo, the conversation that might have come up in a code review did come up, whether you're pairing or whether you were refining together as a team earlier on. And so, when the reviewer finally got to it, they already knew what was going to be there. And when they looked at it, they say, \"Oh, this is exactly what I expected.\" And in that circumstance, I think that that's actually a win. But the communication happened. If there was no communication all the way along, I would say that there's definitely a problem. \n\nAnd, if you have a large batch, you've spent two weeks working on this PR, a pull request, you know, those who don't use the lingo. You're giving this to a reviewer, and they look at it for five minutes and say, \"Oh yeah, that's good.\" I think that's a problem [chuckles]. Because you've done a big body of work there, and it needs a lot of time. Really, you probably have asked for a day's worth of that person's time to really fully understand what's going on.\n\nJUSTIN: It's interesting, when people think of coding or when you're a coder yourself, and you're thinking, oh, my job is coding, and I'm going to put out a bunch of code. That's how I know that I'm doing a good job is: I put in a thousand lines of code today or something like that. Whereas, in reality, coding is certainly a significant part of your job, but even more important, is the planning about what you're doing and making sure that the whole process is given equal importance. \n\nYou're not just throwing your code over to be installed into production. You work with your team in planning what you're going to be working on. You work with your team on, you know, you do the actual work and then you do the code reviews, and you do the testing. Well, the testing should happen throughout and everything. And then there's the monitoring. And it's truly the software development life cycle, as they say. It's something that encompasses every part. \n\nIf you look at a typical software development life cycle graph, each of the parts is actually pretty much the same size. It kind of emphasizes that you can't just drop something. Or if you pay too much attention to a certain part, other parts may lack. But, I don't know; that's a little bit of a tangent with regards to code review, but I thought it was interesting.\n\nKYLE: That's kind of a tangent, but, I mean, to some extent, you maybe think with a PR, in that life cycle, as you're saying, so if I'm a dev and I throw up a PR, I have the experience from developing and whatever my team might have. But I also have the option of throwing somebody from QA, or security, or DevOps onto that, you know, that are down in the life cycle or somewhere in the life cycle as well. They can review it. They can throw their experience in there that I may not have thought about, you know, get those details going, kind of like you're saying, the monitoring and all that jazz before it even hits prod. \n\nEDDY: And, Justin, I have a question for you. So, you're in security, right? \n\nJUSTIN: Right. \n\nEDDY: Are you involved in any of the PRs that are going up in production at all or any? \n\nJUSTIN: Occasionally. And it hasn't happened that often yet. It happens probably about once every other week, maybe once every three weeks, where somebody asks us to take a look at something. You know, usually, it leads to the discussion about what's your intent here? You know, kind of walk me through your solution. A lot of it is, you know, people just need reassurance that what they did is the right way.\n\nBut occasionally, we come back and say, \"Hey, you know, you really should do some more validation, you know, just consider all your inputs as untrusted,\" or, you know, something to that effect where we talk through a particular solution. Oftentimes, it's talking about a third party and, you know, what we're sending them, or what they're sending us, and how do we trust it, or that sort of thing. \n\nLong story short, yeah, every couple of weeks, I get pulled in to take a look at something, and it is really cool. I love doing it because, you know, having that discussion and getting into the code is one of the funnest parts of my application security job. One of the least fun parts is the policy writing, which is what I'm doing today [laughs]. But yeah, if you guys ever want me to look at something, please feel free to interrupt me. Whatever I'm doing, I'm going to drop it and come help you [laughter].\n\nMIKE: Can I ask a follow-up question to that one?\n\nJUSTIN: Sure.\n\nMIKE: Would you rather talk to somebody once the code is already written or before they write the code? \n\nJUSTIN: That's a good question. Probably both, but there are certain questions that need to be answered before the code is written. We actually are working with Anna and the product team to make sure those questions are asked at the epic level and answer to the epic level, things like, you know, are there changes in authentication or authorization? Are there changes with PII data? Are there changes with third-party interaction? Those are the main three questions that we want to ask on each epic. \n\nA lot of times it's, like, not applicable or something like that because it's not, you know, they aren't doing that particular work or know or that sort of thing. But the times when we get brought into, when they put yes on those questions, we go in and have a conversation about exactly what's changed, and then, you know, just to make sure that those delicate subjects are treated with the proper respect that they need. \n\nMIKE: Let me take that a little further. Would you like a software project to be written, and then you come in and say, \"Okay, now it's time to add security to it\"? \n\nJUSTIN: Oh. Well, we've had that happen all the time, unfortunately [laughs]. \n\nMIKE: How well does that work? \n\nJUSTIN: It does not work well because it messes up people's timelines. You know, oftentimes, a project is headed towards production, and then, you know, expectations are set. And then somebody asks the question, \"Hey, we should have security look at this.\" And then, you know, we look at it, and we raise some questions.\n\nA good example is we had a question about something the mobile team was implementing, and we had to go back and say, \"Hey, what do you guys think about this?\" You know, a conversation went in about a particular API they had and how they were accessing it and how it was designed. We all agreed that, hey, changes needed to be made. And so, they had to go back and add another, I think, it was another couple of days at least of development work to fix the concerns. \n\nWe really don't want to go in and dictate stuff because the key there is helping people understand why we have concerns. And once we've had that conversation, oftentimes, people are like, yeah, that makes a lot of sense. And that's what we're shooting for is like, hey, we want you to understand why we have concerns. And what results from that is sometimes we change, but also, sometimes they understand why we have concerns, and then we can go in and explain the risks and have a discussion about timelines and things like that.\n\nMIKE: And obviously, I asked kind of a pointed question [laughter] that reveals that it is costly to make changes to a design late in the process. \n\nJUSTIN: Yes. \n\nMIKE: And security isn't just some dust you sprinkle on a project [laughter]. It's an integral part of the way a structure is built, you know, whether that's in physical world or in software [laughs]. You can't say, \"Oh, I'm going to build a building with no thoughts as to structural integrity [laughs] initially and then add that later.\" It's not something you can add later. It doesn't work that way. The security is built in from the beginning. And it's not just security, right? We bring up security as an example. \n\nIf the review is the first time that important conversations are happening, I think it's a real problem. Building a little bit more on Eddy's question, you know, \"It looks good to me,\" I think the ideal software development process, software development lifecycle, has communication early so that the review is there to have some dialogue, but it is a continuation of a conversation that was begun much earlier in the process.\n\nJUSTIN: I think we're moving towards a, you know, what should you be looking for in a code review? And as a code reviewer, I mean, we have a couple of things. What should you do to prepare your code for code reviews? And what should you do? As a code reviewer, what should you be doing? If you guys haven't seen it yet, there is a really good example that Google gives. They have a paper that they wrote, a white paper, that has those two sections. It's like, what should I be doing to have a good code review? And then the other section is what should I do as a good code reviewer?\n\nAnd if you haven't had the chance to look at that, go through it because I liked how it enumerated everything. It let me know what I was missing from both ends, you know, included things like, hey, is this performance? You know, performance is something you often don't think about that goes along with security; sometimes, you don't think about. But performance is like, you know, hey, it works for me in my development environment. And then you're like, somebody else who's doing a code review they should be aware of that. And, hopefully, their experience comes in and says, \"Hey, you know, accessing this table this many times is going to lead to some issues,\" or something like that, so yeah.\n\nMIKE: I fixed a performance issue during the winter, you know, Christmas time break. So [laughs], it's fresh on my mind and very much so. It's like security. You can't just bolt it on at the end. It's like, hey, we'll add performance now [laughs]. \n\nEDDY: Well, and, you know, I actually looked into that, too, when I came back, and it was really interesting because you could only replicate that in higher environments with a higher traffic count. And that's not as obvious, you know, when you're testing in a local environment, when you're truly in control of the data, right? \n\nMIKE: Yeah, leaning on expertise and talking about that early is really helpful. \n\nKYLE: I'm sitting here listening to this, too, and thinking through, and we're kind of saying it's hard or almost impossible to add it later, which for, like, performance and both security to the original product, yes. But I think the part that hasn't really been brought up is, so I'm thinking, performance. Yeah, if your app isn't performant, can you fix that? Sometimes you can't. How do you do that? You throw hardware at it. You throw money at it [laughter]. You get it fixed that way. [laughter] Same as security, right? You have to put another layer in front of it in order to fix your application. \n\nSo yeah, I mean, I'm agreeing with you guys, but I'm like, it becomes exponentially more costly because how do you end up fixing it? If you're fixing it late in the game, you're throwing extra layers at it, which costs more and more money. \n\nMIKE: There's a lot of these things that are pointing back to having these conversations early. And coming back to reviews, reviews are a conversation. It's intended as a venue for communication. And we may enforce it and say you have to do that [chuckles], but only because we've seen that it's so valuable. You know, somebody's making some work of art, and they want to bring it to somebody. They're trying to open a dialogue. They're trying to have a conversation. And that's what code reviews can really provide us is that conversation so that people are thinking and interacting together. \n\nIf there's any antagonism or ego involved in there, it's very destructive to that process. It's just an opportunity to collaborate. And when embraced as such, I think it can provide a lot of value. But also, it opens up to this bigger idea that communication and bringing communication cycles earlier in the process is vital to quality software. \n\nThere's another thing I've been thinking a lot about lately. Some years back, I don't even know how many years back, 20 probably, there was this document, the Agile Manifesto that was written. Some developers got together and said, \"You know, some things in process tend to be bad, and some things tend to be good.\" And they wrote a document that said, \"Well, this is better than this.\" And one of the better things, the things that's most important, is having those feedback loops where you have a quick cycle of information. You build something; you very quickly get it to somebody who can look at it and give you feedback. And then you make a little change then you quickly bring it back. \n\nThere's an alternative way, which is you spend, like, a year writing documentation, and then you hand it to somebody and say, \"Okay, go build it,\" [chuckles] And that doesn't tend to work very well. Maybe writing policies or [laughs] [inaudible 26:14] with documentation is hard. It doesn't fit very well. It's the way humans work. We work a lot better when we have something more tangible. Something we can look at, something we can talk about. \n\nAnd encouraging that communication cycle early is really what code reviews are an extension of. It's an opportunity to have built-in feedback into the system so that you can get some feedback there. But it's not the only one, and it's important to not lean on that one piece. Sometimes, people hear, \"Oh yeah, I want to be agile.\" And they think, I got to go get a book that says how somebody else did it and set up a process that follows that, you know, the diagrams they've got in the book.\n\nThat misses the whole point of what the document was about. Maybe not all of the point, but a lot of it, which is that some aspects of process are better than others. And central to the process, a good process, is recognition of human frailties and human strengths. And those work best under a tight feedback loop with a lot of communication. \n\nJUSTIN: And so, something that comes up often is, like, I've got a new thing, and it's hard to break down, and there's a lot of features on the new thing. How do I do incremental releases on the new thing and make it smaller? But I don't want to change the old thing until the new thing is all done or the new thing is ready to be released.\n\nMIKE: I get it. I've got some answers I can throw at that [laughs]. \n\nJUSTIN: Sure. \n\nMIKE: First of all, to your point about the old thing, I don't want to get rid of the old thing until the new thing is all ready. There's the temptation to think, okay, that means I need to go and build the whole thing, and then I'll have it tested. That's a really bad idea [laughs]. That's a really bad idea. To use a famous piece of hardware like the iPhone, I've never worked at Apple, but I extremely strongly doubt that they put together a completed iPhone, handed it to Steve Jobs, and said, \"Okay, this is ready. Go present on it.\" \n\nWhat they would have done is they would have had different departments building different components within that device, collaborating together, you know, figuring out the interfaces between them, and iteratively building that thing. Even though it wasn't released, they were internally testing. And, again, I'm guessing, but just knowing how software works, it's the only way it's possible. They would have been internally testing it all along in pieces and in gradually larger chains of components until the whole thing was put together.\n\nSo, by the time the whole thing was put together, it had been heavily tested in end-to-end tests all along. Likewise, when we're building new things in software, you know, it's just one example. You know, we think it's physical, so it's a little more tangible. We should never think, well, this isn't going to be released, so I'm not going to bother testing it or getting it reviewed until it's all done. And this is the whole point of that communication loop. \n\nThere's no reason you can't have a communication loop with your stakeholders, you know, people who've asked for it, whether that be product people in your company and, hopefully, even some beta testers out in the wild, some users who could be working with you and testing it. So, even though it's not going up to general release, you follow exactly the same process as you would otherwise. And then, when you're ready, you flip a flag and maybe move people over. At that point, you've gone through the process, just that we've talked about. You just happened to have done it with a smaller group.\n\nJUSTIN: And you can achieve that smaller group in a variety of ways, like keep it internal. Keep it behind a feature flag. You know, have alpha testers, have beta testers. All of these things can help you. You don't have to have general release, but you still gain the advantages of iterative releasing. \n\nMIKE: There's a longstanding practice in a lot of companies where they have feature releases, companies that are not yet doing continuous delivery, and sometimes that's imposed on you. If you've got, like, a mobile app, if it's going out through app stores, continuous delivery is hard [laughter] because you've got to get every change approved. So, there's an external constraint. The batch size is forced to be larger. And there could be a temptation in that environment to say, \"Okay, well, we'll build everything for the next release, and then we'll get it tested.\"\n\nBut best practice involves having a feature branch and be testing that. Treat that like your finished product and get your testing, get your feedback on that throughout the process so that when you finally get to that endpoint and ready for release, it's just a tag [laughs] almost, right? You're at a point where you know that it's already good.\n\nEDDY: We've talked a lot about, like, why do code reviews, but I'm still kind of curious on how you would do a code review. And one thing that we actively practice, at least in the team that I'm on, is keeping the code file changes concise and below a minimum file change. And I think we've determined that that's easier to be more productive and find bugs if the code changes are small. I like that idea. I've seen other teams that do larger file changes, and, to me, it's sort of like, how the heck are you able to give a good review when you have 40 or 50 file changes in a single [inaudible 31:15], right? \n\nMIKE: I would suggest you probably can't. \n\nJUSTIN: Sometimes, you just have to hit approve. Is that what you're saying? \n[laughter]\n\nMIKE: At some point, you're going to have to press that button [laughter]. The clock is ticking. That's why you don't put yourself in that situation in the first place. \n\nI think, you know, it's something Justin is saying. Preparing for reviewers, one thing you can do is not put a huge change; give them a huge change. Well, one thing I like to do is I like to put comments, not necessarily in the code, but on the pull review itself, you know, so kind of meta information. I'll go and I'll leave comments on my own code, you know, on my own pull request, and say, \"Well, this is why I did this here. Maybe give this area some scrutiny. This is where some, you know, sensitive changes are.\" Or \"This test was added,\" you know, whatever it is. I feel like that's really valuable, in my opinion. \n\nJUSTIN: Should those be in the code review, or should those be actual comments in the code?\n\nMIKE: I phrased that specifically because I think, I mean, arguably, they could be comments in the code, but some things I don't think are necessarily appropriate as comments in the code, that is, they don't make sense in the code. If I came back a year later, that comment wouldn't make any sense to me because it's talking about something that's not applicable in that context. \n\nBut in the context of that change, it's very important, and that's where I think the value in having that kind of meta commenting, where, you know, you're commenting on the review, you know, on the change, the request, rather than on the code itself means that there's no artifact that's going into the permanent code from your changes. But there is, you know, that artifact that somebody can look at as they're reviewing to get some additional context. That's one thing that I think is helpful. \n\nEDDY: Typically, when we add comments to code, it's because it's supposed to make it easier to understand. If you're adding comments to make it easier, does that imply that the logic for that code that you're making is difficult? And if that's the case, maybe we shouldn't be commenting, but rather, we should be refactoring it or breaking it down.\n\nMIKE: I would agree with that. I don't know that I'd go as far as to say that comments are a smell, but I maybe come close. That code that requires comments is complex. Anything complex is hard to work with. \n\nKYLE: I actually just started doing that. I started putting my own comments on my PRs, like, mostly on stuff that I'm not 100% sure of, like, stylistic and, like, team convention on how we like to do that. Like, I was just writing a validation for just a model the other day. And there was two options I could have gone with, a custom validator, or they have, like, built-in syntax you can do just, like, right at the top, whatever. And I was like, which would we prefer? What's the team convention on this? And I thought it was helpful. And also, explaining my thought process on how I thought this should be done. Is there a better way? That kind of stuff. \n\nMIKE: And did you get some feedback on it? \n\nKYLE: I did. Yeah. Very helpful.\n\nMIKE: Exactly. You opened up a dialogue. You held up that olive branch and said, \"Please.\" [laughs] \n\nJUSTIN: So, one of the things that I've found really helpful is you are your own first code reviewer. And I think you were kind of alluding to that when you're writing comments in your own code review. When you create your code review, you need to go through and review it yourself. Look at all the file changes and everything. And I found that for my code, I catch all sorts of stuff [laughs]. \n\nSo, it turns out that that code review is really helpful for me to get it ready before I send it out to other people. So, don't be afraid to create a code review and label it as draft or something like that. And then, you'll be making more changes to it, but it really is helpful to see it in that code review mindset. It's almost as if you're wearing a different hat. You know, getting that different perspective just from yourself is really helpful. \n\nKYLE: Yeah, like, I treat it like almost as if you're, like, proofreading an essay. Like, when you're first writing it, it's like, it might work. It might still be correct. But is there a better way to go? You know, you read back through your sentence, and you're like, oh, I'm going to put this verb at the end of the sentence to, you know, add additional emphasis to it, or anything like that. I think it's a good mindset to stay in.\n\nEDDY: There have been times where it's been easier to express my concern with a pull request by just hopping on the call with that developer and be like, \"Hey, instead of going back and forth, you know, on this pull request [laughs] that can span 20 or 30 threads long, you know, it's easier to hop on a call and elaborate what those changes are [inaudible 35:54]. \n\nThe problem with that, and I don't know if you all agree, is if I have that question, probably someone else who stumbles upon the code will have the same question. So, at what point do you move the conversation audibly versus having it traceable, you know, in a pull request so that it becomes easier for someone else? Because, at some point, it becomes documented.\n\nMIKE: You know, I will do the same thing we've been talking about, and I'll leave a comment on the pull request and say, \"Okay, we had this conversation.\" Or \"Can we have this conversation?\" So, another reviewer looks in and sees, oh, there's another conversation here that I don't know about. I can go ask about that. And I like to call that out for that very reason. If they don't know about it, then they can't take advantage of it. \n\nJUSTIN: Having multiple different ways of communication that's just something that we're used to. Personally, like, I'll leave small comments on PRs when I know that people are working on other things. And they'll get around to it, and then they could just leave some insight. Obviously like, if it's a very long, heavy, big concept, then taking it onto a call or, like, a Slack chat, whatever, definitely would make it easier, for sure. So, I think it depends on the situation.\n\nMIKE: The idea we've been talking about of communication being vital suggests that the channel is not as important as the conversation. But making people aware...it sounds like part of your question was saying, well, there's no artifact to this conversation, so nobody knows it happened. That signaling, putting some sort of signal, that's more communication. You're saying a conversation happened, and things we can do to signal to others that something happened, I think, are really valuable. It's being proactive, maybe not quite noisy, but providing lots of hooks for people to grab onto to know what's going on. It enables that communication to happen more effectively.\n\nJUSTIN: So, that kind of leads into a question of what kind of comments should you be putting in there? There's different levels of comments. There's, like, a nit level of comment. Like, this is a minor thing, you know, consider putting this on one line or do this on, you know, maybe use a slightly different function like a math function or something like that. You have optional stuff. Clearly label it optional if something is optional. And then there's, like, the ones that are like, \"Hey, I don't think this will work. Let's have a conversation offline,\" that sort of thing. What are the different levels that you guys put on there? \n\nMIKE: I think you left out another one that's actually as important, if not more important. Like, \"Hey, this is great.\" \n\nJUSTIN: Yes. Yes, I did [laughter].\n\nMIKE: That sets an atmosphere. It sets a tone. You know, going back to music, you know, I like that riff. What if we change the rhythm? It lets people know that you understand the algorithms. You understand the big picture, and you really like what's going on. So, they have that framework, you know, that scaffolding to hold on to. It doesn't sound like I'm coming here to say, \"Your code sucks.\" That's a miserable experience for everybody. So, I would add that to your list, although I think your list is valuable. \n\nYou know, there's different degrees, and I think that it'd be nice if there was, like, color coding or something so you could say. But, you know, there's verbal cues you can give like, \"Oh, this is not a big deal. This is a style thing. This is important. Please let's talk about it. But also, you know, I like what you did here. This line is beautiful. I really like how concisely you wrote this.\" \n\nI think those comments...and you might think, well, I don't need to put those. That doesn't change the code. It isn't going to change anything. Well, it is changing something [chuckles]. It's changing the perspective of the person who wrote the code so they understand where you're coming from. \n\nEDDY: I don't even shy away from leaving a comment being like, \"Can you explain what this does? This is pretty ambiguous. Can you elaborate what your intention is?\" Because, at the end of the day, the one that's stamping the approval is me. So, like, if I feel unconfident or unsure about that change, I don't shy away from that. And I typically tend to be, like, the straggler. \n\nJUSTIN: So, what do you think about, you know, suppose you do have, like, a comment, like, you don't think this will work. Have you considered, like, do you add additional stuff, like, have you considered X, or have you considered Y? \n\nMIKE: And code examples are really nice in that context, where X has some actual code written out, you know, maybe it's pseudocode, but, you know, it lays out an idea. It's a whole lot easier to talk about something that is concrete. \n\nEDDY: Okay, can I just preface and go on record and saying, hey, I really love it when someone says, \"Hey, I think it would be better this way,\" and they provide a code block. And like, \"This is how I would think this reads better.\" Oh my God, like, how helpful.\n\nMIKE: [laughs]\n\nEDDY: Because then not only do you understand what they're trying to get the point across, but you can see an example of what they meant. I love that. And it takes, what, like, an extra two minutes or so to pseudocode, like Mike was saying.\n\nJUSTIN: I kind of want to go back to the format of code reviews. I mean, the ideal situation is that you're a developer, and you want to go sit down with somebody else, and you are sitting there with them. And they review your code face-to-face. In the ideal world, that'd be awesome, and you can have a conversation face to face. But we can't often do that because of, you know, time zones or, you know, we all have different things going on that we're working on. \n\nAnd so, code reviews are there to make that experience as close as possible to that experience. And whatever you can do as a code reviewer to make that experience happen, I think, is a good thing. And so, being very clear and being verbose, maybe not too verbose, but being very cognizant of how the other person looks and feels, and what their situation is, and things like that. All that comes into play while you're doing this code review, and they're not sitting there right next to you. \n\nEDDY: What's everyone's opinion on paragraphs being left as code reviews throughout the whole code? \n\nJUSTIN: Wait, a whole paragraph? Like -- [laughs]\n\nEDDY: It happens. Like, what's your opinion? Because you have, like, ten file changes, and, like, on each file, you have, like, a paragraph that's being written on, like, the gravity of that change [inaudible 42:06]. It doesn't happen often, but it does happen. Like, at that point, do you find that disruptive, or do you find that a bit overwhelming? Like, I'm kind of curious. \n\nJUSTIN: I don't know. I've never really had that much [laughs]. My initial thought would be like, oh, that's a lot. But I don't know, have other people had that experience?\n\nMIKE: I'm thinking of one reviewer who tends to leave long comments like that. \n\nEDDY: [laughs]\n\nMIKE: And my default answer is going to be, wow, you cared enough to give me all this information. Thank you. It might take a little bit of time, but that means that they respected this interaction enough to give it that much attention. Somebody doesn't do that unless they care.\n\nKYLE: At times, I'll run into situations where I want to leave a paragraph. \n\nMIKE: [laughs]\n\nKYLE: And in those boats, I don't want to make the individual feel uncomfortable because I feel like when you do that, it's a bit of a, like, hey, change your world, change everything you're doing type of feeling when somebody comes at you like that. So, I prefer to take those offline and, like, do a direct message with them, kind of work through it a bit, and then come back with a smaller comment. That's my approach. I have had people leave those larger paragraphs, and I just know I personally don't feel great about them most of the time. So, yeah, that's what I've done. \n\nMIKE: We've been talking a lot about keeping your audience in mind. It matters. Yeah, I think having a mental model of who you're working with and being respectful of them can make the process go a lot smoother. \n\nKYLE: I do feel like the quicker channels like Slack or Teams or whatever you do, something with a communication turnaround, it's a little bit easier to avoid miscommunications as well than back-and-forth communication on a PR. So, that's what I mean when taking it offline, too. \n\nMIKE: It's a lot easier to have a conversation, a verbal conversation, than to have somebody write ten paragraphs [laughter]. \n\nEDDY: And maybe you can take it a step further and do it in person. \n\nJUSTIN: Yeah. And actually, one comment and then one kind of moving to the next level. Yeah, like I said earlier, it's always, like, whatever you can do to convey your intents in a clear manner. Sometimes that is just a single line on the comments, or sometimes it is, like, you having to sit down because it might take you a little while longer to get your intent across. And then, like you said, Mike, it's really important that you understand your audience.\n\nAnd then, the next question I have, if we were to take this kind of where we're leading, is how do we handle pushback in code reviews? Suppose somebody comes in and says, \"Hey, you need to do it this way [laughs]. This is the way.\" So, how do you handle that sort of situation? \n\nEDDY: I've gotten pushback so far as people will request code changes without even, like, approaching me directly regarding their question. [inaudible 45:08] just sits there [chuckles]. You're just like, ah, like, I could have explained it had you just messaged me directly versus, like, abrupt request code changes. But I'm typically pretty open. \n\nI was told pretty early on, actually, by a lot of people who mentored me saying, \"Hey, don't be married to your code.\" And I live by that. I really do. I'm super early in my career, so if someone suggests something, I'm like, it's for a reason. Like, they've probably been through the same pain point, and they're trying to save you the heartache, you know, having to deal with the same thing they did. So, typically, I'm pretty open, and I'm pretty flexible. Very seldomly do I push back and be like, \"But this works, and it does the same thing.\" Very rare. However, nine times out of 10, I typically say, \"Oh yeah, that does look better. That does read nicer.\" \n\nMIKE: Sometimes there are team conventions that you can point to, and if, as a reviewer, I say, \"Well, this is our team convention,\" and there's justification there. You can point to an example and say, \"Well, this is why we should do it.\" That sounds different than somebody coming and saying, \"Well, no, I hate your code. You should do it my way.\" One of them is conscientious. It refers back to the standards that you've developed as a team. It ties back into the consensus. And the other one is very egocentric. Like, well, this is just all about me and my perspective. \n\nAnd I think that both as a reviewer and as a reviewee, keeping those ideas in mind matters. The code is a group product. And if we can build the team, then we should try to do so. And it's not really about us personally, and if it is, then you're ejecting yourself, right? Then that is actually not valuable for the company probably. You've brought something that's not valuable to the company, and you're just bringing your own baggage in. You know, and we all have our own things that we're working through, but trying to avoid that where possible, both as a reviewer and a reviewee, I think, smooths out the process, not just in code reviews but in life [laughs]. \n\nEDDY: Do you ever find yourself approving code before it's ready, trusting the person that they're going to go in and actually update what you recommended? Let me take that a step further. Let's say you say, \"Oh, this looks good. I recommend these changes, but are non-blockers.\" Like, do you find yourself approving PRs like that, or do you sit back and wait for them to make a change? \n\nJUSTIN: You just said that it was a non-blocker, so why don't you approve it? \n\nEDDY: All right. Because, like, I've seen, like, feedback where it's just like, oh yeah, like, I'd recommend doing it this way, but I get it, non-blocking, blah, approved. Like, do we feel good when it comes to doing approvals like that, or do we prefer to [inaudible 47:47] upon that and only approve it only after you feel really good about the change?\n\nMIKE: There's some people who I know if I left that comment they're going to go back and make the change. I made a comment like that on a review probably a couple of months ago. You know, the coder went back and said, \"Oh, you know, that was a really good idea. [laughs] That could have really simplified this.\" They went back and made the change. And I saw that in my email a couple of days...I was like, oh. [laughs] I didn't get a chance to get back to it, and they totally made the change. And I know that that, you know, that person would do it. \n\nIf I'm working with somebody who is just getting started and they're kind of overwhelmed [laughs] and they don't know what to do, then I'm probably not going to approve it, not because I don't approve of them as a person or, you know, of their ability generally but just because you've improved the process to give them a chance to make those changes. It depends some on the audience. \n\nKYLE: It made me kind of think whenever I'm doing a review, I try to keep the audience in mind in the sense that do I know this individual? And if I don't know this individual, what is their background? There will be times when I'm either recommending a change, you know, and how much detail I will go into sometimes I will take into consideration their level in so much that if I'm not aware, I've gone into our directory and seeing, like, what level of the chain they are, you know, like, are they a software 1, 2, 3 type thing, you know. \n\nAnd if it's a more junior individual, I will take the time to elaborate more or reach out to them. If they're more of a senior individual, I will take more of those, I guess, shorter routes where it's just kind of a quick explanation, kind of expecting that they'll take it and do what they will with it. That's just me, but I tend to do that route. \n\nMIKE: You know, and this recurring theme of knowing your audience maybe is a good point to kind of conclude this session. We started talking about music and art and getting feedback. They say when you're making YouTube videos, don't read the comments [laughs] because we know the internet is mean. There are people that you actually care about and trust that you want their feedback. And code review is an opportunity to get that, you know, it's an opportunity to collaborate with people that you want to collaborate with generally. You can get advice on how to make a better product. \n\nIt's part of a broader culture of communication. In isolation, it's probably not going to help you very much [laughs]. You can't stick that security on at the end. But as part of a broader culture of tight communication loops, it can expand the communication in a really healthy, productive way and result in better code.\n\nThank you, everybody, for participating today. Any final words? \n\nJUSTIN: Let me put my security hat on. Check your security issues while you do a code review. All right, now I'll take it off. \n\n[laughter]\n\nMIKE: Thank you. [inaudible 50:36] for us next time on the Acima Development Podcast.","content_html":"In this episode of The Acima Development Podcast, host Mike Challis introduces a discussion on code reviews by drawing an analogy between creating music and coding while sharing personal stories about feedback in musical endeavors to illustrate the importance of constructive criticism. These anecdotes highlight the parallels between receiving feedback on creative projects, like music, and technical work, such as code, emphasizing how both require openness to feedback for improvement.
\n\nThe conversation then goes into the specifics of code reviews, highlighting their value in the software development process and how code reviews are akin to collaborations in music, where input from multiple contributors often leads to a superior output. The panelists explore the nuances of effective code reviews, including the balance between too many and too few contributors, the importance of automation in enforcing style guidelines, and the value of comments within the review process to provide context and facilitate understanding.
\n\nThe episode concludes with a deep dive into the best practices for conducting code reviews, addressing the challenges of pushback, the significance of understanding the reviewer's perspective, and strategies for ensuring constructive and efficient feedback. The conversation also touches on the importance of security considerations during the review process and the potential pitfalls of approving changes prematurely.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development podcast. I'm Mike, and I'll be hosting today. Here we have with us Eddy, Justin, and Kyle who've been with us before. And we are going to be talking about code reviews. I like to start with a story, and I'm going to do that.
\n\nSometime recently, we talked about music and about how there's often overlap between people who make music and people who write code. I'm going to build on that a little bit. I like to write music. I sometimes just write music for fun. I do stuff my kids like [laughs]. Their favorite song is something I did; it was just kind of a personal challenge. You know the video game Plants vs. Zombies?
\n\nJUSTIN: Mm-hmm.
\n\nMIKE: I [laughs] listened to the soundtrack of that, and I thought, if I were to write the soundtrack, what would I do? And I wrote a song that kind of captured my take on it. And my kids love it. That's the one they ask me to play most [laughter]. So, I feel pretty good about that. They are honest judges. And, you know, they do, you know, they give me commentary on it. And sometimes there's a situation like that, and sometimes there's something a little bit more formal.
\n\nA serious example: I had a friend who passed away a few years ago, and they asked me to do an arrangement for her funeral. And I got together with the woman who was going to be singing. I did an arrangement, and I brought it to the singer, and she gave me feedback. And she said, "Well, you know, I think that there's too much build in the second verse, and I think we should move that to the third verse." And, honestly, she was right [laughs] in kind of every respect. She had the feedback that was necessary in order to improve that arrangement, you know, for something that we both cared about. That's really relevant, and that's not the only time that's happened.
\n\nI've got some friends that got a high schooler who's in...he does a lot of singing and drama. He's involved in a lot of those things. And I've done something with him before, too. Once again, I gave it to the singer. He came back with feedback and said, "Well, you know, I think we should change this. I think the melody is a little too repetitive. And I think if it went up here instead of down, that'd be better." And he was right. It made a genuine improvement to the structure of the music I put together.
\n\nI think that this story is really instructive. It's a review of something creative that is not in code, but it has many of the same characteristics as what we do in code, sometimes anybody who creates something. There's an intro to a song by a musician, like, a soul singer. She says [chuckles], "You know, remember, I'm an artist. I'm sensitive [laughs]. So, we feel that way, you know." Like, I'm an artist. I make this beautiful, perfect thing. And we think, well, you know, if anybody is giving me any feedback about this, they're criticizing my personal character and saying that I'm just not good enough. It's a really dangerous thing, both for ourselves and our art, I think, to start thinking that way.
\n\nIt doesn't matter really how brilliant we think we are [laughs], and maybe we are. You know, maybe you have beautiful art that you create. Getting feedback on what you've created allows you to see it from a different perspective. We are all limited by the scope of what we can see with our own perspective. And seeing something from somebody else's perspective can help open up new views into something that may be wonderful.
\n\nYou may have built something that's truly good. And when an eager collaborator is coming to work with you, they're not interested in tearing you down. They're interested in helping you make it better and in helping you achieve your vision. And they can say, "You know, I think that you were trying to do this. I don't think you quite got there," and help you better accomplish your purpose that you had initially. That framing, for me, for reviews is extremely helpful.
\n\nNow, we're going to be talking about code reviews, you know, that's perhaps more technical, maybe [laughs], than some of the stuff that comes from other creative endeavors, but it has many of the same characteristics. We're trying to solve a problem. And getting that second pair of eyes can help us solve the problem better in many cases. Also, the collaborator, in general, and if you're not doing this, you're doing it wrong [laughs], is trying to help you accomplish your purpose, not to tear you down, but to just help you do it better. And that second pair of eyes, that sounding board, is extremely helpful. So, that's the framing I wanted to start with. Does anybody have any thoughts about that?
\n\nJUSTIN: It's interesting because you see a lot of people that do great work, like, artists or whatever, all by themselves. And then they get together with somebody, and they do a collaboration. And some of the best music comes out of collaborations. And it's like, a couple of my favorite songs have, like, a lead artist, and then they have some lesser-known artist that is coming in and doing a riff or something like that. But you can tell that they meshed together their ideas and just made something so much better.
\n\nIf you think about music these days, it's not just, you know, people don't just, like, or most of the time, they don't just slam something down, and it's done. It is a work of months and months and months, and they're tweaking every little thing. If you get somebody else in on that, it makes that tweaking move much faster because you have somebody else that you're brainstorming with to solve the problem. And I personally like pair programming a lot because we are talking about code reviews in this. But the pair programming part it's like an ongoing code review as you go in and solve the issue that you're doing together. We can talk about pair programming later, but those are my thoughts on that.
\n\nEDDY: As a band, you know, the more people that collaborate, it's an interesting dynamic because I associate that the more people you have in the pot, the slower it moves because you have more opinions. And so, because music is pretty subjective, the productivity does go down slightly, you know, the more people have input, kind of similar to the code, right? Like, if you're a single code developer [inaudible 05:52] to reviewers, the amount of feedback you get is much lower than if you have five or six people looking into these code changes, right?
\n\nJUSTIN: Yeah, I think there's definitely a point of diminishing returns as you add more people to it. That's a pretty steep curve [laughs], and so...
\n\nMIKE: You have bands with a couple of people. You have bands with three people. Four are pretty common. Very rarely do you have, like, 20. You've got like, what, Lynyrd Skynyrd, I don't know [laughter]. There's some crazy bands that have huge numbers of people, sort of a collective. But usually, you know, you just have a few because there's the limits, right? There's limits to what you can collaborate together on successfully.
\n\nJUSTIN: Though I do love big band music. Give me a good, big band. But, at that point, it's like you have a conductor that is leading the show. Maybe the comparison breaks down a little bit there, but anyway.
\n\nMIKE: Well, it's interesting. I mean, I was thinking similar. If you have a jazz combo, you know, a small jazz group, then there's a lot of room for creativity, and they can work together. When you get to the big band, you have a composer, right [laughs]? You have somebody who writes out the music, writes out the lead sheets, and gives it to people. It just changes the way you work.
\n\nYou know, kind of going back to this idea that there's value in getting the collaborators–when we write code, it's very much common practice in the industry to have a code review or maybe pair programming, as Justin said, which is kind of a live code review, or you're collaborating in real-time, which is another way of providing value, right [chuckles]? Real-time collaboration provides many of the same benefits. It's normal industry to have a code review.
\n\nThere are a few different purposes that could be proposed for that code review and that are sometimes used, and some of them, I think, have different value than others. For example, if you're sending some code over to code review and the primary feedback you get is stylistic, then I think that was a wasted opportunity [chuckles]. To say that again, I think that is a wasted opportunity.
\n\nThere are automated tools in probably the language that they're using; if they're not, it would surprise me [chuckles]. There are automated tools in the language that you are using that can enforce style guidelines. And you can download the style guidelines from the internet and use what some big company uses and have a standard on your team. And you can make some tweaks to that. But the automated tool can enforce, you know, whether you use tabs versus spaces. It can enforce what your quotes look like. If you're having arguments about that, then I think you've got a more fundamental problem.
\n\nThe place that we should start when you're working with the team is choosing the conventions that you're going to use, and that should just be the baseline, you know, that's the foundation. And if those come up in reviews, that means that somebody has either ignored those rules, and that's a different issue [chuckles], or you really haven't gotten consensus on your convention, and you need to go back to revisit the convention. So, I say this one more time, you know, I don't think that that is a valuable use of a code review.
\n\nTo go to the music example, if you're a guitarist, you probably don't want somebody to say, "Well, no, I think you should pull out a trumpet." "What? [laughs] I don't know what you're talking about. We're a band that does not have trumpets." That's not what you're there for. But if somebody says, "Hey, you know, I think you could change the rhythm on your riff," that's a different kind of comment. It's commenting about the structure of what you've created in a way that is meaningful. The style should just be a given going in. Anybody have thoughts on that particular idea?
\n\nKYLE: I kind of agree, even the system's code that we have, you know, using Terraform, and I know that a lot of other languages have similar formatting tools, right? We've kind of just agreed, you know, we're going to use the Terraform format command. That is a quote, unquote "reviewer" per se in the steps in our PR, right? It's going to go through, and it will decline and say that we've failed if we haven't remembered to run that.
\n\nBut then that keeps us all in line, especially where we're kind of cross-ecosystem, where some of us are running Mac, some of us are running Windows. And we avoid some of that, you know, line ending white space type issue, so that keeps us in line. And then the actual reviewers themselves they're looking at functionality of what we're actually creating the PR for rather than how does it look.
\n\nMIKE: Yeah, yeah. Absolutely. And you're not wasting your time [laughs].
\n\nKYLE: No.
\n\nMIKE: You're not wasting your time haggling over details that have been decided. If it can be automated, it probably should be. We're developers. We tell the computers what to do for us [laughs]. And they can take away some of our work.
\n\nEDDY: Would you agree, Mike, that getting an approval without any comments or "Looks good to me" would be just as bad as a wasted opportunity for stylistic comments?
\n\nMIKE: That's a great question, a loaded question [laughter] because I think we've all probably thrown an LGTM or something similar onto a review. I think it opens up a broader question, actually, and something I wanted to talk a little bit about. Have any of you read the book, The Phoenix Project? It is classic in the industry and helped give birth to the DevOps movement. So, well, I'm going to strongly recommend it. I've read it multiple times. It consolidates a lot of research into a novel so that you get a really [laughter] enjoyable novel that's noted, right? It gives you references as to where a lot of this material came from.
\n\nBut one of the key themes of that book is that batch size matters. Let me explain that. There's a surprising amount of parallel between software development and physical goods manufacturing, whether it be cars or, you know, I'll say cars [laughs], the manufacturer of automobiles. And a lot of times, people say, "Well, no, I'm an artist. I read through this creative work." There's really nothing in line because, you know, I have to invent stuff all the time.
\n\nAnd certainly, there are differences, but in aggregate, you take a step far back enough, you're looking at people who are building things. At a high level, that is largely predictable. You can measure it, and you can streamline it, and you can do things to improve the process. And one of the things that is really bad for physical world manufacturing is large batch size.
\n\nFor example, if you've got a, like, a powder coating station, and you have to have a thousand parts to go through that powder coating station, because otherwise you're wasting the resources of a big booth, then you have to wait for all of those thousand parts to be made every time you pass it through. So, you have an enforced stop in your process in order to wait for the material to pile up before you send it through. So, if you were to stand up on a catwalk up above the floor, you'd see this big pile of stuff in front of a powder coating. You could see that just at a glance that, wow, there is a bottleneck in my process right there. We can't let anything through until it's all ready.
\n\nAnd one thing that you can do to improve that on the assembly line is to rework your machinery so that you could have a continuous flow. So, if you could build a powder coating system that could take one part at a time, you know, you'd be required to rebuild the machining, but it would get rid of that dead spot. It'd get rid of that bottleneck in your process and reveal where the next bottleneck possibly was. But it would allow you to have continuous flow.
\n\nSo, if your car, if you think about cars, if you have a bunch of auto bodies stacked up, well, that's hard to stack them up, right? How do you stack a bunch of auto bodies? It uses up space. It uses up mental energy. There's a lot of labor that goes into a large batch. And if you can reduce that batch size to a very small one, then a lot of that labor goes away. Sometimes, we think, well, I want to make sure my reviewer doesn't waste their time. So, I'm going to make sure I put a lot of code together, and I'm going to give it to them all at once.
\n\nAnd I think that that way of thinking is usually in error because it ignores those other costs: the cognitive costs of trying to understand a great, big change, the time costs of waiting for weeks, maybe, to have this change go through, where you could have had incremental changes, where you're putting up pieces of code during all that time and getting value out of it.
\n\nThis is kind of a long answer to your question, Eddy. But this batch size, I think, is critical because if you rework your process so that small changes are going through regularly, it may be that your code changes are so obvious that somebody's going to look at them and say, "Oh yeah, well, of course, that works [laughter]. I really don't have anything to say because there's nothing left to talk about."
\n\nBut that doesn't mean the conversation didn't happen because it took a lot of refinement ahead of time, earlier up that assembly line, right? Earlier in the process when you were planning out the work you were going to do when you broke it out into stories. That means that you already had those conversations as to what should be happening.
\n\nSo, the conversation that might have come up in a code review did come up, whether you're pairing or whether you were refining together as a team earlier on. And so, when the reviewer finally got to it, they already knew what was going to be there. And when they looked at it, they say, "Oh, this is exactly what I expected." And in that circumstance, I think that that's actually a win. But the communication happened. If there was no communication all the way along, I would say that there's definitely a problem.
\n\nAnd, if you have a large batch, you've spent two weeks working on this PR, a pull request, you know, those who don't use the lingo. You're giving this to a reviewer, and they look at it for five minutes and say, "Oh yeah, that's good." I think that's a problem [chuckles]. Because you've done a big body of work there, and it needs a lot of time. Really, you probably have asked for a day's worth of that person's time to really fully understand what's going on.
\n\nJUSTIN: It's interesting, when people think of coding or when you're a coder yourself, and you're thinking, oh, my job is coding, and I'm going to put out a bunch of code. That's how I know that I'm doing a good job is: I put in a thousand lines of code today or something like that. Whereas, in reality, coding is certainly a significant part of your job, but even more important, is the planning about what you're doing and making sure that the whole process is given equal importance.
\n\nYou're not just throwing your code over to be installed into production. You work with your team in planning what you're going to be working on. You work with your team on, you know, you do the actual work and then you do the code reviews, and you do the testing. Well, the testing should happen throughout and everything. And then there's the monitoring. And it's truly the software development life cycle, as they say. It's something that encompasses every part.
\n\nIf you look at a typical software development life cycle graph, each of the parts is actually pretty much the same size. It kind of emphasizes that you can't just drop something. Or if you pay too much attention to a certain part, other parts may lack. But, I don't know; that's a little bit of a tangent with regards to code review, but I thought it was interesting.
\n\nKYLE: That's kind of a tangent, but, I mean, to some extent, you maybe think with a PR, in that life cycle, as you're saying, so if I'm a dev and I throw up a PR, I have the experience from developing and whatever my team might have. But I also have the option of throwing somebody from QA, or security, or DevOps onto that, you know, that are down in the life cycle or somewhere in the life cycle as well. They can review it. They can throw their experience in there that I may not have thought about, you know, get those details going, kind of like you're saying, the monitoring and all that jazz before it even hits prod.
\n\nEDDY: And, Justin, I have a question for you. So, you're in security, right?
\n\nJUSTIN: Right.
\n\nEDDY: Are you involved in any of the PRs that are going up in production at all or any?
\n\nJUSTIN: Occasionally. And it hasn't happened that often yet. It happens probably about once every other week, maybe once every three weeks, where somebody asks us to take a look at something. You know, usually, it leads to the discussion about what's your intent here? You know, kind of walk me through your solution. A lot of it is, you know, people just need reassurance that what they did is the right way.
\n\nBut occasionally, we come back and say, "Hey, you know, you really should do some more validation, you know, just consider all your inputs as untrusted," or, you know, something to that effect where we talk through a particular solution. Oftentimes, it's talking about a third party and, you know, what we're sending them, or what they're sending us, and how do we trust it, or that sort of thing.
\n\nLong story short, yeah, every couple of weeks, I get pulled in to take a look at something, and it is really cool. I love doing it because, you know, having that discussion and getting into the code is one of the funnest parts of my application security job. One of the least fun parts is the policy writing, which is what I'm doing today [laughs]. But yeah, if you guys ever want me to look at something, please feel free to interrupt me. Whatever I'm doing, I'm going to drop it and come help you [laughter].
\n\nMIKE: Can I ask a follow-up question to that one?
\n\nJUSTIN: Sure.
\n\nMIKE: Would you rather talk to somebody once the code is already written or before they write the code?
\n\nJUSTIN: That's a good question. Probably both, but there are certain questions that need to be answered before the code is written. We actually are working with Anna and the product team to make sure those questions are asked at the epic level and answer to the epic level, things like, you know, are there changes in authentication or authorization? Are there changes with PII data? Are there changes with third-party interaction? Those are the main three questions that we want to ask on each epic.
\n\nA lot of times it's, like, not applicable or something like that because it's not, you know, they aren't doing that particular work or know or that sort of thing. But the times when we get brought into, when they put yes on those questions, we go in and have a conversation about exactly what's changed, and then, you know, just to make sure that those delicate subjects are treated with the proper respect that they need.
\n\nMIKE: Let me take that a little further. Would you like a software project to be written, and then you come in and say, "Okay, now it's time to add security to it"?
\n\nJUSTIN: Oh. Well, we've had that happen all the time, unfortunately [laughs].
\n\nMIKE: How well does that work?
\n\nJUSTIN: It does not work well because it messes up people's timelines. You know, oftentimes, a project is headed towards production, and then, you know, expectations are set. And then somebody asks the question, "Hey, we should have security look at this." And then, you know, we look at it, and we raise some questions.
\n\nA good example is we had a question about something the mobile team was implementing, and we had to go back and say, "Hey, what do you guys think about this?" You know, a conversation went in about a particular API they had and how they were accessing it and how it was designed. We all agreed that, hey, changes needed to be made. And so, they had to go back and add another, I think, it was another couple of days at least of development work to fix the concerns.
\n\nWe really don't want to go in and dictate stuff because the key there is helping people understand why we have concerns. And once we've had that conversation, oftentimes, people are like, yeah, that makes a lot of sense. And that's what we're shooting for is like, hey, we want you to understand why we have concerns. And what results from that is sometimes we change, but also, sometimes they understand why we have concerns, and then we can go in and explain the risks and have a discussion about timelines and things like that.
\n\nMIKE: And obviously, I asked kind of a pointed question [laughter] that reveals that it is costly to make changes to a design late in the process.
\n\nJUSTIN: Yes.
\n\nMIKE: And security isn't just some dust you sprinkle on a project [laughter]. It's an integral part of the way a structure is built, you know, whether that's in physical world or in software [laughs]. You can't say, "Oh, I'm going to build a building with no thoughts as to structural integrity [laughs] initially and then add that later." It's not something you can add later. It doesn't work that way. The security is built in from the beginning. And it's not just security, right? We bring up security as an example.
\n\nIf the review is the first time that important conversations are happening, I think it's a real problem. Building a little bit more on Eddy's question, you know, "It looks good to me," I think the ideal software development process, software development lifecycle, has communication early so that the review is there to have some dialogue, but it is a continuation of a conversation that was begun much earlier in the process.
\n\nJUSTIN: I think we're moving towards a, you know, what should you be looking for in a code review? And as a code reviewer, I mean, we have a couple of things. What should you do to prepare your code for code reviews? And what should you do? As a code reviewer, what should you be doing? If you guys haven't seen it yet, there is a really good example that Google gives. They have a paper that they wrote, a white paper, that has those two sections. It's like, what should I be doing to have a good code review? And then the other section is what should I do as a good code reviewer?
\n\nAnd if you haven't had the chance to look at that, go through it because I liked how it enumerated everything. It let me know what I was missing from both ends, you know, included things like, hey, is this performance? You know, performance is something you often don't think about that goes along with security; sometimes, you don't think about. But performance is like, you know, hey, it works for me in my development environment. And then you're like, somebody else who's doing a code review they should be aware of that. And, hopefully, their experience comes in and says, "Hey, you know, accessing this table this many times is going to lead to some issues," or something like that, so yeah.
\n\nMIKE: I fixed a performance issue during the winter, you know, Christmas time break. So [laughs], it's fresh on my mind and very much so. It's like security. You can't just bolt it on at the end. It's like, hey, we'll add performance now [laughs].
\n\nEDDY: Well, and, you know, I actually looked into that, too, when I came back, and it was really interesting because you could only replicate that in higher environments with a higher traffic count. And that's not as obvious, you know, when you're testing in a local environment, when you're truly in control of the data, right?
\n\nMIKE: Yeah, leaning on expertise and talking about that early is really helpful.
\n\nKYLE: I'm sitting here listening to this, too, and thinking through, and we're kind of saying it's hard or almost impossible to add it later, which for, like, performance and both security to the original product, yes. But I think the part that hasn't really been brought up is, so I'm thinking, performance. Yeah, if your app isn't performant, can you fix that? Sometimes you can't. How do you do that? You throw hardware at it. You throw money at it [laughter]. You get it fixed that way. [laughter] Same as security, right? You have to put another layer in front of it in order to fix your application.
\n\nSo yeah, I mean, I'm agreeing with you guys, but I'm like, it becomes exponentially more costly because how do you end up fixing it? If you're fixing it late in the game, you're throwing extra layers at it, which costs more and more money.
\n\nMIKE: There's a lot of these things that are pointing back to having these conversations early. And coming back to reviews, reviews are a conversation. It's intended as a venue for communication. And we may enforce it and say you have to do that [chuckles], but only because we've seen that it's so valuable. You know, somebody's making some work of art, and they want to bring it to somebody. They're trying to open a dialogue. They're trying to have a conversation. And that's what code reviews can really provide us is that conversation so that people are thinking and interacting together.
\n\nIf there's any antagonism or ego involved in there, it's very destructive to that process. It's just an opportunity to collaborate. And when embraced as such, I think it can provide a lot of value. But also, it opens up to this bigger idea that communication and bringing communication cycles earlier in the process is vital to quality software.
\n\nThere's another thing I've been thinking a lot about lately. Some years back, I don't even know how many years back, 20 probably, there was this document, the Agile Manifesto that was written. Some developers got together and said, "You know, some things in process tend to be bad, and some things tend to be good." And they wrote a document that said, "Well, this is better than this." And one of the better things, the things that's most important, is having those feedback loops where you have a quick cycle of information. You build something; you very quickly get it to somebody who can look at it and give you feedback. And then you make a little change then you quickly bring it back.
\n\nThere's an alternative way, which is you spend, like, a year writing documentation, and then you hand it to somebody and say, "Okay, go build it," [chuckles] And that doesn't tend to work very well. Maybe writing policies or [laughs] [inaudible 26:14] with documentation is hard. It doesn't fit very well. It's the way humans work. We work a lot better when we have something more tangible. Something we can look at, something we can talk about.
\n\nAnd encouraging that communication cycle early is really what code reviews are an extension of. It's an opportunity to have built-in feedback into the system so that you can get some feedback there. But it's not the only one, and it's important to not lean on that one piece. Sometimes, people hear, "Oh yeah, I want to be agile." And they think, I got to go get a book that says how somebody else did it and set up a process that follows that, you know, the diagrams they've got in the book.
\n\nThat misses the whole point of what the document was about. Maybe not all of the point, but a lot of it, which is that some aspects of process are better than others. And central to the process, a good process, is recognition of human frailties and human strengths. And those work best under a tight feedback loop with a lot of communication.
\n\nJUSTIN: And so, something that comes up often is, like, I've got a new thing, and it's hard to break down, and there's a lot of features on the new thing. How do I do incremental releases on the new thing and make it smaller? But I don't want to change the old thing until the new thing is all done or the new thing is ready to be released.
\n\nMIKE: I get it. I've got some answers I can throw at that [laughs].
\n\nJUSTIN: Sure.
\n\nMIKE: First of all, to your point about the old thing, I don't want to get rid of the old thing until the new thing is all ready. There's the temptation to think, okay, that means I need to go and build the whole thing, and then I'll have it tested. That's a really bad idea [laughs]. That's a really bad idea. To use a famous piece of hardware like the iPhone, I've never worked at Apple, but I extremely strongly doubt that they put together a completed iPhone, handed it to Steve Jobs, and said, "Okay, this is ready. Go present on it."
\n\nWhat they would have done is they would have had different departments building different components within that device, collaborating together, you know, figuring out the interfaces between them, and iteratively building that thing. Even though it wasn't released, they were internally testing. And, again, I'm guessing, but just knowing how software works, it's the only way it's possible. They would have been internally testing it all along in pieces and in gradually larger chains of components until the whole thing was put together.
\n\nSo, by the time the whole thing was put together, it had been heavily tested in end-to-end tests all along. Likewise, when we're building new things in software, you know, it's just one example. You know, we think it's physical, so it's a little more tangible. We should never think, well, this isn't going to be released, so I'm not going to bother testing it or getting it reviewed until it's all done. And this is the whole point of that communication loop.
\n\nThere's no reason you can't have a communication loop with your stakeholders, you know, people who've asked for it, whether that be product people in your company and, hopefully, even some beta testers out in the wild, some users who could be working with you and testing it. So, even though it's not going up to general release, you follow exactly the same process as you would otherwise. And then, when you're ready, you flip a flag and maybe move people over. At that point, you've gone through the process, just that we've talked about. You just happened to have done it with a smaller group.
\n\nJUSTIN: And you can achieve that smaller group in a variety of ways, like keep it internal. Keep it behind a feature flag. You know, have alpha testers, have beta testers. All of these things can help you. You don't have to have general release, but you still gain the advantages of iterative releasing.
\n\nMIKE: There's a longstanding practice in a lot of companies where they have feature releases, companies that are not yet doing continuous delivery, and sometimes that's imposed on you. If you've got, like, a mobile app, if it's going out through app stores, continuous delivery is hard [laughter] because you've got to get every change approved. So, there's an external constraint. The batch size is forced to be larger. And there could be a temptation in that environment to say, "Okay, well, we'll build everything for the next release, and then we'll get it tested."
\n\nBut best practice involves having a feature branch and be testing that. Treat that like your finished product and get your testing, get your feedback on that throughout the process so that when you finally get to that endpoint and ready for release, it's just a tag [laughs] almost, right? You're at a point where you know that it's already good.
\n\nEDDY: We've talked a lot about, like, why do code reviews, but I'm still kind of curious on how you would do a code review. And one thing that we actively practice, at least in the team that I'm on, is keeping the code file changes concise and below a minimum file change. And I think we've determined that that's easier to be more productive and find bugs if the code changes are small. I like that idea. I've seen other teams that do larger file changes, and, to me, it's sort of like, how the heck are you able to give a good review when you have 40 or 50 file changes in a single [inaudible 31:15], right?
\n\nMIKE: I would suggest you probably can't.
\n\nJUSTIN: Sometimes, you just have to hit approve. Is that what you're saying?
\n[laughter]
MIKE: At some point, you're going to have to press that button [laughter]. The clock is ticking. That's why you don't put yourself in that situation in the first place.
\n\nI think, you know, it's something Justin is saying. Preparing for reviewers, one thing you can do is not put a huge change; give them a huge change. Well, one thing I like to do is I like to put comments, not necessarily in the code, but on the pull review itself, you know, so kind of meta information. I'll go and I'll leave comments on my own code, you know, on my own pull request, and say, "Well, this is why I did this here. Maybe give this area some scrutiny. This is where some, you know, sensitive changes are." Or "This test was added," you know, whatever it is. I feel like that's really valuable, in my opinion.
\n\nJUSTIN: Should those be in the code review, or should those be actual comments in the code?
\n\nMIKE: I phrased that specifically because I think, I mean, arguably, they could be comments in the code, but some things I don't think are necessarily appropriate as comments in the code, that is, they don't make sense in the code. If I came back a year later, that comment wouldn't make any sense to me because it's talking about something that's not applicable in that context.
\n\nBut in the context of that change, it's very important, and that's where I think the value in having that kind of meta commenting, where, you know, you're commenting on the review, you know, on the change, the request, rather than on the code itself means that there's no artifact that's going into the permanent code from your changes. But there is, you know, that artifact that somebody can look at as they're reviewing to get some additional context. That's one thing that I think is helpful.
\n\nEDDY: Typically, when we add comments to code, it's because it's supposed to make it easier to understand. If you're adding comments to make it easier, does that imply that the logic for that code that you're making is difficult? And if that's the case, maybe we shouldn't be commenting, but rather, we should be refactoring it or breaking it down.
\n\nMIKE: I would agree with that. I don't know that I'd go as far as to say that comments are a smell, but I maybe come close. That code that requires comments is complex. Anything complex is hard to work with.
\n\nKYLE: I actually just started doing that. I started putting my own comments on my PRs, like, mostly on stuff that I'm not 100% sure of, like, stylistic and, like, team convention on how we like to do that. Like, I was just writing a validation for just a model the other day. And there was two options I could have gone with, a custom validator, or they have, like, built-in syntax you can do just, like, right at the top, whatever. And I was like, which would we prefer? What's the team convention on this? And I thought it was helpful. And also, explaining my thought process on how I thought this should be done. Is there a better way? That kind of stuff.
\n\nMIKE: And did you get some feedback on it?
\n\nKYLE: I did. Yeah. Very helpful.
\n\nMIKE: Exactly. You opened up a dialogue. You held up that olive branch and said, "Please." [laughs]
\n\nJUSTIN: So, one of the things that I've found really helpful is you are your own first code reviewer. And I think you were kind of alluding to that when you're writing comments in your own code review. When you create your code review, you need to go through and review it yourself. Look at all the file changes and everything. And I found that for my code, I catch all sorts of stuff [laughs].
\n\nSo, it turns out that that code review is really helpful for me to get it ready before I send it out to other people. So, don't be afraid to create a code review and label it as draft or something like that. And then, you'll be making more changes to it, but it really is helpful to see it in that code review mindset. It's almost as if you're wearing a different hat. You know, getting that different perspective just from yourself is really helpful.
\n\nKYLE: Yeah, like, I treat it like almost as if you're, like, proofreading an essay. Like, when you're first writing it, it's like, it might work. It might still be correct. But is there a better way to go? You know, you read back through your sentence, and you're like, oh, I'm going to put this verb at the end of the sentence to, you know, add additional emphasis to it, or anything like that. I think it's a good mindset to stay in.
\n\nEDDY: There have been times where it's been easier to express my concern with a pull request by just hopping on the call with that developer and be like, "Hey, instead of going back and forth, you know, on this pull request [laughs] that can span 20 or 30 threads long, you know, it's easier to hop on a call and elaborate what those changes are [inaudible 35:54].
\n\nThe problem with that, and I don't know if you all agree, is if I have that question, probably someone else who stumbles upon the code will have the same question. So, at what point do you move the conversation audibly versus having it traceable, you know, in a pull request so that it becomes easier for someone else? Because, at some point, it becomes documented.
\n\nMIKE: You know, I will do the same thing we've been talking about, and I'll leave a comment on the pull request and say, "Okay, we had this conversation." Or "Can we have this conversation?" So, another reviewer looks in and sees, oh, there's another conversation here that I don't know about. I can go ask about that. And I like to call that out for that very reason. If they don't know about it, then they can't take advantage of it.
\n\nJUSTIN: Having multiple different ways of communication that's just something that we're used to. Personally, like, I'll leave small comments on PRs when I know that people are working on other things. And they'll get around to it, and then they could just leave some insight. Obviously like, if it's a very long, heavy, big concept, then taking it onto a call or, like, a Slack chat, whatever, definitely would make it easier, for sure. So, I think it depends on the situation.
\n\nMIKE: The idea we've been talking about of communication being vital suggests that the channel is not as important as the conversation. But making people aware...it sounds like part of your question was saying, well, there's no artifact to this conversation, so nobody knows it happened. That signaling, putting some sort of signal, that's more communication. You're saying a conversation happened, and things we can do to signal to others that something happened, I think, are really valuable. It's being proactive, maybe not quite noisy, but providing lots of hooks for people to grab onto to know what's going on. It enables that communication to happen more effectively.
\n\nJUSTIN: So, that kind of leads into a question of what kind of comments should you be putting in there? There's different levels of comments. There's, like, a nit level of comment. Like, this is a minor thing, you know, consider putting this on one line or do this on, you know, maybe use a slightly different function like a math function or something like that. You have optional stuff. Clearly label it optional if something is optional. And then there's, like, the ones that are like, "Hey, I don't think this will work. Let's have a conversation offline," that sort of thing. What are the different levels that you guys put on there?
\n\nMIKE: I think you left out another one that's actually as important, if not more important. Like, "Hey, this is great."
\n\nJUSTIN: Yes. Yes, I did [laughter].
\n\nMIKE: That sets an atmosphere. It sets a tone. You know, going back to music, you know, I like that riff. What if we change the rhythm? It lets people know that you understand the algorithms. You understand the big picture, and you really like what's going on. So, they have that framework, you know, that scaffolding to hold on to. It doesn't sound like I'm coming here to say, "Your code sucks." That's a miserable experience for everybody. So, I would add that to your list, although I think your list is valuable.
\n\nYou know, there's different degrees, and I think that it'd be nice if there was, like, color coding or something so you could say. But, you know, there's verbal cues you can give like, "Oh, this is not a big deal. This is a style thing. This is important. Please let's talk about it. But also, you know, I like what you did here. This line is beautiful. I really like how concisely you wrote this."
\n\nI think those comments...and you might think, well, I don't need to put those. That doesn't change the code. It isn't going to change anything. Well, it is changing something [chuckles]. It's changing the perspective of the person who wrote the code so they understand where you're coming from.
\n\nEDDY: I don't even shy away from leaving a comment being like, "Can you explain what this does? This is pretty ambiguous. Can you elaborate what your intention is?" Because, at the end of the day, the one that's stamping the approval is me. So, like, if I feel unconfident or unsure about that change, I don't shy away from that. And I typically tend to be, like, the straggler.
\n\nJUSTIN: So, what do you think about, you know, suppose you do have, like, a comment, like, you don't think this will work. Have you considered, like, do you add additional stuff, like, have you considered X, or have you considered Y?
\n\nMIKE: And code examples are really nice in that context, where X has some actual code written out, you know, maybe it's pseudocode, but, you know, it lays out an idea. It's a whole lot easier to talk about something that is concrete.
\n\nEDDY: Okay, can I just preface and go on record and saying, hey, I really love it when someone says, "Hey, I think it would be better this way," and they provide a code block. And like, "This is how I would think this reads better." Oh my God, like, how helpful.
\n\nMIKE: [laughs]
\n\nEDDY: Because then not only do you understand what they're trying to get the point across, but you can see an example of what they meant. I love that. And it takes, what, like, an extra two minutes or so to pseudocode, like Mike was saying.
\n\nJUSTIN: I kind of want to go back to the format of code reviews. I mean, the ideal situation is that you're a developer, and you want to go sit down with somebody else, and you are sitting there with them. And they review your code face-to-face. In the ideal world, that'd be awesome, and you can have a conversation face to face. But we can't often do that because of, you know, time zones or, you know, we all have different things going on that we're working on.
\n\nAnd so, code reviews are there to make that experience as close as possible to that experience. And whatever you can do as a code reviewer to make that experience happen, I think, is a good thing. And so, being very clear and being verbose, maybe not too verbose, but being very cognizant of how the other person looks and feels, and what their situation is, and things like that. All that comes into play while you're doing this code review, and they're not sitting there right next to you.
\n\nEDDY: What's everyone's opinion on paragraphs being left as code reviews throughout the whole code?
\n\nJUSTIN: Wait, a whole paragraph? Like -- [laughs]
\n\nEDDY: It happens. Like, what's your opinion? Because you have, like, ten file changes, and, like, on each file, you have, like, a paragraph that's being written on, like, the gravity of that change [inaudible 42:06]. It doesn't happen often, but it does happen. Like, at that point, do you find that disruptive, or do you find that a bit overwhelming? Like, I'm kind of curious.
\n\nJUSTIN: I don't know. I've never really had that much [laughs]. My initial thought would be like, oh, that's a lot. But I don't know, have other people had that experience?
\n\nMIKE: I'm thinking of one reviewer who tends to leave long comments like that.
\n\nEDDY: [laughs]
\n\nMIKE: And my default answer is going to be, wow, you cared enough to give me all this information. Thank you. It might take a little bit of time, but that means that they respected this interaction enough to give it that much attention. Somebody doesn't do that unless they care.
\n\nKYLE: At times, I'll run into situations where I want to leave a paragraph.
\n\nMIKE: [laughs]
\n\nKYLE: And in those boats, I don't want to make the individual feel uncomfortable because I feel like when you do that, it's a bit of a, like, hey, change your world, change everything you're doing type of feeling when somebody comes at you like that. So, I prefer to take those offline and, like, do a direct message with them, kind of work through it a bit, and then come back with a smaller comment. That's my approach. I have had people leave those larger paragraphs, and I just know I personally don't feel great about them most of the time. So, yeah, that's what I've done.
\n\nMIKE: We've been talking a lot about keeping your audience in mind. It matters. Yeah, I think having a mental model of who you're working with and being respectful of them can make the process go a lot smoother.
\n\nKYLE: I do feel like the quicker channels like Slack or Teams or whatever you do, something with a communication turnaround, it's a little bit easier to avoid miscommunications as well than back-and-forth communication on a PR. So, that's what I mean when taking it offline, too.
\n\nMIKE: It's a lot easier to have a conversation, a verbal conversation, than to have somebody write ten paragraphs [laughter].
\n\nEDDY: And maybe you can take it a step further and do it in person.
\n\nJUSTIN: Yeah. And actually, one comment and then one kind of moving to the next level. Yeah, like I said earlier, it's always, like, whatever you can do to convey your intents in a clear manner. Sometimes that is just a single line on the comments, or sometimes it is, like, you having to sit down because it might take you a little while longer to get your intent across. And then, like you said, Mike, it's really important that you understand your audience.
\n\nAnd then, the next question I have, if we were to take this kind of where we're leading, is how do we handle pushback in code reviews? Suppose somebody comes in and says, "Hey, you need to do it this way [laughs]. This is the way." So, how do you handle that sort of situation?
\n\nEDDY: I've gotten pushback so far as people will request code changes without even, like, approaching me directly regarding their question. [inaudible 45:08] just sits there [chuckles]. You're just like, ah, like, I could have explained it had you just messaged me directly versus, like, abrupt request code changes. But I'm typically pretty open.
\n\nI was told pretty early on, actually, by a lot of people who mentored me saying, "Hey, don't be married to your code." And I live by that. I really do. I'm super early in my career, so if someone suggests something, I'm like, it's for a reason. Like, they've probably been through the same pain point, and they're trying to save you the heartache, you know, having to deal with the same thing they did. So, typically, I'm pretty open, and I'm pretty flexible. Very seldomly do I push back and be like, "But this works, and it does the same thing." Very rare. However, nine times out of 10, I typically say, "Oh yeah, that does look better. That does read nicer."
\n\nMIKE: Sometimes there are team conventions that you can point to, and if, as a reviewer, I say, "Well, this is our team convention," and there's justification there. You can point to an example and say, "Well, this is why we should do it." That sounds different than somebody coming and saying, "Well, no, I hate your code. You should do it my way." One of them is conscientious. It refers back to the standards that you've developed as a team. It ties back into the consensus. And the other one is very egocentric. Like, well, this is just all about me and my perspective.
\n\nAnd I think that both as a reviewer and as a reviewee, keeping those ideas in mind matters. The code is a group product. And if we can build the team, then we should try to do so. And it's not really about us personally, and if it is, then you're ejecting yourself, right? Then that is actually not valuable for the company probably. You've brought something that's not valuable to the company, and you're just bringing your own baggage in. You know, and we all have our own things that we're working through, but trying to avoid that where possible, both as a reviewer and a reviewee, I think, smooths out the process, not just in code reviews but in life [laughs].
\n\nEDDY: Do you ever find yourself approving code before it's ready, trusting the person that they're going to go in and actually update what you recommended? Let me take that a step further. Let's say you say, "Oh, this looks good. I recommend these changes, but are non-blockers." Like, do you find yourself approving PRs like that, or do you sit back and wait for them to make a change?
\n\nJUSTIN: You just said that it was a non-blocker, so why don't you approve it?
\n\nEDDY: All right. Because, like, I've seen, like, feedback where it's just like, oh yeah, like, I'd recommend doing it this way, but I get it, non-blocking, blah, approved. Like, do we feel good when it comes to doing approvals like that, or do we prefer to [inaudible 47:47] upon that and only approve it only after you feel really good about the change?
\n\nMIKE: There's some people who I know if I left that comment they're going to go back and make the change. I made a comment like that on a review probably a couple of months ago. You know, the coder went back and said, "Oh, you know, that was a really good idea. [laughs] That could have really simplified this." They went back and made the change. And I saw that in my email a couple of days...I was like, oh. [laughs] I didn't get a chance to get back to it, and they totally made the change. And I know that that, you know, that person would do it.
\n\nIf I'm working with somebody who is just getting started and they're kind of overwhelmed [laughs] and they don't know what to do, then I'm probably not going to approve it, not because I don't approve of them as a person or, you know, of their ability generally but just because you've improved the process to give them a chance to make those changes. It depends some on the audience.
\n\nKYLE: It made me kind of think whenever I'm doing a review, I try to keep the audience in mind in the sense that do I know this individual? And if I don't know this individual, what is their background? There will be times when I'm either recommending a change, you know, and how much detail I will go into sometimes I will take into consideration their level in so much that if I'm not aware, I've gone into our directory and seeing, like, what level of the chain they are, you know, like, are they a software 1, 2, 3 type thing, you know.
\n\nAnd if it's a more junior individual, I will take the time to elaborate more or reach out to them. If they're more of a senior individual, I will take more of those, I guess, shorter routes where it's just kind of a quick explanation, kind of expecting that they'll take it and do what they will with it. That's just me, but I tend to do that route.
\n\nMIKE: You know, and this recurring theme of knowing your audience maybe is a good point to kind of conclude this session. We started talking about music and art and getting feedback. They say when you're making YouTube videos, don't read the comments [laughs] because we know the internet is mean. There are people that you actually care about and trust that you want their feedback. And code review is an opportunity to get that, you know, it's an opportunity to collaborate with people that you want to collaborate with generally. You can get advice on how to make a better product.
\n\nIt's part of a broader culture of communication. In isolation, it's probably not going to help you very much [laughs]. You can't stick that security on at the end. But as part of a broader culture of tight communication loops, it can expand the communication in a really healthy, productive way and result in better code.
\n\nThank you, everybody, for participating today. Any final words?
\n\nJUSTIN: Let me put my security hat on. Check your security issues while you do a code review. All right, now I'll take it off.
\n\n[laughter]
\n\nMIKE: Thank you. [inaudible 50:36] for us next time on the Acima Development Podcast.
","summary":"","date_published":"2024-03-13T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/37f9ad43-2b8a-4fb8-b18b-ae25b5a4a159.mp3","mime_type":"audio/mpeg","size_in_bytes":32241513,"duration_in_seconds":3048}]},{"id":"b7e6df1d-3975-4c82-b5fc-0af26b9b5336","title":"Episode 40: Git","url":"https://acima-development.fireside.fm/40","content_text":"The podcast begins with Mike sharing his fondness for smoothies and drawing an analogy to Git, a distributed database. He compares the irreversible process of making a smoothie to the irreversible nature of operations in Git. Mike explains that Git, emerging from the same project that gave us Linux, is a distributed database that allows information sharing and verification across geographic regions. He highlights Git's significance in facilitating collaborative development in large-scale projects like Linux.\n\nThe discussion then shifts to the technical aspects of Git, such as dealing with conflicts, the concept of a distributed repository, and the uniqueness of Git in managing changes and time. Mike elaborates on the cryptographic operation called hashing used in Git, emphasizing that changes in Git represent patches or differences rather than versions of code. The panel discusses Git's ability to handle vast numbers of contributors and the significance of timestamps and commit hashes in tracking changes.\n\nFinally, the conversation delves into the practicalities and best practices of using Git. The team discusses branching strategies, the importance of not rebasing shared branches, and the impact of different deployment strategies on Git usage. They also touch on the challenges of merge conflicts and the importance of understanding Git's limitations and strengths. The episode concludes with an acknowledgment of Git's ubiquity in various fields beyond software development and encourages listeners to familiarize themselves with Git for collaborative projects.\n\nTranscript:\n\nMIKE: Hello, and welcome to another episode of the Acima Development podcast. I'm Mike. I'm going to be hosting today. With us, we've got Eddy, JP, and Kyle. Great to have you all here today.\n\nAnd, as usual, I'd like to start with a bit of a story. And I'm actually going to talk about my breakfast this morning. I have become a great lover of smoothies [laughs]. Years ago...I enjoy them. I've always liked a smoothie, but they never really were enough. I have a lot of appetite. I was a huge eater as a teen. I was late getting my height, so I grew a foot in a year [laughs]. That left me skinny and hungry [laughs], and I also ran long distance. So, huge appetite in my teens. You know, I still don't have the same appetite as I used to have, but, you know, I still like to eat enough. And something like a smoothie for breakfast was never enough. \n\nWell, I kind of by accident stumbled on a combination that scratches the itch [laughs]. I put a lot of seeds in it, and that gives the fat and protein it needs to keep things good, and then lots of whole fruit. I don't even throw juice in anymore. So, I just use water to add enough liquid. That means that I am getting all kinds of fiber, and I get the fat and protein from the seeds. It means that I stay really stable with my blood sugar. It's fantastic. I love it. \n\nSo, I throw together all these ingredients in a blender, you know, I add the water and blend it. One thing that I have never tried to do is put the fruit back together afterward. And there's a reason for that, and it is that it's effectively impossible. I mean, technically, you could pull apart all the molecules, right? And reconstitute them. But there is no way in a meaningful amount of human time. And I think it would all have rotted by that point anyway, right [laughs]? \n\nThere are some things that only go in one direction, and a smoothie is one of those [chuckles]. You press that button to get it going, and that's the end of that fruit. It still tastes good [chuckles]. It's still valuable. It's still valuable. But it only goes in one direction. That actually applies to several aspects of what we're going to be talking about today regarding Git. \n\nGit is a distributed database, and if you're not familiar with, you're thinking, well, why would I need a distributed database? It's like listening to your friend, who is a huge Bitcoin enthusiast. We all need distributed databases. Unless you're an enthusiast, probably your eyes glaze over [laughs], and you forget about it until the next time your friend comes over. But it's a similar sort of thing. Most of these cryptocurrencies are built as a distributed database so that you can have information shared across geographic regions and be able to verify that data is not corrupted. That's what Git is. There's a few reasons that it is what it is.\n\nNow, Git was spawned by the same project that gave us Linux, the operating system that powers, like, most of the internet [chuckles]. If you've got an Android phone, it's running Linux. If you've got some cars, I think Tesla runs Linux, you know, Linux runs kind of all the things—most of the servers, not all of them. You have some Windows servers out there, some old Unix servers, but a lot of the [inaudible 03:19] are on Linux. \n\nBut a long time ago, it was just some guy, Linus Torvalds, who wrote a project where he had an operating system in college, and he released it open source, released his code to the internet. And people actually started using it, and they started contributing to it. And pretty soon, it was this worldwide project where you have thousands, potentially, of people who are all contributing to this project. And sometimes they're going to make changes in the same files. And there were systems for managing that sort of thing in the past, but they all had a few problems. \n\nFirst, dealing with conflicts was a pain [laughs]. And there's a few ways to deal with that, but you need to recognize that conflicts are a pain. And they are especially a pain, and to go back to my smoothie, they are especially a pain if you have to have some sort of shared state. If you say this is the perfect state of the repository, this is how my code is and that everybody has to work with that version of the code, well, if you have 1,000 people working on the same thing at once, it's pretty much impossible to actually have a shared vision of what that thing is. So, that is a serious problem. \n\nIf you have a whole bunch of people trying to make the smoothie at once, it's even worse than it happening in one place. Well, Linus Torvalds had an idea to change from the way things were currently working, where he said, you know what? We're not going to have a central version. There is no such thing as a, you know, single, canonical version of what our code is. You can all code separately, and it's fine. And we're just going to let time move forward. And what the pure, true version is, is just whoever the person in charge says it is, who has their copy of the code. \n\nAnd here's the other place where the smoothie comes in. This idea of time only moving forward matters. There's an operation, a cryptographic operation, called a hash where you take some data, and you can do some mangling on it, and you get a number out the other end. And you can't go back the other way. There's a few different ways of doing it. There's a popular algorithm, the SHA set of algorithms, that is used to do this hashing. And it's really all it says, you know, hash means to scramble something up. It's basically what I'm doing with my smoothie. You can do it with vegetables [chuckles]. Once you've shredded something up, you can't go back the other direction. \n\nSo, this is the other key thing that Git does is that anytime somebody makes a change, it makes a hash of that change. That is, it runs this mathematical operation, takes all your changes, and comes out with just a number on the other end, a long number. And that number is pretty much going to be unique. The chances of it being the same as somebody else's numbers that they hashed is essentially zero. \n\nSo, you can have people all over the world making their changes and then creating these hashes, and the hashes are all going to be different. Together with that hash, you have a timestamp. And each of those hashes is associated with a change, and the change is not a version of the code. And here's another key thing to note: the changes represent a change, that is, a difference. They represent a patch or a this is what we're going to do to change the code. \n\nSo, what you end up with is this database distributed across any machines. You can have thousands of people. They could be working for months separately, come back, and they have this list, you know, this set of changes. Each of these changes has a commit hash associated with a unique number you can identify with and a timestamp. And each of these also represents a set of changes that's going to be applied. As long as you can apply those changes, it really doesn't matter if you don't have a central version, just [inaudible 06:47] the changes. \n\nAnd you can imagine sometimes it doesn't work. And that's what we're going to get to a little bit later today is dealing with some of those times when it doesn't work. But the fact that the time only moves forward, that is, you always have to apply changes; you're not going back to some central vision of what the code is. It means that everybody can work separately, and it's just fine.\n\nWhat you decide to deploy here with Linux is whoever is in charge of the project says, \"Hey, this is the version that we're going to go with.\" And you think, well, how do you know? Well, you know, you probably have a human problem there [chuckles]. That is, we have human structures to deal with governance, so use those human structures. Let the people decide and designate somebody who is going to say, \"Okay, this is the version that we're going to go with.\" And if you have that person, she or he can say, \"You know what? This is good. I give it my stamp. We can deploy this.\" \n\nAnd then you can have people working separately, and they can contribute to it on their own time by removing that need for a central figure and by giving things, you know, these unique handles so that, you know, everybody can verify that the change is unique. And by allowing time to only go forward—you can only make changes—then you can solve a lot of the problems that we had because there were systems before. Did any of you use some of the systems we used before Git, and how did that go for you?\n\nEDDY: Well, honestly, for myself, I'm pretty new [laughs] to development. So, the only version control that I know is Git. I'm no stranger to previous systems, you know, that were used in the past. Like, out of curiosity, I did look up on, like, what Git was, and I looked at the timeline and what other features they were. I read about, like, RCS and SVN, et cetera, which pale in comparison to what Git is.\n\nMIKE: Kyle, I think you mentioned you used CVS back in the day. \n\nKYLE: Yeah, I was quite junior. I don't remember a lot about it. The one that I would know the most about, which was just that it was always down, was, like, our SVN when I was at a C# shop specifically. It was great when it was working, but it seemed to stop the ship anytime there was a major error. It seemed to stop the ship pretty dead center when there was a conflict, which was always just a hassle to get through.\n\nMIKE: And you hit on something. It was really hard back in the day to try to manage this using the tools that were there. But those tools were a big step forward from what you had before because if you don't have some sort of tool for [laughs] managing, then you just got your code on your machine, and you email it to somebody, right? And then, they try to figure out the differences and hope they get it right. That's not a great way to do things. Really, that's what you had before we had some of these tools. \n\nSo, while it may sound like we're casting some shade on Subversion or CVS, that doesn't mean that those tools were not incredibly useful and a huge step forward from what we had before. But once you have to have a central, a central repository to maintain, then you have a single point of failure. And a single point of failure is not so fun to deal with.\n\nJP: I guess also want to call out as well that Git is not the last iteration as well. A lot of people will talk about Git. We have all these beautiful tools that have emerged in the technology industry to work on top of Git. I mean, the foundation is still Git and a lot of these other tools like Subversion and CVS, but really, Git just laid a foundation, like you said, with distributing that data and using, you know, the mathematical computation of hashes to be able to empower this extremely large distributed network of code and make it publicly accessible, which was something that really wasn't there before.\n\nEDDY: Wait, Jackson, you said that it's not the end all be all. So, are you saying that there's other version controls currently that are newer --\n\nJP: Not other version controls, but systems leveraging Git. So, I know at Acima and at a lot of [laughs] organizations, the world depends on GitHub, for example. GitHub itself is a version control system that relies on Git but adds a ton of additional features on top of that system.\n\nMIKE: Right. It's another layer on top of it. When you think about a database, releasing a database to the world is awesome, but not very many people are going to say, \"Hey, I'm going to go hit PostgreSQL today.\" But they might say [laughs], \"I'm going to go visit Facebook,\" right? [laughs] And that layer on top matters with GitHub, or GitLab, or Bitbucket, or, you know, there's any number of different versions out there. I'm not trying to say that one is the best. They add another layer on top, so you actually have an application that runs on top of that distributed database down beneath.\n\nJP: The big call out kind of, Eddy, to respond to that, is, like, what does GitHub give that Git doesn't by itself? Right off the bat, the biggest feature that I guarantee that most people would agree on is pull requests or merge requests, the concept of that. That is not something that comes with Git by itself.\n\nEDDY: But that is available with other version controls, right? So, I'm sure GitLab does something similar to that. \n\nJP: Well, absolutely. GitHub, GitLab all of those more just systems leveraging Git provide that functionality. But Git, by itself, if you're just hosting your own Git server, it doesn't come with that functionality. \n\nMIKE: And Git is the database. \n\nJP: Yes.\n\nMIKE: Git is the database, and the database is not going to give you all the social interaction tools that these applications provide, this idea of a pull request or a merge request with reviewers, what all that you have in there, your descriptions, all of your workflows.\n\nJP: Status checks, yep.\n\nMIKE: Yeah, that isn't provided by the database. The database stores the changes to the code, but it doesn't manage any of that social interaction, and that's by design. You know, it's a tool that's designed to be the database, not to manage that social interaction. That's an important thing to recognize.\n\nEDDY: That's interesting. I never thought of Git as a database. But putting into perspective, I think it actually makes sense in hindsight. \n\nJP: And I guess kind of to, like, layer on top of that, Mike, if you don't mind, we have Git as the database. But there are a lot of other...like, we talked about GitHub, GitLab that leverage that database. But the day-to-day, again, even when developers are working with Git on their systems, they're not working with the database directly. They work with the Git CLI. And there's other alternatives to that as well. So, a lot of people think that Git CLI is...that's it. That's the thing doing my version control. No, it's that combined with the database technology underneath that really gives you that full functionality of Git.\n\nMIKE: That's a really good point. We interact a lot with that command line interface, right? You know, all of the command line tool that Git provides for us or maybe use a graphical tool to interact with that. \n\nJP: Yeah [laughs]. Yes. \n\nMIKE: And a lot of people do. But that itself isn't the database [chuckles]. Having those tools for writing the database are important. You [chuckles] don't want to corrupt your database, and then you've got an even bigger problem [laughs]. It's probably been done, but I strongly doubt that very many people have ever written their own data to that database by hand. They use an automated tool to do it.\n\nEDDY: I actually have a question. And, again, seven months full-time development, so I'm still pretty new to the concept. Git, since it's a database, does it store all the repositories for a vast majority of the companies that use -- \n\nJP: Oh, good question, though. Good question.\n\nMIKE: Let me answer that question with a question. Do the databases you use store data from Facebook, and why or why not? So, for your application, say you're using PostgreSQL, do you and your PostgreSQL database store data from another company? \n\nEDDY: Probably not.\n\nMIKE: Probably not. But they may also be using PostgreSQL, right? \n\nEDDY: Right.\n\nMIKE: So, PostgreSQL is a technology that can be used to create a repository for storing data, but it isn't itself of that repository. It's a technology for creating a repository. So, there are, you know, millions of entities out there that have a repository, but that doesn't mean they all have the same one in Git or in any other database. There are many repositories out there, many of which have nothing to do with each other at all. \n\nAnd thinking about this being distributed, we can all have separate repositories, and that's fine. But many of us have repositories that we connect to each other so that we can have some sense of shared direction and code and data, maybe, I should say. Because it doesn't necessarily have to be code. I've used Git for things other than pure code.\n\nJP: [laughs] And I guess to kind of follow up on that as well to kind of answer it, just using GitHub as an example, and I guess most major version control hosted solutions, each project or set of projects that you're working on usually gets written in its own Git database, its own...what they call a Git repository. That is the terminology for it. So, a lot of organizations, or bigger companies, or even just large projects will have many Git repositories that are all tracked in separate Git repository databases, not in the same one together. \n\nEDDY: So, where does the code get saved then when you push up? --\n\nJP: Oooh, another good question. In that case and, Mike, please, yeah, please bounce off me. Using a provider like GitHub, they're actually hosting a Git server. That's another piece of the Git technology stack, Git repository server that will receive the requests of the commit hashes that you're changing and the associated data, and they will store it on their side.\n\nMIKE: Remember when I said earlier that you designate somebody to be the person to say, \"Hey, my repository is the one that matters?\" We've elected to let GitHub...I say we, you know, anybody who chooses to use GitHub generally elects to use GitHub as that gatekeeper. And we've chosen their copy of the repository to be the one that's in charge, but everybody else has a full copy. Anybody who works with that data has the full set of data. \n\nGitHub is not special or GitLab, you know, you name it. We'll use GitHub today. They're not special. They could go down, and the world would be okay [chuckles]. You wouldn't because [laughter] [inaudible 16:48]. But we wouldn't lose everything because everybody else who's ever used that code would also have all of that data. You're pushing data. You're just syncing your data to that other repository, but you still have everything else. You're just pushing up a few little changes. Really, you're just pushing up those few commits, those few little chunks of changes with their hashes, and not everything. You're not pushing up the whole repository. You're just pushing up the changes that you made to your own branch. \n\nWe didn't mention branches before, but it does allow you to have...it has this idea of a branch in Git. So, you can say, \"Oh, you know what? I'm going to make a copy over here.\" And it's really lightweight. You're not actually copying over all the code because the beauty of this distributed database is you're just making a set of changes. So, naming a set of changes is no big deal. It's just, what, one name [chuckles]? The overhead for that is extremely small. \n\nSo, it's really easy to create a new set of changes [inaudible 17:43] go off in your own direction, and you can throw it away. Or you can bring it back here and say, \"Hey, you know, I'm going to bring these changes in,\" which actually brings us to a point that we said we'd talk about is what does it mean to bring changes in? What does it mean to merge branches? And there's a couple of different schools of thought on how to do this. \n\nLet's say you've got a branch of code. It's just the history, right? It's just a series of changes. You can call them patches, commits. Here's the change that's going to be applied. Here's the change that's going to be applied next. Here's the change that's going to be applied next, from zero up to infinity, right? It's just an endless set of changes that are applied. And if you have two people who've been working separately for a while, you can merge those. And as long as you haven't been changing the same files, then it'll work, right? They'll be interleaved. \n\nYou'll have one person's changes, and that person made another change. Then the other person made a couple, and then the first person made a couple, and the other person made one, and the other person made one. You'll see it coming in from one person and the other person and one person and the other person. If you look at the history, you'll just see that history of when they made those changes. Each of those changes represents a change to what happened before. \n\nAnd if you're thinking about reading the history, if you want to just know when they made those changes, well, that's a reasonable way to think about it. But I will say that that's not usually what you care about. What we usually think about is in terms of something more like a feature. And the way that people usually use Git is they have a branch where they build out a feature, and then they want that feature to come in. And if you wanted to go through the history and see how that feature was built, you'd have to go through and see all the little changes interleaved with everybody else's changes. \n\nSo, there's another school of thought that says when you're merging, you shouldn't actually do this [inaudible 19:18] what we call a merge, where you just throw all the changes in where they were made. Instead, you go through a process, first, of rebasing, and rebasing actually means more than one thing. It's a bigger tool, and, hopefully, we have time to talk a little bit more about it. Think about that word means base and rebasing means you're redoing the base [chuckles]. \n\nSince our changes are just a series of patches, I'll make this change, and this change, and this change. Usually, you're making those changes thinking about starting back whenever you branched off of the code originally. But you can change that. Git will allow you to do so and say, you know what? Instead, I'm going to branch off of where the code is now on my local version, you know, grab the changes or, you know, or even off a remote version. \n\nI'm going to branch off of this specific commit. Remember, they're named. They're named with this big number, this hash. Say, \"I'm going to branch off of this hash instead.\" Then you can do a couple of things. You could either squash all your changes down to one big change, and then you've only got one big change [inaudible 20:11] for your feature. Or you can just put them all in together, but they're all sequential. Then, if you go back through your history, you see a series of the sequential changes for one feature, and then a series of sequential changes for another feature, and then a series of sequential changes for another feature. And it makes it much easier to read. \n\nSo, here's the two schools of thought: the hey, just merge it in. It's the easier way. I say the easier way; it's the more simplistic way. It's kind of the default. \"Hey, I'm just going to throw my stuff in there. I hope it works,\" way of doing things. And then there's the rebasing approach, which says, you know what? I'm going to try to be very polite and put my changes all in one nice, little tight bundle so that people can read it later. It does make the history a lot easier to read. But it also means you got to get everybody else on board. And it also means that you're rewriting the history because you're changing your local branch to be starting from somewhere else. \n\nAnd if you have anybody else collaborating on that local branch, you're going to do them a world of hurt when you do that if they try to pull those changes down because it's going to say, \"This doesn't match my local version. The history is rewritten.\" What happened in the past? I don't know anymore. The world makes no sense. And [chuckles] they're going to have to decide what the true history is. There's some downside to collaborating within a single branch when you follow that approach if you're ever going to make changes after you've done a rebase.\n\nJP: I guess kind of to, like, to step backwards as well, like, simplify what all that really comes down to in Git terminology because these words get thrown around a lot, is you either have a merge commit, which that happens during the Git Merge process, and that's that default mode we talked about a second ago, just merging in the history. And your changes get globbed on top of each other, not maintaining the actual linear history of changes. \n\nOr there's rewriting the history, which is actually moving your commit hashes around and potentially resolving conflicts, which is maybe something we can talk about as well, in order to create a new linear history that more matches the actual timestamp of when those changes happened, even if they were on separate branches and time. \n\nThere are definitely, like Mike mentioned, benefits and drawbacks to both approaches. And, you know, it can be a very opinionated thing. But it really depends on, do you care about how your code was put together? And do you want to see the changes in a clear, fashionable way that can be audited according to certain standards? So, hopefully, that's another good way to reference that. \n\nEDDY: Let me ask you this, then, when you roll back, where do you reach out to? Do you use Git as a tool to roll back, or do you use the [inaudible 22:37] to roll back? \n\nJP: That's a really complicated question because that really depends on what rollback means. Yes, that can be part of what they call the GitOps process, you know, doing events based on changes to a Git database. But that's going to depend on organization from organization [chuckles]. It's not necessarily related to Git. It can be, and a lot of organizations choose to do that. But yeah, that's a large discussion [laughs]. \n\nMIKE: Well, you hit on something really key that I tried to talk about with my smoothie [laughter] [inaudible 23:08]. Git doesn't have a rollback. It has no such concept, and that is by design. Time can only go forward. Once the smoothie is made, you can't put it back together. Git only has the idea of a revert, and a revert does not undo anything. And this is critical. This is, like, a really important thing to understand: A revert does not undo anything. It does the changes in reverse because time might have gone on, right? \n\nLet's say that ten people have put new code into the repository that you've decided to centralize on after you made your changes. What would rolling back mean? Getting rid of all those changes? Getting rid of some of them? Doing some sort of rebase where you put other people's stuff on top of yours? It's ill-defined. It's not a well-defined problem. And Git has decided that there is no answer to that problem. \n\nInstead, when you're undoing your changes in Git, it just applies your changes in reverse. And then, when you go to try to merge them in, they might not work. You might not be able to go backwards anymore because things have changed. And you're going to have to deal with the conflicts because, again, time only goes forward. \n\nJP: This even occurs, let's say, if you wanted to delete history. The same concept happens in Git if it only goes forward. Yes, you removed, or you rebased, is really what the terminology is, your history of commits. There's a mark in time that a rebase occurred there, and it's by new commits. The new commits come in, and that is only going forward. You can never really return back to that location that you were at before.\n\nEDDY: Wait, but if you're going back, right? And it does it in reverse, like, how does it have context of all the code that's been merged since? \n\nMIKE: It doesn't. It doesn't at all. It has zero. \n\nJP: It only has context of what files changed and what lines and where. So, it just tries to repeat the previous commit or two or how many you've chose in reverse.\n\nMIKE: And it might conflict with those changes that come afterward. It lets that set of changes be no different than any other set of changes. It's just a set of changes going forward. That's a key distinction that makes Git special. It actually makes it easier to use. It's weird to think about because we like to think about, oh no, there's this pure, true version, and I need to go back to that version. \n\nJP: [laughs]\n\nMIKE: But no, there is no such thing in Git. There's only time moving forward.\n\nJP: And it's also kind of on that same vein; a lot of people usually take a moment in time in Git and turn that into some type of artifact that's this code in this point of time, but it is not Git where you're making that decision. It's where you package it up and put it somewhere else. \n\nKYLE: So, basically, you can...the idea of rollbacks, or whatever, could only be possible with an actual binary.\n\nJP: A binary, package, artifact, whatever you call that, but that comes after exactly the Git process.\n\nMIKE: But you can copy out a version, right? \n\nJP: [laughs]\n\nMIKE: And then later, you can go back to it. That's not Git doing so. That's a choice outside of your database, you know, outside of your version control.\n\nEDDY: I feel like having an analogy of what Git is would really help. While we were talking, I looked up a more simplistic way to think about what Git is. The repository is like a storybook, and the pages in that book are the files. The writers are the developers. Changes and additions are the commits. Book's memory is the history. Going back in time is the version control that we were talking about. Working together is collaboration. And then sharing the book is the remote repository. Would we agree, in essence, that that's a fair way to do a comparison?\n\nJP: Yes and no. \n\nMIKE: Digital book? Yeah. \n\nJP: [laughs]\n\nKYLE: I was sitting there thinking with Eddy's comparison there; I'm thinking back to all of my college books, right? And it almost seemed like it does work pretty well there. The revisions of your college books they don't change a lot. But they might fix some wording, and they might fix a few quote, unquote, \"bugs\" here and there. But they don't revert back to anything. They have to release a new version, regardless of what they're doing. \n\nMIKE: Yeah, that's true. You can only do revisions forward. Once it's out there, you can't get it back. \n\nJP: Great point. \n\nMIKE: One thing we haven't talked about...we've talked about this idea of rebasing. We've talked about merging. We haven't talked about what happens when it doesn't work. \n\nJP: [laughs]\n\nMIKE: And yes, that will happen to you today if you [laughs] are just starting using Git because it does happen. Although if you use a very responsible and different ways to go about this, you know, if you have a very careful process...and I would strongly advocate for continuous delivery. Thank you, DevOps. We've got some DevOps people here. Thank you so much for making our lives better [laughter]. \n\nIf you make lots of small changes, you're less likely to have a problem. If you make a few huge changes, you're almost certainly going to conflict, and it's going to be painful. Sometimes, you're going to make a change in the same place somebody else did, and there's no way to get them in alignment automatically. That's what we call a merge conflict, and Git doesn't solve those for you. It instead gives you both versions side by side and lets you decide. \n\nAnd sometimes, the answer is to pick one. Sometimes, the answer is you pick the other, and sometimes, the answer is you have to somehow make them work together [laughs] and combine the two. And this is inescapable because, yeah, you both change the same place. You're going to have to deal with that. And no, there's no magical system that can address that. So, instead, it just makes it easy. It says, here are your two versions. Go ahead.\n\nEDDY: It's harder to resolve, or it's more common to run into when you have a larger team working on the same codebase.\n\nMIKE: The number of people working in the same files is really the same thing. You could have two people working in the codebase working on the same file and have it happen a lot. It's the people working in the same part of the code that really gets you.\n\nJP: I guess to call out that distinction as well, what is Git actually recording in its database? Now, without going too deep, it's usually recording line changes within a file, and that's why merge conflicts come up. It's not because multiple files change. It's going to be multiple lines changed by different people in the same file, and that's why we have to resolve that. \n\nTake a JSON file, for example. A lot of people are familiar with that data structure. If I'm adding a new item in a list in a JSON file while you add a whole new object in that same location, you can't just merge those automatically. Those are two different data types that will break the JSON format. That won't be a valid source code file anymore to use within my code. That's why we check up on the lines that you're changing and why you have to make the decision and the distinction of which one makes sense. And sometimes, like Mike said, it's neither [laughs], and you have to fix it yourself.\n\nEDDY: 100%. Well, and it's kind of cool that Git kind of just sits back and be like, you tell me what the right version is, and then I'll go [laughs] ahead and push it up. So, it gives the responsibility to the writer. \n\nMIKE: And, interestingly, you're probably doing this in a branch. And you're probably using some of these tools on top of Git that will then let you do a review process. And so, other people can look at it and say, \"No, that's not how it's supposed to go,\" or \"Oh, yeah.\" \n\nEDDY: So, I've heard that before, we used local databases as a way of version control. Like, is that true prior to, like, cloud-basing version control? \n\nJP: I mean, and that's still what we use databases for [laughs], just not for source code, if you want to think about it that way. We've chosen to add an additional set of tools and technology in the Git database to manage source code and files. But we have customer data, potential [inaudible 30:47], mathematical computations, whatever you're storing in a database. It's still version there and sometimes has its own scheming.\n\nEDDY: I got to imagine, right? Like, if you were storing that in a local database somewhere, what happens if that data gets corrupted, right? \n\nJP: [laughs]\n\nEDDY: So, it's like one point of failure, essentially.\n\nJP: Absolutely.\n\nKYLE: You work later.\n\nEDDY: [laughs] You work later.\n\nKYLE: You work a lot later.\n\nJP: [laughs] And there's the whole concept as well of what Git is, right? I mean, Git is a simple database technology that runs off files on your system. You're storing something in a large database technology like we've been using Postgres as an example. You have to run a whole set of technology as well. So, let's call out Git as well. You don't have to run anything. You just have to use tools that apply the Git technology, Git database technology in order to work with it at runtime. You don't have to keep something running 24/7. That's another big benefit.\n\nMIKE: It relies on the file system you already got, you know, and there are distributed databases that people use for customer data. Couchbase is one I've [inaudible 31:53], which is designed for cases where sometimes somebody's not going to be connected for a while. It might be good for a mobile app where, you know, somebody's going to be offline a lot [chuckles]. And they're going to be making some changes, and you want to merge those back in later. So, these kinds of ideas are not exclusive to Git and can be used for other kinds of data. But we're talking about Git, which is designed around files.\n\nJP: I guess to also talk about–Eddy, because I really like what you mentioned; there are other stores, and one extremely popular, like, data store that isn't doing it for, like, source code but for in general for files as a whole is, like, S3 or similar blob storages. They can also version your files. They don't do it as a conglomerate like Git does, where everything that's changed in this specific directory structure is recorded. S3 can take specific files and manage their versions over time. \n\nSo, just like Mike said, there are other version control technology out there. You could store your code in S3 and version it that way. It's not going to probably be very beneficial. But some of those ideas that have come from Git and the previous VCs technologies are definitely used in a lot of other places. \n\nKYLE: Slap Athena on top of it, and you're good to go.\n\n[laughter]\n\nMIKE: We've talked a lot about how Git works, what it does, this idea of merge conflicts. We haven't necessarily talked much about best practices.\n\nEDDY: Don't force push if you're collaborating.\n\nJP: [laughs]\n\nMIKE: That goes back to the rebasing thing. You change history now the other person has got a divergent history. And what do they do? That's the gotcha for using a rebase approach. I actually am partial to the rebase approach, but that doesn't mean that it solves all problems. I like to have a Git history that's easy to follow [chuckles]. I think it's a wonderful thing. [chuckles] I mean, when you have to go back and try to figure out what happened in the codebase, it's great. \n\nBy the way, this is just database. You can look at the history. If you've got the Git command line, you can do Git log, and it will show you all of those commit hashes plus the description of the change all the way back through history, and you can search it. And you can pass the dash p for the patch flag, and it'll show you the differences. And you go back and just search, like, uh, this is the name of the function that I'm looking for. And you can go back and search through your history. It's just like any other file. You can go back and search through it, which is fantastic [chuckles]. It's a searchable database. \n\nBut, you know, so, I really like to be able to search for things, to be able to understand things. But yeah, if you ever are in the same branch as somebody else, if you change your history using this rebase, if you change the history and then push it up to a shared repository—you have this force push that allows you to do that—then anybody else who pulls that is going to have to deal with the consequences, which is now their local version is not in sync with the remote version. They have a different history. And they're going to have to figure out what to do. \n\nThey can throw out their local changes. Hopefully, they haven't done anything important, right? That rebase type flow really only works if you have individual contributors working in a branch, and then a shared branch you treat as something that you don't change, right? You don't ever rewrite the history on anything that's shared.\n\nJP: You know, and you mentioned best practices. I'd also, like, include as, like, a subcategory and kind of really [inaudible 35:03] on that is also branching strategy as part of best practices. A lot of popular projects out there, especially ones that are, like, libraries for simple projects, use something called trunk-based development, which is usually a branching strategy of where you have a default branch typically named, like, master or main. \n\nAnd your code, when you branch off that, and you return back to that original branch at some point in time, usually, through a pull request or a merge request against standards that you want to follow, when you're using Git, usually, you choose to go back to that branch. But there are many other strategies out there, and your team or project should help decide what branching strategy you should use. \n\nA lot of mobile projects for a long time have used Git Flow as a branching strategy, which I won't even attempt to try to explain right now. But it is a whole nother branching strategy with a whole nother set of standards. So, you really have a lot of flexibility to be able to define these on your own, but each one comes with their own caveats. \n\nIf you're using trunk-based development where you're merging back to that master or a main branch, just as Mike mentioned, let's say I'm working directly on the main branch. You should never do this, but let's say that you are. Let's say I force-push a rebase that I had just done on the main branch up to main, and Eddy comes to put up a pull request with his changes that he had branched off main. Now he's going to have even more issues because the branch he's trying to go back to, to merge back into, he has diverged his branch's history from that branch he's going back into, which can be a nightmare. \n\nWhat I'm trying to say, in a nutshell, is know what branching strategy you want and have certain rules for the certain branches that you're working with of what they are allowed and not allowed to have happen within their history.\n\nMIKE: A simple rule, based on what you said, Eddy, is never rebase shared branches. It's pretty straightforward, but you have to come up with a way to do that. How are you going to do this? You can work on your own stuff, and you can rewrite your own history because it hasn't been shared with anybody else yet. But once you put it out into the world with other people, then you have to only go forward, right? It's past the time when it's responsible to go back and try to rewrite history and change things.\n\nEDDY: I wanted to mention, just so I can get some more context, what's the branching strategy that we use in our team?\n\nMIKE: We used to use something closer to Git Flow, but we have moved back to a trunk-based strategy because, again, thank you, DevOps [laughter]. We've got continuous delivery. And if you're deploying 20 times a day, you're making lots of little changes, lots of little low-risk changes. That doesn't mean no risk, right? You need to be responsible in your changes.\n\nJP: [laughs]\n\nMIKE: But if you're making many small, concise changes, they're unlikely to step on each other, and you can just go back into your default branch. One reason the mobile teams use something like Git Flow is that you maintain a parallel branch. You maintain a parallel branch for development and periodically come back to your default branch, to your primary branch. The reason for that is something like mobile; you can't deploy many times a day because you're working with an app store, you know, you're working with a third party that doesn't allow that kind of continuous deployment that you can get in a web application type of environment. \n\nSo, everybody has a different shared branch that you periodically merge into the one that ends up going to your app store, and that way, you still have your shared branch. You still have this idea of a shared branch similar to, you know, that main or master, but it's different. You have this development branch, and that's what you are treating as the shared special branch. And then the main one you only use for those builds. \n\nJP: So, in a nutshell, you can say, when you're defining your standards and your branching strategy that you're using with Git, it's really influenced on how you're deploying something. Git doesn't do the deploying, but how you use Git and the database will be influenced from that deployment type. So, a mobile app, like Mike said, is your source code packaged up in some formation. But a web application or a web server that's something that's ingested and can be constantly updated on every single network call that your client is making. So, those just have very different deployment strategies. \n\nIf you even see, like, talking about, like, Slack or another tool that's built on Electron, that's even more complicated because it is a web application running as a desktop application. So, you have to do both types of deployment strategies. So, it's really cool. And you have to definitely pay attention to both sides of the coin. How do I want to develop, and how's it going out after I'm done?\n\nMIKE: There's no one right answer. \n\nJP: No, no [laughs].\n\nEDDY: Yeah, the takeaway, for me, so far, has been Git is much more vast than I initially thought it was, which is really cool.\n\nJP: Git's simplistic in nature of what it's trying to record. So, it makes it a powerful technology.\n\nMIKE: It follows the long history of Unix tools...\n\nJP: [laughs]\n\nMIKE: That are really good at one very specific thing so that they can be chained and used together. Even the fact that it uses the filesystem as its storage means that it lives within an ecosystem. You can swap out the file system; no big deal, right? In fact, you would likely have different developers on different file systems, and it's all okay [chuckles]. That is not a problem at all. It's intended to do a good job within its own little niche and never step outside that. If you need to step outside that, use another tool.\n\nKYLE: I mean, that's ignoring the carriage return, right?\n\nJP: [laughs] Hey, they fixed that too, Kyle [laughs].\n\nMIKE: If any of our listeners don't know, different operating systems have historically created files that used different line endings. And trying to collaborate across different operating systems where [chuckles] they have different endings of your lines means that some people are going to have a carriage return, some people are going to have a line break, some people are going to have both. And having to merge those is potentially painful. And they've had to improve that cross-operating system handling overtime, partially by using some heuristics, say, you know what? I think you're on a Mac. I think I'm going to go with, let's say, carriage returns only, [chuckles], you know, and they just make some guesses.\n\nEDDY: If you were to make a new utility to replace Git, what would be your approach to making it more predominant?\n\nJP: I mean, all jokes aside, my first thing would be, what am I trying to fix? Because that's how you find not only your target audience but how you build the right technology. What does Git not solve for you right now? And I guess people have actually asked that question. And there are other tools out there. That's why GitHub exists. That's why GitLab exists and adds those additional feature sets.\n\nMIKE: There is a modern version control system called Mercurial that has a niche following, that I think has a lot of these same features. But it's partially proprietary, and people are cheap. And one thing people like about open source, not always, but often, you can get it for free, as in beer, as well as free as in speech. And they like that free stuff.\n\nEDDY: Is Mercurial, the one you are mentioning, open source?\n\nMIKE: My understanding is that it was not, at least times in the past. Is it today?\n\nJP: I don't know. I'm going to find out. \n\nMIKE: It looks like it is today [inaudible 42:12]\n\nJP: I keep finding people saying Mercurial is free. It does not say open source but free.\n\nKYLE: GPL V2. \n\nJP: That would be open-source\n\nEDDY: For the listeners, open source and free are completely different. \n\nJP: [laughs]\n\nEDDY: And it did take me a bit to [laughter] [inaudible 42:30] when I first started to find that distinction.\n\nMIKE: According to Wikipedia, which could be wrong [laughs], it says that Facebook uses Mercurial, Mozilla, the W3C. \n\nEDDY: What is Mercurial trying to solve here? Like, what's its selling point?\n\nMIKE: Another thing on the Wikipedia page says that Bitbucket dropped Mercurial support back in 2020 because less than 1% of new projects use it. So, it's one of those things that it may be solving lots of problems, but I don't have enough familiarity because I don't use it.\n\nJP: Eddy, I'll ask you the same question in a different way: of why do people still write in COBOL? \n\nKYLE: Because of our banking software.\n\n[laughter]\n\nEDDY: Because if you have a repository that is written on COBOL and trying to [inaudible 43:18] would be a [inaudible 43:21].\n\nJP: Yes. I would say not only is, like, there's the cheap factor of software, but there's also the familiarity in the habits of software. \n\nEDDY: Well, familiarity isn't really always a good thing because with technology always changing every single day --\n\nJP: Then we end up with COBOL.\n\n[laughter]\n\nEDDY: It took me a few months to really get familiarized with Git. And to have to adopt a new technology just because someone has an itch [laughs] is not always fun.\n\nMIKE: You know, Git it is a tool that has met a lot of people's needs, and I think it became popular because it worked [chuckles]. That doesn't mean that there are not other tools that work and may even be a little better. But it does a really good job. And any differences are just not enough for people to care about. And momentum is hard to beat. If you've got a tool that does the job for almost everybody, then it's going to get the attention. It's going to get the fixes. Eventually, it's going to get the features.\n\nEDDY: So, I'm assuming Git is something that's widely used predominantly in the software industry, right?\n\nMIKE: I honestly can't think of the last time I talked to somebody who wasn't using Git [laughs].\n\nEDDY: So yes, listeners, I would say if you're wanting to become a developer, I would think familiarizing yourself with Git [chuckles] is crucial.\n\nMIKE: My 11-year-old was asking me about Git the other day. It's that ubiquitous [laughs]. He ran into it independently, looking into Minecraft modding, I think. But the first answer he got is, \"The first thing you need to do you need to set up a Git repository.\" [chuckles] And like, \"Oh, can you tell me how to get set up with GitHub? What's GitHub?\" [laughs]\n\nJP: And then I would also say, not even just as a developer, if you're even a data engineer and you're looking to leverage tooling and other things out there, it can be very useful to know at least some of the fundamentals of Git in order to get your way around those tools and see how they work. Documentation has also made its way, like you were kind of hinting at, Mike, into the Git world. So, learning about that if you're doing any kind of technical documentation is also a really good place to be.\n\nKYLE: Even more, like, layman tasks. My wife ran into it a while back. She has her website blog that she uses, and she was looking up how to modify one of her themes, and she needed to get something off of a Git repo. You know, it's kind of trending towards a common tool that everybody's going to have to know about, you know, even if you're just a writer, or in social work, or something, right? You don't have to be an engineer. It's out there. There's some obligations that you're going to find in Git.\n\nMIKE: And I wouldn't say just a writer or just a social worker. \n\nKYLE: Well, those -- [laughter]\n\nMIKE: We provide value in different ways [laughter]. That does not --\n\nKYLE: Yes. Yes. You're right. You're right. My bad.\n\nMIKE: [laughs] Git is an amazing tool. Those of us who've been around for a while use some other tools. Most of us have deeply fallen in love with Git and how well it works for us. It's one of those things that just works. Anything that just works is wonderful. Whether you're maintaining your social work documentation, or whether you're writing code, or whether you're doing something exotic, I can't think of [laughs] that it's amazing using Git. \n\nIt's a tool that generally just works. It helps me to understand what's going on, to understand what it can do and what it can't do, and to go back in time. That actually is a feature, not a bug. And it allows you to work with other people well. If you haven't used it yet, give it a try. Collaborate [laughs]. We'll talk to you next time on the Acima Development podcast.","content_html":"The podcast begins with Mike sharing his fondness for smoothies and drawing an analogy to Git, a distributed database. He compares the irreversible process of making a smoothie to the irreversible nature of operations in Git. Mike explains that Git, emerging from the same project that gave us Linux, is a distributed database that allows information sharing and verification across geographic regions. He highlights Git's significance in facilitating collaborative development in large-scale projects like Linux.
\n\nThe discussion then shifts to the technical aspects of Git, such as dealing with conflicts, the concept of a distributed repository, and the uniqueness of Git in managing changes and time. Mike elaborates on the cryptographic operation called hashing used in Git, emphasizing that changes in Git represent patches or differences rather than versions of code. The panel discusses Git's ability to handle vast numbers of contributors and the significance of timestamps and commit hashes in tracking changes.
\n\nFinally, the conversation delves into the practicalities and best practices of using Git. The team discusses branching strategies, the importance of not rebasing shared branches, and the impact of different deployment strategies on Git usage. They also touch on the challenges of merge conflicts and the importance of understanding Git's limitations and strengths. The episode concludes with an acknowledgment of Git's ubiquity in various fields beyond software development and encourages listeners to familiarize themselves with Git for collaborative projects.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development podcast. I'm Mike. I'm going to be hosting today. With us, we've got Eddy, JP, and Kyle. Great to have you all here today.
\n\nAnd, as usual, I'd like to start with a bit of a story. And I'm actually going to talk about my breakfast this morning. I have become a great lover of smoothies [laughs]. Years ago...I enjoy them. I've always liked a smoothie, but they never really were enough. I have a lot of appetite. I was a huge eater as a teen. I was late getting my height, so I grew a foot in a year [laughs]. That left me skinny and hungry [laughs], and I also ran long distance. So, huge appetite in my teens. You know, I still don't have the same appetite as I used to have, but, you know, I still like to eat enough. And something like a smoothie for breakfast was never enough.
\n\nWell, I kind of by accident stumbled on a combination that scratches the itch [laughs]. I put a lot of seeds in it, and that gives the fat and protein it needs to keep things good, and then lots of whole fruit. I don't even throw juice in anymore. So, I just use water to add enough liquid. That means that I am getting all kinds of fiber, and I get the fat and protein from the seeds. It means that I stay really stable with my blood sugar. It's fantastic. I love it.
\n\nSo, I throw together all these ingredients in a blender, you know, I add the water and blend it. One thing that I have never tried to do is put the fruit back together afterward. And there's a reason for that, and it is that it's effectively impossible. I mean, technically, you could pull apart all the molecules, right? And reconstitute them. But there is no way in a meaningful amount of human time. And I think it would all have rotted by that point anyway, right [laughs]?
\n\nThere are some things that only go in one direction, and a smoothie is one of those [chuckles]. You press that button to get it going, and that's the end of that fruit. It still tastes good [chuckles]. It's still valuable. It's still valuable. But it only goes in one direction. That actually applies to several aspects of what we're going to be talking about today regarding Git.
\n\nGit is a distributed database, and if you're not familiar with, you're thinking, well, why would I need a distributed database? It's like listening to your friend, who is a huge Bitcoin enthusiast. We all need distributed databases. Unless you're an enthusiast, probably your eyes glaze over [laughs], and you forget about it until the next time your friend comes over. But it's a similar sort of thing. Most of these cryptocurrencies are built as a distributed database so that you can have information shared across geographic regions and be able to verify that data is not corrupted. That's what Git is. There's a few reasons that it is what it is.
\n\nNow, Git was spawned by the same project that gave us Linux, the operating system that powers, like, most of the internet [chuckles]. If you've got an Android phone, it's running Linux. If you've got some cars, I think Tesla runs Linux, you know, Linux runs kind of all the things—most of the servers, not all of them. You have some Windows servers out there, some old Unix servers, but a lot of the [inaudible 03:19] are on Linux.
\n\nBut a long time ago, it was just some guy, Linus Torvalds, who wrote a project where he had an operating system in college, and he released it open source, released his code to the internet. And people actually started using it, and they started contributing to it. And pretty soon, it was this worldwide project where you have thousands, potentially, of people who are all contributing to this project. And sometimes they're going to make changes in the same files. And there were systems for managing that sort of thing in the past, but they all had a few problems.
\n\nFirst, dealing with conflicts was a pain [laughs]. And there's a few ways to deal with that, but you need to recognize that conflicts are a pain. And they are especially a pain, and to go back to my smoothie, they are especially a pain if you have to have some sort of shared state. If you say this is the perfect state of the repository, this is how my code is and that everybody has to work with that version of the code, well, if you have 1,000 people working on the same thing at once, it's pretty much impossible to actually have a shared vision of what that thing is. So, that is a serious problem.
\n\nIf you have a whole bunch of people trying to make the smoothie at once, it's even worse than it happening in one place. Well, Linus Torvalds had an idea to change from the way things were currently working, where he said, you know what? We're not going to have a central version. There is no such thing as a, you know, single, canonical version of what our code is. You can all code separately, and it's fine. And we're just going to let time move forward. And what the pure, true version is, is just whoever the person in charge says it is, who has their copy of the code.
\n\nAnd here's the other place where the smoothie comes in. This idea of time only moving forward matters. There's an operation, a cryptographic operation, called a hash where you take some data, and you can do some mangling on it, and you get a number out the other end. And you can't go back the other way. There's a few different ways of doing it. There's a popular algorithm, the SHA set of algorithms, that is used to do this hashing. And it's really all it says, you know, hash means to scramble something up. It's basically what I'm doing with my smoothie. You can do it with vegetables [chuckles]. Once you've shredded something up, you can't go back the other direction.
\n\nSo, this is the other key thing that Git does is that anytime somebody makes a change, it makes a hash of that change. That is, it runs this mathematical operation, takes all your changes, and comes out with just a number on the other end, a long number. And that number is pretty much going to be unique. The chances of it being the same as somebody else's numbers that they hashed is essentially zero.
\n\nSo, you can have people all over the world making their changes and then creating these hashes, and the hashes are all going to be different. Together with that hash, you have a timestamp. And each of those hashes is associated with a change, and the change is not a version of the code. And here's another key thing to note: the changes represent a change, that is, a difference. They represent a patch or a this is what we're going to do to change the code.
\n\nSo, what you end up with is this database distributed across any machines. You can have thousands of people. They could be working for months separately, come back, and they have this list, you know, this set of changes. Each of these changes has a commit hash associated with a unique number you can identify with and a timestamp. And each of these also represents a set of changes that's going to be applied. As long as you can apply those changes, it really doesn't matter if you don't have a central version, just [inaudible 06:47] the changes.
\n\nAnd you can imagine sometimes it doesn't work. And that's what we're going to get to a little bit later today is dealing with some of those times when it doesn't work. But the fact that the time only moves forward, that is, you always have to apply changes; you're not going back to some central vision of what the code is. It means that everybody can work separately, and it's just fine.
\n\nWhat you decide to deploy here with Linux is whoever is in charge of the project says, "Hey, this is the version that we're going to go with." And you think, well, how do you know? Well, you know, you probably have a human problem there [chuckles]. That is, we have human structures to deal with governance, so use those human structures. Let the people decide and designate somebody who is going to say, "Okay, this is the version that we're going to go with." And if you have that person, she or he can say, "You know what? This is good. I give it my stamp. We can deploy this."
\n\nAnd then you can have people working separately, and they can contribute to it on their own time by removing that need for a central figure and by giving things, you know, these unique handles so that, you know, everybody can verify that the change is unique. And by allowing time to only go forward—you can only make changes—then you can solve a lot of the problems that we had because there were systems before. Did any of you use some of the systems we used before Git, and how did that go for you?
\n\nEDDY: Well, honestly, for myself, I'm pretty new [laughs] to development. So, the only version control that I know is Git. I'm no stranger to previous systems, you know, that were used in the past. Like, out of curiosity, I did look up on, like, what Git was, and I looked at the timeline and what other features they were. I read about, like, RCS and SVN, et cetera, which pale in comparison to what Git is.
\n\nMIKE: Kyle, I think you mentioned you used CVS back in the day.
\n\nKYLE: Yeah, I was quite junior. I don't remember a lot about it. The one that I would know the most about, which was just that it was always down, was, like, our SVN when I was at a C# shop specifically. It was great when it was working, but it seemed to stop the ship anytime there was a major error. It seemed to stop the ship pretty dead center when there was a conflict, which was always just a hassle to get through.
\n\nMIKE: And you hit on something. It was really hard back in the day to try to manage this using the tools that were there. But those tools were a big step forward from what you had before because if you don't have some sort of tool for [laughs] managing, then you just got your code on your machine, and you email it to somebody, right? And then, they try to figure out the differences and hope they get it right. That's not a great way to do things. Really, that's what you had before we had some of these tools.
\n\nSo, while it may sound like we're casting some shade on Subversion or CVS, that doesn't mean that those tools were not incredibly useful and a huge step forward from what we had before. But once you have to have a central, a central repository to maintain, then you have a single point of failure. And a single point of failure is not so fun to deal with.
\n\nJP: I guess also want to call out as well that Git is not the last iteration as well. A lot of people will talk about Git. We have all these beautiful tools that have emerged in the technology industry to work on top of Git. I mean, the foundation is still Git and a lot of these other tools like Subversion and CVS, but really, Git just laid a foundation, like you said, with distributing that data and using, you know, the mathematical computation of hashes to be able to empower this extremely large distributed network of code and make it publicly accessible, which was something that really wasn't there before.
\n\nEDDY: Wait, Jackson, you said that it's not the end all be all. So, are you saying that there's other version controls currently that are newer --
\n\nJP: Not other version controls, but systems leveraging Git. So, I know at Acima and at a lot of [laughs] organizations, the world depends on GitHub, for example. GitHub itself is a version control system that relies on Git but adds a ton of additional features on top of that system.
\n\nMIKE: Right. It's another layer on top of it. When you think about a database, releasing a database to the world is awesome, but not very many people are going to say, "Hey, I'm going to go hit PostgreSQL today." But they might say [laughs], "I'm going to go visit Facebook," right? [laughs] And that layer on top matters with GitHub, or GitLab, or Bitbucket, or, you know, there's any number of different versions out there. I'm not trying to say that one is the best. They add another layer on top, so you actually have an application that runs on top of that distributed database down beneath.
\n\nJP: The big call out kind of, Eddy, to respond to that, is, like, what does GitHub give that Git doesn't by itself? Right off the bat, the biggest feature that I guarantee that most people would agree on is pull requests or merge requests, the concept of that. That is not something that comes with Git by itself.
\n\nEDDY: But that is available with other version controls, right? So, I'm sure GitLab does something similar to that.
\n\nJP: Well, absolutely. GitHub, GitLab all of those more just systems leveraging Git provide that functionality. But Git, by itself, if you're just hosting your own Git server, it doesn't come with that functionality.
\n\nMIKE: And Git is the database.
\n\nJP: Yes.
\n\nMIKE: Git is the database, and the database is not going to give you all the social interaction tools that these applications provide, this idea of a pull request or a merge request with reviewers, what all that you have in there, your descriptions, all of your workflows.
\n\nJP: Status checks, yep.
\n\nMIKE: Yeah, that isn't provided by the database. The database stores the changes to the code, but it doesn't manage any of that social interaction, and that's by design. You know, it's a tool that's designed to be the database, not to manage that social interaction. That's an important thing to recognize.
\n\nEDDY: That's interesting. I never thought of Git as a database. But putting into perspective, I think it actually makes sense in hindsight.
\n\nJP: And I guess kind of to, like, layer on top of that, Mike, if you don't mind, we have Git as the database. But there are a lot of other...like, we talked about GitHub, GitLab that leverage that database. But the day-to-day, again, even when developers are working with Git on their systems, they're not working with the database directly. They work with the Git CLI. And there's other alternatives to that as well. So, a lot of people think that Git CLI is...that's it. That's the thing doing my version control. No, it's that combined with the database technology underneath that really gives you that full functionality of Git.
\n\nMIKE: That's a really good point. We interact a lot with that command line interface, right? You know, all of the command line tool that Git provides for us or maybe use a graphical tool to interact with that.
\n\nJP: Yeah [laughs]. Yes.
\n\nMIKE: And a lot of people do. But that itself isn't the database [chuckles]. Having those tools for writing the database are important. You [chuckles] don't want to corrupt your database, and then you've got an even bigger problem [laughs]. It's probably been done, but I strongly doubt that very many people have ever written their own data to that database by hand. They use an automated tool to do it.
\n\nEDDY: I actually have a question. And, again, seven months full-time development, so I'm still pretty new to the concept. Git, since it's a database, does it store all the repositories for a vast majority of the companies that use --
\n\nJP: Oh, good question, though. Good question.
\n\nMIKE: Let me answer that question with a question. Do the databases you use store data from Facebook, and why or why not? So, for your application, say you're using PostgreSQL, do you and your PostgreSQL database store data from another company?
\n\nEDDY: Probably not.
\n\nMIKE: Probably not. But they may also be using PostgreSQL, right?
\n\nEDDY: Right.
\n\nMIKE: So, PostgreSQL is a technology that can be used to create a repository for storing data, but it isn't itself of that repository. It's a technology for creating a repository. So, there are, you know, millions of entities out there that have a repository, but that doesn't mean they all have the same one in Git or in any other database. There are many repositories out there, many of which have nothing to do with each other at all.
\n\nAnd thinking about this being distributed, we can all have separate repositories, and that's fine. But many of us have repositories that we connect to each other so that we can have some sense of shared direction and code and data, maybe, I should say. Because it doesn't necessarily have to be code. I've used Git for things other than pure code.
\n\nJP: [laughs] And I guess to kind of follow up on that as well to kind of answer it, just using GitHub as an example, and I guess most major version control hosted solutions, each project or set of projects that you're working on usually gets written in its own Git database, its own...what they call a Git repository. That is the terminology for it. So, a lot of organizations, or bigger companies, or even just large projects will have many Git repositories that are all tracked in separate Git repository databases, not in the same one together.
\n\nEDDY: So, where does the code get saved then when you push up? --
\n\nJP: Oooh, another good question. In that case and, Mike, please, yeah, please bounce off me. Using a provider like GitHub, they're actually hosting a Git server. That's another piece of the Git technology stack, Git repository server that will receive the requests of the commit hashes that you're changing and the associated data, and they will store it on their side.
\n\nMIKE: Remember when I said earlier that you designate somebody to be the person to say, "Hey, my repository is the one that matters?" We've elected to let GitHub...I say we, you know, anybody who chooses to use GitHub generally elects to use GitHub as that gatekeeper. And we've chosen their copy of the repository to be the one that's in charge, but everybody else has a full copy. Anybody who works with that data has the full set of data.
\n\nGitHub is not special or GitLab, you know, you name it. We'll use GitHub today. They're not special. They could go down, and the world would be okay [chuckles]. You wouldn't because [laughter] [inaudible 16:48]. But we wouldn't lose everything because everybody else who's ever used that code would also have all of that data. You're pushing data. You're just syncing your data to that other repository, but you still have everything else. You're just pushing up a few little changes. Really, you're just pushing up those few commits, those few little chunks of changes with their hashes, and not everything. You're not pushing up the whole repository. You're just pushing up the changes that you made to your own branch.
\n\nWe didn't mention branches before, but it does allow you to have...it has this idea of a branch in Git. So, you can say, "Oh, you know what? I'm going to make a copy over here." And it's really lightweight. You're not actually copying over all the code because the beauty of this distributed database is you're just making a set of changes. So, naming a set of changes is no big deal. It's just, what, one name [chuckles]? The overhead for that is extremely small.
\n\nSo, it's really easy to create a new set of changes [inaudible 17:43] go off in your own direction, and you can throw it away. Or you can bring it back here and say, "Hey, you know, I'm going to bring these changes in," which actually brings us to a point that we said we'd talk about is what does it mean to bring changes in? What does it mean to merge branches? And there's a couple of different schools of thought on how to do this.
\n\nLet's say you've got a branch of code. It's just the history, right? It's just a series of changes. You can call them patches, commits. Here's the change that's going to be applied. Here's the change that's going to be applied next. Here's the change that's going to be applied next, from zero up to infinity, right? It's just an endless set of changes that are applied. And if you have two people who've been working separately for a while, you can merge those. And as long as you haven't been changing the same files, then it'll work, right? They'll be interleaved.
\n\nYou'll have one person's changes, and that person made another change. Then the other person made a couple, and then the first person made a couple, and the other person made one, and the other person made one. You'll see it coming in from one person and the other person and one person and the other person. If you look at the history, you'll just see that history of when they made those changes. Each of those changes represents a change to what happened before.
\n\nAnd if you're thinking about reading the history, if you want to just know when they made those changes, well, that's a reasonable way to think about it. But I will say that that's not usually what you care about. What we usually think about is in terms of something more like a feature. And the way that people usually use Git is they have a branch where they build out a feature, and then they want that feature to come in. And if you wanted to go through the history and see how that feature was built, you'd have to go through and see all the little changes interleaved with everybody else's changes.
\n\nSo, there's another school of thought that says when you're merging, you shouldn't actually do this [inaudible 19:18] what we call a merge, where you just throw all the changes in where they were made. Instead, you go through a process, first, of rebasing, and rebasing actually means more than one thing. It's a bigger tool, and, hopefully, we have time to talk a little bit more about it. Think about that word means base and rebasing means you're redoing the base [chuckles].
\n\nSince our changes are just a series of patches, I'll make this change, and this change, and this change. Usually, you're making those changes thinking about starting back whenever you branched off of the code originally. But you can change that. Git will allow you to do so and say, you know what? Instead, I'm going to branch off of where the code is now on my local version, you know, grab the changes or, you know, or even off a remote version.
\n\nI'm going to branch off of this specific commit. Remember, they're named. They're named with this big number, this hash. Say, "I'm going to branch off of this hash instead." Then you can do a couple of things. You could either squash all your changes down to one big change, and then you've only got one big change [inaudible 20:11] for your feature. Or you can just put them all in together, but they're all sequential. Then, if you go back through your history, you see a series of the sequential changes for one feature, and then a series of sequential changes for another feature, and then a series of sequential changes for another feature. And it makes it much easier to read.
\n\nSo, here's the two schools of thought: the hey, just merge it in. It's the easier way. I say the easier way; it's the more simplistic way. It's kind of the default. "Hey, I'm just going to throw my stuff in there. I hope it works," way of doing things. And then there's the rebasing approach, which says, you know what? I'm going to try to be very polite and put my changes all in one nice, little tight bundle so that people can read it later. It does make the history a lot easier to read. But it also means you got to get everybody else on board. And it also means that you're rewriting the history because you're changing your local branch to be starting from somewhere else.
\n\nAnd if you have anybody else collaborating on that local branch, you're going to do them a world of hurt when you do that if they try to pull those changes down because it's going to say, "This doesn't match my local version. The history is rewritten." What happened in the past? I don't know anymore. The world makes no sense. And [chuckles] they're going to have to decide what the true history is. There's some downside to collaborating within a single branch when you follow that approach if you're ever going to make changes after you've done a rebase.
\n\nJP: I guess kind of to, like, to step backwards as well, like, simplify what all that really comes down to in Git terminology because these words get thrown around a lot, is you either have a merge commit, which that happens during the Git Merge process, and that's that default mode we talked about a second ago, just merging in the history. And your changes get globbed on top of each other, not maintaining the actual linear history of changes.
\n\nOr there's rewriting the history, which is actually moving your commit hashes around and potentially resolving conflicts, which is maybe something we can talk about as well, in order to create a new linear history that more matches the actual timestamp of when those changes happened, even if they were on separate branches and time.
\n\nThere are definitely, like Mike mentioned, benefits and drawbacks to both approaches. And, you know, it can be a very opinionated thing. But it really depends on, do you care about how your code was put together? And do you want to see the changes in a clear, fashionable way that can be audited according to certain standards? So, hopefully, that's another good way to reference that.
\n\nEDDY: Let me ask you this, then, when you roll back, where do you reach out to? Do you use Git as a tool to roll back, or do you use the [inaudible 22:37] to roll back?
\n\nJP: That's a really complicated question because that really depends on what rollback means. Yes, that can be part of what they call the GitOps process, you know, doing events based on changes to a Git database. But that's going to depend on organization from organization [chuckles]. It's not necessarily related to Git. It can be, and a lot of organizations choose to do that. But yeah, that's a large discussion [laughs].
\n\nMIKE: Well, you hit on something really key that I tried to talk about with my smoothie [laughter] [inaudible 23:08]. Git doesn't have a rollback. It has no such concept, and that is by design. Time can only go forward. Once the smoothie is made, you can't put it back together. Git only has the idea of a revert, and a revert does not undo anything. And this is critical. This is, like, a really important thing to understand: A revert does not undo anything. It does the changes in reverse because time might have gone on, right?
\n\nLet's say that ten people have put new code into the repository that you've decided to centralize on after you made your changes. What would rolling back mean? Getting rid of all those changes? Getting rid of some of them? Doing some sort of rebase where you put other people's stuff on top of yours? It's ill-defined. It's not a well-defined problem. And Git has decided that there is no answer to that problem.
\n\nInstead, when you're undoing your changes in Git, it just applies your changes in reverse. And then, when you go to try to merge them in, they might not work. You might not be able to go backwards anymore because things have changed. And you're going to have to deal with the conflicts because, again, time only goes forward.
\n\nJP: This even occurs, let's say, if you wanted to delete history. The same concept happens in Git if it only goes forward. Yes, you removed, or you rebased, is really what the terminology is, your history of commits. There's a mark in time that a rebase occurred there, and it's by new commits. The new commits come in, and that is only going forward. You can never really return back to that location that you were at before.
\n\nEDDY: Wait, but if you're going back, right? And it does it in reverse, like, how does it have context of all the code that's been merged since?
\n\nMIKE: It doesn't. It doesn't at all. It has zero.
\n\nJP: It only has context of what files changed and what lines and where. So, it just tries to repeat the previous commit or two or how many you've chose in reverse.
\n\nMIKE: And it might conflict with those changes that come afterward. It lets that set of changes be no different than any other set of changes. It's just a set of changes going forward. That's a key distinction that makes Git special. It actually makes it easier to use. It's weird to think about because we like to think about, oh no, there's this pure, true version, and I need to go back to that version.
\n\nJP: [laughs]
\n\nMIKE: But no, there is no such thing in Git. There's only time moving forward.
\n\nJP: And it's also kind of on that same vein; a lot of people usually take a moment in time in Git and turn that into some type of artifact that's this code in this point of time, but it is not Git where you're making that decision. It's where you package it up and put it somewhere else.
\n\nKYLE: So, basically, you can...the idea of rollbacks, or whatever, could only be possible with an actual binary.
\n\nJP: A binary, package, artifact, whatever you call that, but that comes after exactly the Git process.
\n\nMIKE: But you can copy out a version, right?
\n\nJP: [laughs]
\n\nMIKE: And then later, you can go back to it. That's not Git doing so. That's a choice outside of your database, you know, outside of your version control.
\n\nEDDY: I feel like having an analogy of what Git is would really help. While we were talking, I looked up a more simplistic way to think about what Git is. The repository is like a storybook, and the pages in that book are the files. The writers are the developers. Changes and additions are the commits. Book's memory is the history. Going back in time is the version control that we were talking about. Working together is collaboration. And then sharing the book is the remote repository. Would we agree, in essence, that that's a fair way to do a comparison?
\n\nJP: Yes and no.
\n\nMIKE: Digital book? Yeah.
\n\nJP: [laughs]
\n\nKYLE: I was sitting there thinking with Eddy's comparison there; I'm thinking back to all of my college books, right? And it almost seemed like it does work pretty well there. The revisions of your college books they don't change a lot. But they might fix some wording, and they might fix a few quote, unquote, "bugs" here and there. But they don't revert back to anything. They have to release a new version, regardless of what they're doing.
\n\nMIKE: Yeah, that's true. You can only do revisions forward. Once it's out there, you can't get it back.
\n\nJP: Great point.
\n\nMIKE: One thing we haven't talked about...we've talked about this idea of rebasing. We've talked about merging. We haven't talked about what happens when it doesn't work.
\n\nJP: [laughs]
\n\nMIKE: And yes, that will happen to you today if you [laughs] are just starting using Git because it does happen. Although if you use a very responsible and different ways to go about this, you know, if you have a very careful process...and I would strongly advocate for continuous delivery. Thank you, DevOps. We've got some DevOps people here. Thank you so much for making our lives better [laughter].
\n\nIf you make lots of small changes, you're less likely to have a problem. If you make a few huge changes, you're almost certainly going to conflict, and it's going to be painful. Sometimes, you're going to make a change in the same place somebody else did, and there's no way to get them in alignment automatically. That's what we call a merge conflict, and Git doesn't solve those for you. It instead gives you both versions side by side and lets you decide.
\n\nAnd sometimes, the answer is to pick one. Sometimes, the answer is you pick the other, and sometimes, the answer is you have to somehow make them work together [laughs] and combine the two. And this is inescapable because, yeah, you both change the same place. You're going to have to deal with that. And no, there's no magical system that can address that. So, instead, it just makes it easy. It says, here are your two versions. Go ahead.
\n\nEDDY: It's harder to resolve, or it's more common to run into when you have a larger team working on the same codebase.
\n\nMIKE: The number of people working in the same files is really the same thing. You could have two people working in the codebase working on the same file and have it happen a lot. It's the people working in the same part of the code that really gets you.
\n\nJP: I guess to call out that distinction as well, what is Git actually recording in its database? Now, without going too deep, it's usually recording line changes within a file, and that's why merge conflicts come up. It's not because multiple files change. It's going to be multiple lines changed by different people in the same file, and that's why we have to resolve that.
\n\nTake a JSON file, for example. A lot of people are familiar with that data structure. If I'm adding a new item in a list in a JSON file while you add a whole new object in that same location, you can't just merge those automatically. Those are two different data types that will break the JSON format. That won't be a valid source code file anymore to use within my code. That's why we check up on the lines that you're changing and why you have to make the decision and the distinction of which one makes sense. And sometimes, like Mike said, it's neither [laughs], and you have to fix it yourself.
\n\nEDDY: 100%. Well, and it's kind of cool that Git kind of just sits back and be like, you tell me what the right version is, and then I'll go [laughs] ahead and push it up. So, it gives the responsibility to the writer.
\n\nMIKE: And, interestingly, you're probably doing this in a branch. And you're probably using some of these tools on top of Git that will then let you do a review process. And so, other people can look at it and say, "No, that's not how it's supposed to go," or "Oh, yeah."
\n\nEDDY: So, I've heard that before, we used local databases as a way of version control. Like, is that true prior to, like, cloud-basing version control?
\n\nJP: I mean, and that's still what we use databases for [laughs], just not for source code, if you want to think about it that way. We've chosen to add an additional set of tools and technology in the Git database to manage source code and files. But we have customer data, potential [inaudible 30:47], mathematical computations, whatever you're storing in a database. It's still version there and sometimes has its own scheming.
\n\nEDDY: I got to imagine, right? Like, if you were storing that in a local database somewhere, what happens if that data gets corrupted, right?
\n\nJP: [laughs]
\n\nEDDY: So, it's like one point of failure, essentially.
\n\nJP: Absolutely.
\n\nKYLE: You work later.
\n\nEDDY: [laughs] You work later.
\n\nKYLE: You work a lot later.
\n\nJP: [laughs] And there's the whole concept as well of what Git is, right? I mean, Git is a simple database technology that runs off files on your system. You're storing something in a large database technology like we've been using Postgres as an example. You have to run a whole set of technology as well. So, let's call out Git as well. You don't have to run anything. You just have to use tools that apply the Git technology, Git database technology in order to work with it at runtime. You don't have to keep something running 24/7. That's another big benefit.
\n\nMIKE: It relies on the file system you already got, you know, and there are distributed databases that people use for customer data. Couchbase is one I've [inaudible 31:53], which is designed for cases where sometimes somebody's not going to be connected for a while. It might be good for a mobile app where, you know, somebody's going to be offline a lot [chuckles]. And they're going to be making some changes, and you want to merge those back in later. So, these kinds of ideas are not exclusive to Git and can be used for other kinds of data. But we're talking about Git, which is designed around files.
\n\nJP: I guess to also talk about–Eddy, because I really like what you mentioned; there are other stores, and one extremely popular, like, data store that isn't doing it for, like, source code but for in general for files as a whole is, like, S3 or similar blob storages. They can also version your files. They don't do it as a conglomerate like Git does, where everything that's changed in this specific directory structure is recorded. S3 can take specific files and manage their versions over time.
\n\nSo, just like Mike said, there are other version control technology out there. You could store your code in S3 and version it that way. It's not going to probably be very beneficial. But some of those ideas that have come from Git and the previous VCs technologies are definitely used in a lot of other places.
\n\nKYLE: Slap Athena on top of it, and you're good to go.
\n\n[laughter]
\n\nMIKE: We've talked a lot about how Git works, what it does, this idea of merge conflicts. We haven't necessarily talked much about best practices.
\n\nEDDY: Don't force push if you're collaborating.
\n\nJP: [laughs]
\n\nMIKE: That goes back to the rebasing thing. You change history now the other person has got a divergent history. And what do they do? That's the gotcha for using a rebase approach. I actually am partial to the rebase approach, but that doesn't mean that it solves all problems. I like to have a Git history that's easy to follow [chuckles]. I think it's a wonderful thing. [chuckles] I mean, when you have to go back and try to figure out what happened in the codebase, it's great.
\n\nBy the way, this is just database. You can look at the history. If you've got the Git command line, you can do Git log, and it will show you all of those commit hashes plus the description of the change all the way back through history, and you can search it. And you can pass the dash p for the patch flag, and it'll show you the differences. And you go back and just search, like, uh, this is the name of the function that I'm looking for. And you can go back and search through your history. It's just like any other file. You can go back and search through it, which is fantastic [chuckles]. It's a searchable database.
\n\nBut, you know, so, I really like to be able to search for things, to be able to understand things. But yeah, if you ever are in the same branch as somebody else, if you change your history using this rebase, if you change the history and then push it up to a shared repository—you have this force push that allows you to do that—then anybody else who pulls that is going to have to deal with the consequences, which is now their local version is not in sync with the remote version. They have a different history. And they're going to have to figure out what to do.
\n\nThey can throw out their local changes. Hopefully, they haven't done anything important, right? That rebase type flow really only works if you have individual contributors working in a branch, and then a shared branch you treat as something that you don't change, right? You don't ever rewrite the history on anything that's shared.
\n\nJP: You know, and you mentioned best practices. I'd also, like, include as, like, a subcategory and kind of really [inaudible 35:03] on that is also branching strategy as part of best practices. A lot of popular projects out there, especially ones that are, like, libraries for simple projects, use something called trunk-based development, which is usually a branching strategy of where you have a default branch typically named, like, master or main.
\n\nAnd your code, when you branch off that, and you return back to that original branch at some point in time, usually, through a pull request or a merge request against standards that you want to follow, when you're using Git, usually, you choose to go back to that branch. But there are many other strategies out there, and your team or project should help decide what branching strategy you should use.
\n\nA lot of mobile projects for a long time have used Git Flow as a branching strategy, which I won't even attempt to try to explain right now. But it is a whole nother branching strategy with a whole nother set of standards. So, you really have a lot of flexibility to be able to define these on your own, but each one comes with their own caveats.
\n\nIf you're using trunk-based development where you're merging back to that master or a main branch, just as Mike mentioned, let's say I'm working directly on the main branch. You should never do this, but let's say that you are. Let's say I force-push a rebase that I had just done on the main branch up to main, and Eddy comes to put up a pull request with his changes that he had branched off main. Now he's going to have even more issues because the branch he's trying to go back to, to merge back into, he has diverged his branch's history from that branch he's going back into, which can be a nightmare.
\n\nWhat I'm trying to say, in a nutshell, is know what branching strategy you want and have certain rules for the certain branches that you're working with of what they are allowed and not allowed to have happen within their history.
\n\nMIKE: A simple rule, based on what you said, Eddy, is never rebase shared branches. It's pretty straightforward, but you have to come up with a way to do that. How are you going to do this? You can work on your own stuff, and you can rewrite your own history because it hasn't been shared with anybody else yet. But once you put it out into the world with other people, then you have to only go forward, right? It's past the time when it's responsible to go back and try to rewrite history and change things.
\n\nEDDY: I wanted to mention, just so I can get some more context, what's the branching strategy that we use in our team?
\n\nMIKE: We used to use something closer to Git Flow, but we have moved back to a trunk-based strategy because, again, thank you, DevOps [laughter]. We've got continuous delivery. And if you're deploying 20 times a day, you're making lots of little changes, lots of little low-risk changes. That doesn't mean no risk, right? You need to be responsible in your changes.
\n\nJP: [laughs]
\n\nMIKE: But if you're making many small, concise changes, they're unlikely to step on each other, and you can just go back into your default branch. One reason the mobile teams use something like Git Flow is that you maintain a parallel branch. You maintain a parallel branch for development and periodically come back to your default branch, to your primary branch. The reason for that is something like mobile; you can't deploy many times a day because you're working with an app store, you know, you're working with a third party that doesn't allow that kind of continuous deployment that you can get in a web application type of environment.
\n\nSo, everybody has a different shared branch that you periodically merge into the one that ends up going to your app store, and that way, you still have your shared branch. You still have this idea of a shared branch similar to, you know, that main or master, but it's different. You have this development branch, and that's what you are treating as the shared special branch. And then the main one you only use for those builds.
\n\nJP: So, in a nutshell, you can say, when you're defining your standards and your branching strategy that you're using with Git, it's really influenced on how you're deploying something. Git doesn't do the deploying, but how you use Git and the database will be influenced from that deployment type. So, a mobile app, like Mike said, is your source code packaged up in some formation. But a web application or a web server that's something that's ingested and can be constantly updated on every single network call that your client is making. So, those just have very different deployment strategies.
\n\nIf you even see, like, talking about, like, Slack or another tool that's built on Electron, that's even more complicated because it is a web application running as a desktop application. So, you have to do both types of deployment strategies. So, it's really cool. And you have to definitely pay attention to both sides of the coin. How do I want to develop, and how's it going out after I'm done?
\n\nMIKE: There's no one right answer.
\n\nJP: No, no [laughs].
\n\nEDDY: Yeah, the takeaway, for me, so far, has been Git is much more vast than I initially thought it was, which is really cool.
\n\nJP: Git's simplistic in nature of what it's trying to record. So, it makes it a powerful technology.
\n\nMIKE: It follows the long history of Unix tools...
\n\nJP: [laughs]
\n\nMIKE: That are really good at one very specific thing so that they can be chained and used together. Even the fact that it uses the filesystem as its storage means that it lives within an ecosystem. You can swap out the file system; no big deal, right? In fact, you would likely have different developers on different file systems, and it's all okay [chuckles]. That is not a problem at all. It's intended to do a good job within its own little niche and never step outside that. If you need to step outside that, use another tool.
\n\nKYLE: I mean, that's ignoring the carriage return, right?
\n\nJP: [laughs] Hey, they fixed that too, Kyle [laughs].
\n\nMIKE: If any of our listeners don't know, different operating systems have historically created files that used different line endings. And trying to collaborate across different operating systems where [chuckles] they have different endings of your lines means that some people are going to have a carriage return, some people are going to have a line break, some people are going to have both. And having to merge those is potentially painful. And they've had to improve that cross-operating system handling overtime, partially by using some heuristics, say, you know what? I think you're on a Mac. I think I'm going to go with, let's say, carriage returns only, [chuckles], you know, and they just make some guesses.
\n\nEDDY: If you were to make a new utility to replace Git, what would be your approach to making it more predominant?
\n\nJP: I mean, all jokes aside, my first thing would be, what am I trying to fix? Because that's how you find not only your target audience but how you build the right technology. What does Git not solve for you right now? And I guess people have actually asked that question. And there are other tools out there. That's why GitHub exists. That's why GitLab exists and adds those additional feature sets.
\n\nMIKE: There is a modern version control system called Mercurial that has a niche following, that I think has a lot of these same features. But it's partially proprietary, and people are cheap. And one thing people like about open source, not always, but often, you can get it for free, as in beer, as well as free as in speech. And they like that free stuff.
\n\nEDDY: Is Mercurial, the one you are mentioning, open source?
\n\nMIKE: My understanding is that it was not, at least times in the past. Is it today?
\n\nJP: I don't know. I'm going to find out.
\n\nMIKE: It looks like it is today [inaudible 42:12]
\n\nJP: I keep finding people saying Mercurial is free. It does not say open source but free.
\n\nKYLE: GPL V2.
\n\nJP: That would be open-source
\n\nEDDY: For the listeners, open source and free are completely different.
\n\nJP: [laughs]
\n\nEDDY: And it did take me a bit to [laughter] [inaudible 42:30] when I first started to find that distinction.
\n\nMIKE: According to Wikipedia, which could be wrong [laughs], it says that Facebook uses Mercurial, Mozilla, the W3C.
\n\nEDDY: What is Mercurial trying to solve here? Like, what's its selling point?
\n\nMIKE: Another thing on the Wikipedia page says that Bitbucket dropped Mercurial support back in 2020 because less than 1% of new projects use it. So, it's one of those things that it may be solving lots of problems, but I don't have enough familiarity because I don't use it.
\n\nJP: Eddy, I'll ask you the same question in a different way: of why do people still write in COBOL?
\n\nKYLE: Because of our banking software.
\n\n[laughter]
\n\nEDDY: Because if you have a repository that is written on COBOL and trying to [inaudible 43:18] would be a [inaudible 43:21].
\n\nJP: Yes. I would say not only is, like, there's the cheap factor of software, but there's also the familiarity in the habits of software.
\n\nEDDY: Well, familiarity isn't really always a good thing because with technology always changing every single day --
\n\nJP: Then we end up with COBOL.
\n\n[laughter]
\n\nEDDY: It took me a few months to really get familiarized with Git. And to have to adopt a new technology just because someone has an itch [laughs] is not always fun.
\n\nMIKE: You know, Git it is a tool that has met a lot of people's needs, and I think it became popular because it worked [chuckles]. That doesn't mean that there are not other tools that work and may even be a little better. But it does a really good job. And any differences are just not enough for people to care about. And momentum is hard to beat. If you've got a tool that does the job for almost everybody, then it's going to get the attention. It's going to get the fixes. Eventually, it's going to get the features.
\n\nEDDY: So, I'm assuming Git is something that's widely used predominantly in the software industry, right?
\n\nMIKE: I honestly can't think of the last time I talked to somebody who wasn't using Git [laughs].
\n\nEDDY: So yes, listeners, I would say if you're wanting to become a developer, I would think familiarizing yourself with Git [chuckles] is crucial.
\n\nMIKE: My 11-year-old was asking me about Git the other day. It's that ubiquitous [laughs]. He ran into it independently, looking into Minecraft modding, I think. But the first answer he got is, "The first thing you need to do you need to set up a Git repository." [chuckles] And like, "Oh, can you tell me how to get set up with GitHub? What's GitHub?" [laughs]
\n\nJP: And then I would also say, not even just as a developer, if you're even a data engineer and you're looking to leverage tooling and other things out there, it can be very useful to know at least some of the fundamentals of Git in order to get your way around those tools and see how they work. Documentation has also made its way, like you were kind of hinting at, Mike, into the Git world. So, learning about that if you're doing any kind of technical documentation is also a really good place to be.
\n\nKYLE: Even more, like, layman tasks. My wife ran into it a while back. She has her website blog that she uses, and she was looking up how to modify one of her themes, and she needed to get something off of a Git repo. You know, it's kind of trending towards a common tool that everybody's going to have to know about, you know, even if you're just a writer, or in social work, or something, right? You don't have to be an engineer. It's out there. There's some obligations that you're going to find in Git.
\n\nMIKE: And I wouldn't say just a writer or just a social worker.
\n\nKYLE: Well, those -- [laughter]
\n\nMIKE: We provide value in different ways [laughter]. That does not --
\n\nKYLE: Yes. Yes. You're right. You're right. My bad.
\n\nMIKE: [laughs] Git is an amazing tool. Those of us who've been around for a while use some other tools. Most of us have deeply fallen in love with Git and how well it works for us. It's one of those things that just works. Anything that just works is wonderful. Whether you're maintaining your social work documentation, or whether you're writing code, or whether you're doing something exotic, I can't think of [laughs] that it's amazing using Git.
\n\nIt's a tool that generally just works. It helps me to understand what's going on, to understand what it can do and what it can't do, and to go back in time. That actually is a feature, not a bug. And it allows you to work with other people well. If you haven't used it yet, give it a try. Collaborate [laughs]. We'll talk to you next time on the Acima Development podcast.
","summary":"","date_published":"2024-02-28T12:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/b7e6df1d-3975-4c82-b5fc-0af26b9b5336.mp3","mime_type":"audio/mpeg","size_in_bytes":29842630,"duration_in_seconds":2825}]},{"id":"f6640176-a67f-4cc6-b708-82a8f04dbd1e","title":"Episode 39: Software Development and Music","url":"https://acima-development.fireside.fm/39","content_text":"The panel explores the connection between programming and music. To begin, Mike shares how his passion for music influenced his career switch from molecular biology to software development, and each panelist reveals their musical experiences, ranging from choir participation and band membership to a keen interest in diverse music genres and car audio systems.\n\nThe discussion then delves into the similarities between music and software development, focusing on how both are forms of human-centric communication and creative expression. They discuss the importance of comprehensible coding for human understanding rather than for machine processing and draw parallels in communication styles and improvisational aspects of both fields.\n\nThe episode also features a live interactive segment on the integration of music and software, through the use of Sonic Pi. This tool demonstrates the practical blending of coding and music creation, exemplifying the tangible overlaps between these two creative domains.\n\nTranscript;\n\nMIKE: Hello, and welcome to another episode of the Acima Development podcast. A lot of times, we go with more technical topics, and it's still a technical topic today but taking a different approach than we often do. Today, we're going to talk about the overlap between programming and music. If you've been in software for very long, you've probably noticed there's an odd overlap there, where there are a lot of people [chuckles] in software who do music. \n\nI am Mike. I'm hosting today. And we've got a panel with us today. We've got Justin, Eddy, Kyle, Dom, Ramses. I know I do music. In fact, little known fact, I'm actually the one who recorded the music that we play in the intro for the podcast [laughs]. I'm somebody who enjoys music, and I have enjoyed music for many years. Actually, it was music that got me into software in the first place. I was originally going to go into a career in biology, molecular biology, genetics, work on plant genetics, and do that with my life. I kind of made a change in direction [laughs] way back when. \n\nAnd what kind of got me going in that direction was that I loved music. I thought about going in that direction. And I thought, you know what? If I go into software, maybe I can apply that to some of the music stuff. And I remembered, hey, wait, I really love this [laughs]. I had done software when I was younger, and I remembered how much I enjoyed it, and I stuck with it, and it became my career. \n\nMusic has taken more of the backburner [laughs] in the years since. But if not for music, I probably would not have gone into software in the first place. I very much have a story with music. So, I'm going to ask each of our panelists here, Justin, do you make music?\n\nJUSTIN: [laughs] I've been in the music scene, but I am a singer. I'm actually a member of a choir, about 100 people. We go on tour. Like, last year, we went to Ireland and England, and we sang in London in the St. Paul Cathedral. It was a really cool experience. And I have a performance here in a couple of weeks for Christmas, so lots of stuff there. My wife...you may hear a piano playing in the background here in a little bit because my wife teaches piano. Basically, every afternoon, there's, like, piano students shuffling in and out.\n\nMIKE: So, that answer was yes. \n\nJUSTIN: Yes [laughter]. It's a long answer. Sorry.\n\nMIKE: Very much yes. Eddy, tell us about you and music.\n\nEDDY: So, I actually used to be in a band in high school. We formulated a group called [SP] Guitarchestra. And it basically is what it sounds like, right? Every member in that group played guitar. We played different sections. You know, we played backup, and some people would play melodies. Some people would play the chord progressions, et cetera. \n\nAnd it was an interesting approach because initially, when you think of a band, you would always think of, like, piano, and trumpets, and drums. And, you know, it was an interesting take at the time. We're talking about, like, 10-plus years ago, probably a little over where it was still kind of fresh to say, \"Yeah, the whole band is comprised of just guitar.\" We even took it a bit further, and we decided to do purely acoustic. We determined that acoustic had a more pleasant sound with what we were going for. So, not to go too deeply into it unless we want to, but yes, to a degree, I do have some background in music.\n\nMIKE: Again, that's not just a little bit of a yes, right? But a big yes [laughs]. Dom, actually, I have no idea if you do music [laughs].\n\nDOM: I'll be the first short, yes. I was never super musically inclined as a kid. I guess the recorder is about as far as I ever went in, like, fifth grade. I could play pretty mean Hot Cross Buns, so I'm going to keep it real. \n\nMIKE: [laughs]\n\nDOM: But I'm an avid enjoyer to listening. I listen to music all day, every day, pretty much whatever. People always ask me like, \"What's your music taste?\" And, you know, it's super basic to be like, \"I listen to everything.\" But you should check out my playlist. It goes from, like, hardcore gangster rap over to some, like, classic rock, maybe some country in there, throw in some Bach. It's pretty wild. But yeah, it's definitely a big part of my life, even though I can't play anything. I wish I could.\n\nEDDY: Dom, you should listen to Ramses' playlist, man. You'd have a blast.\n\nDOM: I bet. I'm open to whatever.\n\nMIKE: And this thinking here it's not universal, right? Not everybody who does software development does music, but there's a lot. Kyle, what about you?\n\nKYLE: I'm going to have to mimic Dom quite a bit, basically everything he said, for the most part. Anything that I really focused on music-wise was in high school and a little bit of college. I did a little bit of DJing, and then I had a big interest in car audio for the longest time. I've kind of grown out of that a little bit, but stereo systems were my thing.\n\nEDDY: What's car audio? \n\nKYLE: [laughs]. Yeah, dude, I've done a few car audio systems for replacing and wiring of the speakers and the head unit, subs, capacitors, amplifiers, all that jazz. You get the little amp for your speakers up front and a big amp for the big boys in the back, a couple of twelves, a couple of tens.\n\nMIKE: So, what about you, Ramses?\n\nRAMSES: I have a bit of experience with music and making music for the, like, last ten years or something, but it's been less two or three years, you know, a larger emphasis on development currently.\n\nMIKE: But you're a creator. Just thinking about the sample size, we've got one, two, three, four, five, six people here. And of those six, the majority, not, like, 1% or 25%, but we've got, what, 4 out of 6 people who have played publicly, right? [laughs] Who have done music in their adult lives. I haven't looked at the statistics, but that seems disproportionate. And it's been that way.\n\nDOM: Does karaoke count?\n\nMIKE: [laughs]\n\nDOM: I rock some mean karaoke.\n\nMIKE: Well, you know, why not? I actually have a lot of thoughts about music. I think it's really unfortunate, actually, the way that music is often taught, particularly, like, classical performance, because we teach people to perform somebody else's music. Can you imagine if we taught writing that way? Like, okay, we're going to teach you to be a writer. And what you're going to do is you're going to take this essay over here, and you're going to copy it over here. And make sure you copy it exactly. Don't make any spelling mistakes. Any spelling mistakes means you're not a very good writer because good writing means that you're copying very well with this other essay. \n\nYou take that to its conclusion, and it's ridiculous. But it's very much how music is often taught, you know, you learn to play with other people. It's kind of neither here nor there. But [laughs] I do think that those of us who are in music should work very hard to be more inclusive. And when music is taught, I think that it should be taught with performance and improvisation in mind as much. You know, it's kind of an equal peer to reading music and learning to perform music. \n\nIn fact, when I teach my kids, that's exactly what I do [chuckles]. We divide the time in half, literally in half. They set a timer, and they spend half their time improvising and the other half learning to play because there is some value in learning. If you want to be a writer, you better be a good reader [laughs], and I think the same thing applies to music. \n\nEDDY: When you teach your kids, do you teach them how to read notes or how to read tabs or, like, a mix of both? Like, how do you approach? \n\nMIKE: Yeah, great question. They haven't been that interested in guitar. They have been interested in piano. My daughter has a little bit of interest in violin, and for that, she's just kind of played by ear a little bit, definitely no note reading for that. For the piano, I have taught them to read sight music to learn to read music notes. You don't play tab on the piano. But I have no objection to tab.\n\nTo give another take here, I think that tablature sometimes gets a little bit of scorn. It's like, well if you want to be a true musician, you have to be able to read traditional European notation. Well, traditional European notation wasn't always traditional, and I think it was created in the Renaissance era. And people had to create it then, and they invented it as just a useful technique to communicate with each other. And tablature was invented in the same way. It's just a notation technique. I have no objection to that. I think that we should actually lean into communicating well and use the notation that works best for the instrument we're playing. Oh, there's my take on it. What was your thoughts on that?\n\nEDDY: Well, I initially...when I first picked up guitar, I taught myself mostly just because I was interested in the art of playing with strings in general. And I always enjoyed the sound. I thought it was always soothing and such. And so, I thought...as a kid, it's kind of hard to teach yourself how to read music, especially since internet was dial-up at the time. So, it was extremely hard, you know. Also, we shared a landline for internet, too. \n\nMIKE: [laughs]\n\nEDDY: So, we had to split, like, home phone and internet. It was another time. Regardless, the easiest approach for me was to download tablature for guitar, and it just made more sense. It was less of a curve, like, a steep curve, to learn because each note correlates to a placement in the guitar versus the note itself. So, I'm quite fond of it. But I do understand, like, it doesn't teach you very much technique as far as, like, if there's a half note versus a whole note. \n\nMIKE: Well, I think that's actually a good tie back into our topic because we're talking about software development. So far, we've pretty much talked exclusively about music. And I'm going to ask a question here: Who do we write code for?\n\nRAMSES: Humans mostly.\n\nJUSTIN: [laughs] In general?\n\nMIKE: I [inaudible 09:42] for a reason. Go ahead, Justin.\n\nJUSTIN: I mean, basically, companies employ coders to write solutions for their business problems. And, you know, that can take a variety of different languages and such. But I think, you know, when you talk about it that way, oftentimes, you're writing code in exchange for dollars and gainful employment. I have a feeling you're talking a little bit deeper.\n\nMIKE: Well, let's start here. So, you said paid us to solve problems. I think a lot of times we think that we're writing code for the computers, right? We're telling the computers what to do, and so we write code. But computers don't speak code. Computer processors have a set of inputs that take, you know, electronic, you know, signals. It's on or off. And we often think about that as zeros and ones. And in the early days of computing, they used the zeros and ones, either with switches or the punch cards; you know, they talked like a computer. And we don't do that anymore. \n\nI got this idea, I think, from Dave who sometimes has hosted here. He says that we don't write code for computers, and I think he's right. We use languages that are written for humans, and then we run it through a compiler or an interpreter in order to convert it over to something that a computer can understand. We don't use notation that would be the most useful for computers. We use notation that will be most effective for us to understand. That is an important realization [laughs] as a coder. It means that getting it to work isn't really your goal. Getting something comprehensible so future you [laughs] or your co-workers, whoever it is, can come back and understand it. \n\nWe write code so that humans can comprehend it, not so computers can comprehend it. And music notation [chuckles], likewise, you know, there's different styles of music notation. That's not written so that we can listen to music. It's written to communicate to humans so they can experience music together. Once again, there's kind of this convergence that there's goals, thinking about the goals of what we're doing. \n\nWe write music because we enjoy that human experience. We're notating it. We're not doing that because we want to prove our awesomeness. That's not why [laughs] we do so but because we want to share our experience with somebody. And we talk about tablature versus other forms of music notation. There's trade-offs, absolutely. They're both means of communication, so we can have that shared experience, much as computer code is.\n\nDOM: I just want to mention something you said a little bit earlier. But you said we're talking about different styles of notation for music. I've heard it word for word from somebody telling me about different languages that you can use the right tool for the job. It's like, why would you go out and build a whole application in some certain language when X language does a better job at doing that thing? That's kind of resonated with me, for sure. \n\nMIKE: Interesting. Because when we're writing code, we're writing it for people, but there's this deep, technical aspect to it. You're telling the machine what to do, and you have to create the structure accurately, or else your code is wrong. But the end audience isn't the computer. Versus when we notate music, we have to get it technically accurate. That paper, you know, that we're writing on is not the end audience. It's the humans who will then go and have that experience.\n\nEDDY: Is the equivalent of writing a blog in programming similar to music by playing the wrong note?\n\nMIKE: That's interesting, Eddy. Is it playing the wrong note? Is it notating the wrong note? It probably depends on the performance because a lot of music is never notated, right? A lot of live music it's ephemeral [laughs]. There is no persistent notation that captures it. There may be a recording. And, absolutely, there are wrong notes and some styles of music; maybe that so-called wrong note ends up becoming part of the music, right? \n\nRAMSES: That's jazz for you. \n\nMIKE: [laughs] Exactly. And very deliberately gets worked in the music, and it depends on how jarring it is, and sometimes people choose to embrace it. Much as in our code, sometimes a bug becomes a feature, a happy accident. This act of creating a representation of our thinking has this huge overlap between creating music and writing code. I would argue that maybe that is some of why there seems to be so much overlap between musicians and coders. \n\nWhy do you all think, just given the sample set? Like, I think it's pretty random sampling [laughs]. We have a lot of people who are avid musicians as well as coders, a majority. Why do you all think that there's overlap between people who code and people who write music or make music? \n\nEDDY: Kind of funny how, on one field, copying and pasting isn't plagiarism but rather a common occurrence. And on the other side of the [inaudible 14:29], copying and pasting can get you in trouble. So, there is an interesting dichotomy.\n\nMIKE: Well, that's interesting because it can get you in trouble if you wholesale lift it completely. When you copy somebody's style, you're totally fine, right? In fact, it's expected, and we've got genres that people seek out because they have a similar style. And there's a gray area as to how much of that borrowing is okay. \n\nBob Dylan wrote a number of years ago...I believe it's called Love and Theft. And in that, without telling anybody, he heavily borrowed his lyrics from, like, a 19th-century poet. And right in the title, he mentions theft and then didn't tell anybody. I remember it caused a bit of a stir when people noticed it. \n\nI think people mostly got over it, and they realized that he's probably doing it on purpose, this big easter egg for people to go in there and find. He's kind of exploring the boundary, what counts as plagiarism because musicians borrow from each other all of the time. And particularly in the folk tradition, they quote pretty much verbatim from other singers. They maybe add their own tweaks to it. And that's how we got a lot of our musical heritage.\n\nJUSTIN: All of the AI compositioning that is going on right now, you look at it, it's trained with existing corpus of music all across, you know, the world, you know. It can certainly use anything older than the copyright period, you know, as part of the training, and it can get a lot of the open-source stuff right now, and all that's completely legal. And so, you got to ask yourself, hey, is it real, or is it just what we do anyway?\n\nEDDY: There have been, like, lawsuits, and court hearings about ownership of music and, like, the way music is written. And I think we've pretty much determined that, like, you cannot own notes [chuckles] and chords, right? Like, that's just not possible. But maybe the way the sequence of those notes, you know, can. And I think to some degree, development, you know, and coding is applicable. If you copy and paste something from Stack Overflow, that's okay, right? Because it's free. Everyone can get it; not a big deal. But if you get your hands on, like, the codebase, you know, of a company, then suddenly, that's plagiarism.\n\nMIKE: And those boundaries aren't as rigid as we might hope, or maybe it's nice that they're not so rigid. We've got social convention that drives that. It's not inevitable that we have copyright law be what it is today [chuckles]. It's just simply not, either for software, for music. \n\nAnd there's been a, you know, proprietary software was kind of king for a long time. And the open-source movement has changed that where a lot of our most fundamental tools like our operating systems, you know, Linux, which runs Android, which runs most of the servers out there [chuckles] is open source. But there's still a lot of proprietary software out there. They live side by side often and maybe, usually, side by side in the same companies, you know, kind of filling different roles. \n\nAnd copyright law (I don't know for music.), you know, it's also gone through different directions. I don't want to get into a debate over copyright law [laughs], but it's a complicated area. And those social conventions can change over time. Have you all thought some about open-source music? I actually have thought a lot about this. But is this something that any of you have thought at length about?\n\nJUSTIN: Yeah, what we're doing today, we're programming music. We can open source it, versus, you know, I think a lot of...there's a lot of copyright-free (I'm doing little air quotes.) copyright-free on YouTube and other platforms that you can use for whatever. And so, it's like, you know, is this code that we're going to go code, are we going to open source it, or are we going to just say it's ours? You know, it's all these things that we got to decide.\n\nMIKE: To make those decisions [chuckles], you start getting into all this ethics. And sometimes you think, oh, I'm just [inaudible 18:32] coder. I don't want to think about that. Or I'm just a musician; I don't have to think about that. But it suffuses kind of everything we do. And it's inescapable that you have to make some of these decisions. And it's not necessarily very clear. And the people who say that they have all of the answers are probably leaving a lot out.\n\nFor example, we all love to get music and to listen to music, and we all kind of wish that it was all free. It seems really problematic to have a lot of our shared cultural heritage locked up and for the purpose of making some corporation money somewhere. I think that all kind of makes us a little queasy. \n\nBut on the flip side, how do the artists get paid if not by putting some restrictions on their work? So, that artificially limiting copying, which is essentially free nowadays, artificially limiting that and forcing people to pay for it. And I'm [inaudible 19:19] to have the answers. Much like the debate in the open-source community versus closed source, there are some questions that have a lively debate, and I think can and should continue to have a lively debate because there are multiple parties involved, and they have different needs. But we've talked a lot about some of the overlap. Anybody else have any other thoughts about why musicians and developers often overlap? \n\nKYLE: One thing that I was thinking about as you guys were talking about, like, chords and written music, is it makes me wonder because, like I said, I've not really done a lot of music myself, but I've known people, dual majors in, like, Spanish and English lit or, you know, that know multiple languages. They tend to also like to know multiple programming languages. And how much is music, you know, is it just another language? Is it just something else to learn, some other way of communicating that people just tend to enjoy? \n\nMIKE: The people love to communicate, and good communicators make good coders. \n\nKYLE: Yeah, it's one of those that, you know, you're drawn to more of those universal languages, right? At least in my experience, you know, the more popular languages they are popular for a reason, you know, say what you will about, like, Java and stuff, but it's a popular language. I mean, that's cross-regional. And how often is music cross-regional? I mean, everybody can listen to music. You don't have to understand the language that it's sung in or, you know, I mean, even if it's vocal, I mean, you don't have to understand the language to enjoy it.\n\nEDDY: And just like a software app, you don't necessarily need to understand the ins and outs of, like, how it's architected behind the scenes to enjoy the app, right? Much like merchant portal.\n\nMIKE: We build software, yeah. And you don't see much of it behind the scenes, but you get to use it as a utility. I don't know if we always think about the utility of music. It has social utility. It brings us together as people. It lets us share emotions with each other. We find it useful, if only for our enjoyment.\n\nLet's take this a little bit further. As Justin alluded to, there are tools out there that crosses boundary between software and music. I have a couple of tools that I had in mind, and we're going to try one out here in a minute. The first one that came to my mind was LilyPond. Has anybody else here used LilyPond before? Ooh, LilyPond is awesome [laughs]. \n\nIt's an open-source tool, and it's written in Scheme, I believe, you know, a Lisp variant, which is very good for recursion and thinking about nested things, yeah, LilyPond. It's a fantastic tool for notating music. It does support tablature, by the way. So, if you want to notate music, I'd recommend to anybody LilyPond, particularly if you're a developer. I've shared it with some people who weren't developers, and they're like, \"Huh, I don't know.\"\n\n[laughter]\n\nJUSTIN: We use MuseScore a lot. You are probably familiar with that already. It looks like it's very similar to LilyPond. But it's nice, and the fact that you can, I mean, it integrates well with a mini keyboard and things like that.\n\nMIKE: The thing about LilyPond, like, the default mode is you write code. It has its own, you know, little domain-specific language where you write note names and durations. And you can nest them in staves, and, you know, it's built up around music notation. If you ever want to...I've used it quite a bit over the years, and I've really enjoyed it. So, there's one thing that I've used. But there are other ways of expressing music. What tools have you all used that cross the boundary between coding and music creation?\n\nDOM: I mean, there's GarageBand. I don't know how much coding you can get into in GarageBand. I never dove into that aspect of it. It's always just been, like, different layers of recording and things.\n\nEDDY: Has anyone heard of Guitar Hero? \n\nRAMSES: Oh yeah. \n\nEDDY: Okay. So, there's a huge community out there. It's still active today, right? Where we found out that we didn't want to be restricted to only the songs that they've licensed for the game, right? So, we, as a community, did an open-source project called Clone Hero. And essentially, you can modify the game and develop the charts yourself in order to compose the music to correlate with the sound, right? \n\nAnd suddenly, it became huge, and everyone became invested into this open-source project that I think is amazing. So, that's the closest I've ever had as an overlap, I would say, where you see the passion of a project, right? And suddenly, you [inaudible 24:00] other tasks, like, be confined, you know, into some sort of project in order to do it. So...\n\nMIKE: Well, that's totally legit [laughs]. That's absolutely the same kind of thing. What kind of notation is used for those charts?\n\nEDDY: It's just circles, like, colored circles coming down on a highway chart where you have --\n\nMIKE: Got it. [crosstalk 24:20] build those. How do you build those? Because I'm assuming you don't take a crayon and [laughs]...have you built any of these yourself?\n\nEDDY: I have, yeah. I have actually posed a couple of those.\n\nMIKE: What sort of format do you...again, because I'm assuming you're not using a crayon. What do you use to find what those circles are going to be? \n\nEDDY: That's kind of interesting. They may have modified it since, right? But it's software that you have to download. You essentially choreograph the placement of the note manually, and you get a timeline, essentially, of the audio and you [inaudible 25:01] matching.\n\nMIKE: Got it.\n\nEDDY: Definitely no crayons.\n\nMIKE: [laughs] No crayons. But at some point, it's a representation of time, right? \n\nEDDY: Yes.\n\nMIKE: Of time distribution and pitch over, you know, what frets [laughs] you're going to be playing on and duration, which is a kind of encoding, which is what we've been talking about all along. \n\nSo, there's this cool project; it's called Sonic Pi. It's been around for years. It's actually been, like, this labor of love for a long time. Boy, I probably first used this, I have to think about this, 7-10 years ago [laughs]. So, this has been a project that has been around for a long time. And it's free. You can download it. I think it's community-supported. You can probably donate money. Shout out here if, you know, maybe give some money to the developers in this project. And it's often used for education. And it's just a tool where you get to do live music creation. \n\nMy understanding is that there are DJs who use this for their shows, so it's not just an educational tool. It can actually be used for music generation in real-world settings. And the scripting language that you use inside of it is Ruby. We're mostly Rubyists here, certainly not exclusively, but there's a lot of Rubyists here. We will brush against Ruby now and again, at least [laughs], and Sonic Pi lets you do that. \n\nOne thing about a podcast is you can't show the visuals. As we're recording this, we're looking at each other's faces. But we just extract the audio stream and push that up. So, we can't really show you what we're doing. But there's...I'll give you an idea of what's going on. Sonic Pi is this tool that lets you just start writing [laughs], and it says, \"There are no mistakes. There are only interesting accidents [laughs].\" It's kind of what we said before. There's not exactly bugs. There's things that might not suit your inclination, so you change it. \n\nI have a relatively new laptop. I didn't have a recent copy of Sonic Pi. I downloaded it, like, 10 minutes before we started our podcast recording. And I just went through the tutorial they've got and threw together some stuff, you know, in a few minutes and put in some loops. So, let me play what I did [chuckles]. There's no claim to greatness in music. But I just want you to see what kind of things you can do in 10 minutes in a tool like this.\n\n[playing music]\n\nSo, I did a few things here. I just did a loop, and this is straight out of the demo. This is just the bass drum [chuckles]. Looped that eight times. Sixteen times, I do another loop where I play some other sounds, including the drum. And then I end with a kind of a trailing sound at the end. \n\nWhat we should do is we should play around with this a little bit. And this is pretty much just from the tutorial. I changed a couple of different sample names, but this is out-of-the-box behavior [laughs]. No brilliance from Mike. And it sounds like music, just with that little bit of time. And I thought, you know, I haven't even tried this. I was going to see what happens if I threw an offset and bass drum in there with a slightly different rate. And I don't even know what's going to happen. Do we see?\n\n[playing music]\n\nThere you go. It's different.\n\nEDDY: Mike, I'm curious: can you use methods?\n\nMIKE: Absolutely.\n\nEDDY: Interesting. \n\nMIKE: So, that is interesting. Should we write one? \n\nEDDY: Yes, let's.\n\nMIKE: Let's see what happens if we replace our bass drum here with a method.\n\n[playing music]\n\nThere we go. Methods work great.\n\nEDDY: Can we do loops?\n\nMIKE: We can, and you may have noticed that it's already doing loops. And, additionally, and I may comment this out, it allows live loops. Let's try it. We press the run button. And we can stop it. Although with it still running, we should be able to change this. \n\nRAMSES: Does the live loop just allow you to modify the code while it's running? Is that the idea? \n\nMIKE: That's the idea. We're going to do our bass drum again. This is straight from the demo. [playing music]. So, what if we want to change the rate of our drum? So, let's see. [playing music] No change there. [playing music] There we go. I kept the duration of the sounds that's getting clipped. [playing music] Okay. What would you have me change? Do you want me to change the tempo? \n\nDOM: I like the total tempo right now. I think adding some complementary snares will really help the composition of our piece.\n\nMIKE: Let's do it. [playing music] So, I would say that that kind of overrode the bass drum a little bit. What if we change that a little bit? So, I'm going to add in a snare [playing music]. It works. \n\nEDDY: Can we add a cymbal? \n\nMIKE: Yeah, let's do it. Let's think about how we would do this. So, first thing, we've got our bass drum, right? It pauses an eighth note and then plays our snare. And then it's going to pause for a half note minus an eighth note. So, I think what we want to do here is...let's think about it. Do we want it exactly on the same positions as our bass drum? And then we sleep for an eighth note. We play our snare drum, right? And then, let's sleep for another eighth note. That will get us to our quarter, play our cymbal again. So, I don't think I've quite got this worked out to full quarter notes yet, but we've got a little bit. Let's what we've got. First take. [playing music] There we go. \n\nEDDY: That's really cool. \n\nMIKE: Yeah, and then we can start adding in more sounds, right? We can start adding in stuff right in the background. Let's add in ambient dark whoosh.\n\n[playing music]\n\nYou get some rhythm in there.\n\n[playing music]\n\nCool. And we wrote some code, and we made some music.\n\nEDDY: I actually [inaudible 32:13] kind of interesting. I went ahead and shared external examples of people who have actively developed [inaudible 32:20] some code. I thought it would be interesting to kind of hear some examples of what you can accomplish with people who have taken presumably hours trying to get the right sequence.\n\nMIKE: Okay, cool. So, we can try one of these examples. Let's give it a try, shall we? [playing music] Nice. Writing music using code. So, we've had some fun [laughs]. We started by talking about some of that overlap between the musicians and coders, some of our background [laughs], and then put it to work, you know, talking about some of these tools.\n\nI'm going to go back to something I said a little bit before about creation. This is all fun. And [chuckles] you might think, oh, it's just fun. Well, I am not going to do that. Well, something that I found in software development, and this has come up before in our podcast, and it's going to come up over and over again, is that communication is vital for successful software development. It's come up in this session [chuckles]. Communication is so central to what we do. We're communicating with a computer, communicating with each other. Much of what we do is maybe...almost everything what we do involves communication. \n\nPlaying around with something like this might not seem very important, but developing shared communication together is one of the most important things that we can accomplish together as a team. You know [laughs], I'd invite anybody who listens to this to...it's maybe a little silly [chuckles] but, you know, to go spend a little time and play around with it but not alone. Here's my invitation, that you go and do it with somebody like we just did. The music that we've made together, I think, was a lot better than we would have gotten alone. \n\nAny parting words that any of you would like to add before we end our session today? \n\nDOM: Make sure to be on the lookout for the new Acima underground album featuring...\n\nMIKE: [laughs]\n\nDOM: Dirty Mike and the Boys. It's our new hit single. It's going to be awesome. \n\nMIKE: [laughs] Thanks for the shout-out, Dom. Be on the listen for a future podcast session. \n\nEDDY: [laughs]\n\nMIKE: Great. Thanks again for listening to us on the Acima Development podcast. Until next time.","content_html":"The panel explores the connection between programming and music. To begin, Mike shares how his passion for music influenced his career switch from molecular biology to software development, and each panelist reveals their musical experiences, ranging from choir participation and band membership to a keen interest in diverse music genres and car audio systems.
\n\nThe discussion then delves into the similarities between music and software development, focusing on how both are forms of human-centric communication and creative expression. They discuss the importance of comprehensible coding for human understanding rather than for machine processing and draw parallels in communication styles and improvisational aspects of both fields.
\n\nThe episode also features a live interactive segment on the integration of music and software, through the use of Sonic Pi. This tool demonstrates the practical blending of coding and music creation, exemplifying the tangible overlaps between these two creative domains.
\n\nTranscript;
\n\nMIKE: Hello, and welcome to another episode of the Acima Development podcast. A lot of times, we go with more technical topics, and it's still a technical topic today but taking a different approach than we often do. Today, we're going to talk about the overlap between programming and music. If you've been in software for very long, you've probably noticed there's an odd overlap there, where there are a lot of people [chuckles] in software who do music.
\n\nI am Mike. I'm hosting today. And we've got a panel with us today. We've got Justin, Eddy, Kyle, Dom, Ramses. I know I do music. In fact, little known fact, I'm actually the one who recorded the music that we play in the intro for the podcast [laughs]. I'm somebody who enjoys music, and I have enjoyed music for many years. Actually, it was music that got me into software in the first place. I was originally going to go into a career in biology, molecular biology, genetics, work on plant genetics, and do that with my life. I kind of made a change in direction [laughs] way back when.
\n\nAnd what kind of got me going in that direction was that I loved music. I thought about going in that direction. And I thought, you know what? If I go into software, maybe I can apply that to some of the music stuff. And I remembered, hey, wait, I really love this [laughs]. I had done software when I was younger, and I remembered how much I enjoyed it, and I stuck with it, and it became my career.
\n\nMusic has taken more of the backburner [laughs] in the years since. But if not for music, I probably would not have gone into software in the first place. I very much have a story with music. So, I'm going to ask each of our panelists here, Justin, do you make music?
\n\nJUSTIN: [laughs] I've been in the music scene, but I am a singer. I'm actually a member of a choir, about 100 people. We go on tour. Like, last year, we went to Ireland and England, and we sang in London in the St. Paul Cathedral. It was a really cool experience. And I have a performance here in a couple of weeks for Christmas, so lots of stuff there. My wife...you may hear a piano playing in the background here in a little bit because my wife teaches piano. Basically, every afternoon, there's, like, piano students shuffling in and out.
\n\nMIKE: So, that answer was yes.
\n\nJUSTIN: Yes [laughter]. It's a long answer. Sorry.
\n\nMIKE: Very much yes. Eddy, tell us about you and music.
\n\nEDDY: So, I actually used to be in a band in high school. We formulated a group called [SP] Guitarchestra. And it basically is what it sounds like, right? Every member in that group played guitar. We played different sections. You know, we played backup, and some people would play melodies. Some people would play the chord progressions, et cetera.
\n\nAnd it was an interesting approach because initially, when you think of a band, you would always think of, like, piano, and trumpets, and drums. And, you know, it was an interesting take at the time. We're talking about, like, 10-plus years ago, probably a little over where it was still kind of fresh to say, "Yeah, the whole band is comprised of just guitar." We even took it a bit further, and we decided to do purely acoustic. We determined that acoustic had a more pleasant sound with what we were going for. So, not to go too deeply into it unless we want to, but yes, to a degree, I do have some background in music.
\n\nMIKE: Again, that's not just a little bit of a yes, right? But a big yes [laughs]. Dom, actually, I have no idea if you do music [laughs].
\n\nDOM: I'll be the first short, yes. I was never super musically inclined as a kid. I guess the recorder is about as far as I ever went in, like, fifth grade. I could play pretty mean Hot Cross Buns, so I'm going to keep it real.
\n\nMIKE: [laughs]
\n\nDOM: But I'm an avid enjoyer to listening. I listen to music all day, every day, pretty much whatever. People always ask me like, "What's your music taste?" And, you know, it's super basic to be like, "I listen to everything." But you should check out my playlist. It goes from, like, hardcore gangster rap over to some, like, classic rock, maybe some country in there, throw in some Bach. It's pretty wild. But yeah, it's definitely a big part of my life, even though I can't play anything. I wish I could.
\n\nEDDY: Dom, you should listen to Ramses' playlist, man. You'd have a blast.
\n\nDOM: I bet. I'm open to whatever.
\n\nMIKE: And this thinking here it's not universal, right? Not everybody who does software development does music, but there's a lot. Kyle, what about you?
\n\nKYLE: I'm going to have to mimic Dom quite a bit, basically everything he said, for the most part. Anything that I really focused on music-wise was in high school and a little bit of college. I did a little bit of DJing, and then I had a big interest in car audio for the longest time. I've kind of grown out of that a little bit, but stereo systems were my thing.
\n\nEDDY: What's car audio?
\n\nKYLE: [laughs]. Yeah, dude, I've done a few car audio systems for replacing and wiring of the speakers and the head unit, subs, capacitors, amplifiers, all that jazz. You get the little amp for your speakers up front and a big amp for the big boys in the back, a couple of twelves, a couple of tens.
\n\nMIKE: So, what about you, Ramses?
\n\nRAMSES: I have a bit of experience with music and making music for the, like, last ten years or something, but it's been less two or three years, you know, a larger emphasis on development currently.
\n\nMIKE: But you're a creator. Just thinking about the sample size, we've got one, two, three, four, five, six people here. And of those six, the majority, not, like, 1% or 25%, but we've got, what, 4 out of 6 people who have played publicly, right? [laughs] Who have done music in their adult lives. I haven't looked at the statistics, but that seems disproportionate. And it's been that way.
\n\nDOM: Does karaoke count?
\n\nMIKE: [laughs]
\n\nDOM: I rock some mean karaoke.
\n\nMIKE: Well, you know, why not? I actually have a lot of thoughts about music. I think it's really unfortunate, actually, the way that music is often taught, particularly, like, classical performance, because we teach people to perform somebody else's music. Can you imagine if we taught writing that way? Like, okay, we're going to teach you to be a writer. And what you're going to do is you're going to take this essay over here, and you're going to copy it over here. And make sure you copy it exactly. Don't make any spelling mistakes. Any spelling mistakes means you're not a very good writer because good writing means that you're copying very well with this other essay.
\n\nYou take that to its conclusion, and it's ridiculous. But it's very much how music is often taught, you know, you learn to play with other people. It's kind of neither here nor there. But [laughs] I do think that those of us who are in music should work very hard to be more inclusive. And when music is taught, I think that it should be taught with performance and improvisation in mind as much. You know, it's kind of an equal peer to reading music and learning to perform music.
\n\nIn fact, when I teach my kids, that's exactly what I do [chuckles]. We divide the time in half, literally in half. They set a timer, and they spend half their time improvising and the other half learning to play because there is some value in learning. If you want to be a writer, you better be a good reader [laughs], and I think the same thing applies to music.
\n\nEDDY: When you teach your kids, do you teach them how to read notes or how to read tabs or, like, a mix of both? Like, how do you approach?
\n\nMIKE: Yeah, great question. They haven't been that interested in guitar. They have been interested in piano. My daughter has a little bit of interest in violin, and for that, she's just kind of played by ear a little bit, definitely no note reading for that. For the piano, I have taught them to read sight music to learn to read music notes. You don't play tab on the piano. But I have no objection to tab.
\n\nTo give another take here, I think that tablature sometimes gets a little bit of scorn. It's like, well if you want to be a true musician, you have to be able to read traditional European notation. Well, traditional European notation wasn't always traditional, and I think it was created in the Renaissance era. And people had to create it then, and they invented it as just a useful technique to communicate with each other. And tablature was invented in the same way. It's just a notation technique. I have no objection to that. I think that we should actually lean into communicating well and use the notation that works best for the instrument we're playing. Oh, there's my take on it. What was your thoughts on that?
\n\nEDDY: Well, I initially...when I first picked up guitar, I taught myself mostly just because I was interested in the art of playing with strings in general. And I always enjoyed the sound. I thought it was always soothing and such. And so, I thought...as a kid, it's kind of hard to teach yourself how to read music, especially since internet was dial-up at the time. So, it was extremely hard, you know. Also, we shared a landline for internet, too.
\n\nMIKE: [laughs]
\n\nEDDY: So, we had to split, like, home phone and internet. It was another time. Regardless, the easiest approach for me was to download tablature for guitar, and it just made more sense. It was less of a curve, like, a steep curve, to learn because each note correlates to a placement in the guitar versus the note itself. So, I'm quite fond of it. But I do understand, like, it doesn't teach you very much technique as far as, like, if there's a half note versus a whole note.
\n\nMIKE: Well, I think that's actually a good tie back into our topic because we're talking about software development. So far, we've pretty much talked exclusively about music. And I'm going to ask a question here: Who do we write code for?
\n\nRAMSES: Humans mostly.
\n\nJUSTIN: [laughs] In general?
\n\nMIKE: I [inaudible 09:42] for a reason. Go ahead, Justin.
\n\nJUSTIN: I mean, basically, companies employ coders to write solutions for their business problems. And, you know, that can take a variety of different languages and such. But I think, you know, when you talk about it that way, oftentimes, you're writing code in exchange for dollars and gainful employment. I have a feeling you're talking a little bit deeper.
\n\nMIKE: Well, let's start here. So, you said paid us to solve problems. I think a lot of times we think that we're writing code for the computers, right? We're telling the computers what to do, and so we write code. But computers don't speak code. Computer processors have a set of inputs that take, you know, electronic, you know, signals. It's on or off. And we often think about that as zeros and ones. And in the early days of computing, they used the zeros and ones, either with switches or the punch cards; you know, they talked like a computer. And we don't do that anymore.
\n\nI got this idea, I think, from Dave who sometimes has hosted here. He says that we don't write code for computers, and I think he's right. We use languages that are written for humans, and then we run it through a compiler or an interpreter in order to convert it over to something that a computer can understand. We don't use notation that would be the most useful for computers. We use notation that will be most effective for us to understand. That is an important realization [laughs] as a coder. It means that getting it to work isn't really your goal. Getting something comprehensible so future you [laughs] or your co-workers, whoever it is, can come back and understand it.
\n\nWe write code so that humans can comprehend it, not so computers can comprehend it. And music notation [chuckles], likewise, you know, there's different styles of music notation. That's not written so that we can listen to music. It's written to communicate to humans so they can experience music together. Once again, there's kind of this convergence that there's goals, thinking about the goals of what we're doing.
\n\nWe write music because we enjoy that human experience. We're notating it. We're not doing that because we want to prove our awesomeness. That's not why [laughs] we do so but because we want to share our experience with somebody. And we talk about tablature versus other forms of music notation. There's trade-offs, absolutely. They're both means of communication, so we can have that shared experience, much as computer code is.
\n\nDOM: I just want to mention something you said a little bit earlier. But you said we're talking about different styles of notation for music. I've heard it word for word from somebody telling me about different languages that you can use the right tool for the job. It's like, why would you go out and build a whole application in some certain language when X language does a better job at doing that thing? That's kind of resonated with me, for sure.
\n\nMIKE: Interesting. Because when we're writing code, we're writing it for people, but there's this deep, technical aspect to it. You're telling the machine what to do, and you have to create the structure accurately, or else your code is wrong. But the end audience isn't the computer. Versus when we notate music, we have to get it technically accurate. That paper, you know, that we're writing on is not the end audience. It's the humans who will then go and have that experience.
\n\nEDDY: Is the equivalent of writing a blog in programming similar to music by playing the wrong note?
\n\nMIKE: That's interesting, Eddy. Is it playing the wrong note? Is it notating the wrong note? It probably depends on the performance because a lot of music is never notated, right? A lot of live music it's ephemeral [laughs]. There is no persistent notation that captures it. There may be a recording. And, absolutely, there are wrong notes and some styles of music; maybe that so-called wrong note ends up becoming part of the music, right?
\n\nRAMSES: That's jazz for you.
\n\nMIKE: [laughs] Exactly. And very deliberately gets worked in the music, and it depends on how jarring it is, and sometimes people choose to embrace it. Much as in our code, sometimes a bug becomes a feature, a happy accident. This act of creating a representation of our thinking has this huge overlap between creating music and writing code. I would argue that maybe that is some of why there seems to be so much overlap between musicians and coders.
\n\nWhy do you all think, just given the sample set? Like, I think it's pretty random sampling [laughs]. We have a lot of people who are avid musicians as well as coders, a majority. Why do you all think that there's overlap between people who code and people who write music or make music?
\n\nEDDY: Kind of funny how, on one field, copying and pasting isn't plagiarism but rather a common occurrence. And on the other side of the [inaudible 14:29], copying and pasting can get you in trouble. So, there is an interesting dichotomy.
\n\nMIKE: Well, that's interesting because it can get you in trouble if you wholesale lift it completely. When you copy somebody's style, you're totally fine, right? In fact, it's expected, and we've got genres that people seek out because they have a similar style. And there's a gray area as to how much of that borrowing is okay.
\n\nBob Dylan wrote a number of years ago...I believe it's called Love and Theft. And in that, without telling anybody, he heavily borrowed his lyrics from, like, a 19th-century poet. And right in the title, he mentions theft and then didn't tell anybody. I remember it caused a bit of a stir when people noticed it.
\n\nI think people mostly got over it, and they realized that he's probably doing it on purpose, this big easter egg for people to go in there and find. He's kind of exploring the boundary, what counts as plagiarism because musicians borrow from each other all of the time. And particularly in the folk tradition, they quote pretty much verbatim from other singers. They maybe add their own tweaks to it. And that's how we got a lot of our musical heritage.
\n\nJUSTIN: All of the AI compositioning that is going on right now, you look at it, it's trained with existing corpus of music all across, you know, the world, you know. It can certainly use anything older than the copyright period, you know, as part of the training, and it can get a lot of the open-source stuff right now, and all that's completely legal. And so, you got to ask yourself, hey, is it real, or is it just what we do anyway?
\n\nEDDY: There have been, like, lawsuits, and court hearings about ownership of music and, like, the way music is written. And I think we've pretty much determined that, like, you cannot own notes [chuckles] and chords, right? Like, that's just not possible. But maybe the way the sequence of those notes, you know, can. And I think to some degree, development, you know, and coding is applicable. If you copy and paste something from Stack Overflow, that's okay, right? Because it's free. Everyone can get it; not a big deal. But if you get your hands on, like, the codebase, you know, of a company, then suddenly, that's plagiarism.
\n\nMIKE: And those boundaries aren't as rigid as we might hope, or maybe it's nice that they're not so rigid. We've got social convention that drives that. It's not inevitable that we have copyright law be what it is today [chuckles]. It's just simply not, either for software, for music.
\n\nAnd there's been a, you know, proprietary software was kind of king for a long time. And the open-source movement has changed that where a lot of our most fundamental tools like our operating systems, you know, Linux, which runs Android, which runs most of the servers out there [chuckles] is open source. But there's still a lot of proprietary software out there. They live side by side often and maybe, usually, side by side in the same companies, you know, kind of filling different roles.
\n\nAnd copyright law (I don't know for music.), you know, it's also gone through different directions. I don't want to get into a debate over copyright law [laughs], but it's a complicated area. And those social conventions can change over time. Have you all thought some about open-source music? I actually have thought a lot about this. But is this something that any of you have thought at length about?
\n\nJUSTIN: Yeah, what we're doing today, we're programming music. We can open source it, versus, you know, I think a lot of...there's a lot of copyright-free (I'm doing little air quotes.) copyright-free on YouTube and other platforms that you can use for whatever. And so, it's like, you know, is this code that we're going to go code, are we going to open source it, or are we going to just say it's ours? You know, it's all these things that we got to decide.
\n\nMIKE: To make those decisions [chuckles], you start getting into all this ethics. And sometimes you think, oh, I'm just [inaudible 18:32] coder. I don't want to think about that. Or I'm just a musician; I don't have to think about that. But it suffuses kind of everything we do. And it's inescapable that you have to make some of these decisions. And it's not necessarily very clear. And the people who say that they have all of the answers are probably leaving a lot out.
\n\nFor example, we all love to get music and to listen to music, and we all kind of wish that it was all free. It seems really problematic to have a lot of our shared cultural heritage locked up and for the purpose of making some corporation money somewhere. I think that all kind of makes us a little queasy.
\n\nBut on the flip side, how do the artists get paid if not by putting some restrictions on their work? So, that artificially limiting copying, which is essentially free nowadays, artificially limiting that and forcing people to pay for it. And I'm [inaudible 19:19] to have the answers. Much like the debate in the open-source community versus closed source, there are some questions that have a lively debate, and I think can and should continue to have a lively debate because there are multiple parties involved, and they have different needs. But we've talked a lot about some of the overlap. Anybody else have any other thoughts about why musicians and developers often overlap?
\n\nKYLE: One thing that I was thinking about as you guys were talking about, like, chords and written music, is it makes me wonder because, like I said, I've not really done a lot of music myself, but I've known people, dual majors in, like, Spanish and English lit or, you know, that know multiple languages. They tend to also like to know multiple programming languages. And how much is music, you know, is it just another language? Is it just something else to learn, some other way of communicating that people just tend to enjoy?
\n\nMIKE: The people love to communicate, and good communicators make good coders.
\n\nKYLE: Yeah, it's one of those that, you know, you're drawn to more of those universal languages, right? At least in my experience, you know, the more popular languages they are popular for a reason, you know, say what you will about, like, Java and stuff, but it's a popular language. I mean, that's cross-regional. And how often is music cross-regional? I mean, everybody can listen to music. You don't have to understand the language that it's sung in or, you know, I mean, even if it's vocal, I mean, you don't have to understand the language to enjoy it.
\n\nEDDY: And just like a software app, you don't necessarily need to understand the ins and outs of, like, how it's architected behind the scenes to enjoy the app, right? Much like merchant portal.
\n\nMIKE: We build software, yeah. And you don't see much of it behind the scenes, but you get to use it as a utility. I don't know if we always think about the utility of music. It has social utility. It brings us together as people. It lets us share emotions with each other. We find it useful, if only for our enjoyment.
\n\nLet's take this a little bit further. As Justin alluded to, there are tools out there that crosses boundary between software and music. I have a couple of tools that I had in mind, and we're going to try one out here in a minute. The first one that came to my mind was LilyPond. Has anybody else here used LilyPond before? Ooh, LilyPond is awesome [laughs].
\n\nIt's an open-source tool, and it's written in Scheme, I believe, you know, a Lisp variant, which is very good for recursion and thinking about nested things, yeah, LilyPond. It's a fantastic tool for notating music. It does support tablature, by the way. So, if you want to notate music, I'd recommend to anybody LilyPond, particularly if you're a developer. I've shared it with some people who weren't developers, and they're like, "Huh, I don't know."
\n\n[laughter]
\n\nJUSTIN: We use MuseScore a lot. You are probably familiar with that already. It looks like it's very similar to LilyPond. But it's nice, and the fact that you can, I mean, it integrates well with a mini keyboard and things like that.
\n\nMIKE: The thing about LilyPond, like, the default mode is you write code. It has its own, you know, little domain-specific language where you write note names and durations. And you can nest them in staves, and, you know, it's built up around music notation. If you ever want to...I've used it quite a bit over the years, and I've really enjoyed it. So, there's one thing that I've used. But there are other ways of expressing music. What tools have you all used that cross the boundary between coding and music creation?
\n\nDOM: I mean, there's GarageBand. I don't know how much coding you can get into in GarageBand. I never dove into that aspect of it. It's always just been, like, different layers of recording and things.
\n\nEDDY: Has anyone heard of Guitar Hero?
\n\nRAMSES: Oh yeah.
\n\nEDDY: Okay. So, there's a huge community out there. It's still active today, right? Where we found out that we didn't want to be restricted to only the songs that they've licensed for the game, right? So, we, as a community, did an open-source project called Clone Hero. And essentially, you can modify the game and develop the charts yourself in order to compose the music to correlate with the sound, right?
\n\nAnd suddenly, it became huge, and everyone became invested into this open-source project that I think is amazing. So, that's the closest I've ever had as an overlap, I would say, where you see the passion of a project, right? And suddenly, you [inaudible 24:00] other tasks, like, be confined, you know, into some sort of project in order to do it. So...
\n\nMIKE: Well, that's totally legit [laughs]. That's absolutely the same kind of thing. What kind of notation is used for those charts?
\n\nEDDY: It's just circles, like, colored circles coming down on a highway chart where you have --
\n\nMIKE: Got it. [crosstalk 24:20] build those. How do you build those? Because I'm assuming you don't take a crayon and [laughs]...have you built any of these yourself?
\n\nEDDY: I have, yeah. I have actually posed a couple of those.
\n\nMIKE: What sort of format do you...again, because I'm assuming you're not using a crayon. What do you use to find what those circles are going to be?
\n\nEDDY: That's kind of interesting. They may have modified it since, right? But it's software that you have to download. You essentially choreograph the placement of the note manually, and you get a timeline, essentially, of the audio and you [inaudible 25:01] matching.
\n\nMIKE: Got it.
\n\nEDDY: Definitely no crayons.
\n\nMIKE: [laughs] No crayons. But at some point, it's a representation of time, right?
\n\nEDDY: Yes.
\n\nMIKE: Of time distribution and pitch over, you know, what frets [laughs] you're going to be playing on and duration, which is a kind of encoding, which is what we've been talking about all along.
\n\nSo, there's this cool project; it's called Sonic Pi. It's been around for years. It's actually been, like, this labor of love for a long time. Boy, I probably first used this, I have to think about this, 7-10 years ago [laughs]. So, this has been a project that has been around for a long time. And it's free. You can download it. I think it's community-supported. You can probably donate money. Shout out here if, you know, maybe give some money to the developers in this project. And it's often used for education. And it's just a tool where you get to do live music creation.
\n\nMy understanding is that there are DJs who use this for their shows, so it's not just an educational tool. It can actually be used for music generation in real-world settings. And the scripting language that you use inside of it is Ruby. We're mostly Rubyists here, certainly not exclusively, but there's a lot of Rubyists here. We will brush against Ruby now and again, at least [laughs], and Sonic Pi lets you do that.
\n\nOne thing about a podcast is you can't show the visuals. As we're recording this, we're looking at each other's faces. But we just extract the audio stream and push that up. So, we can't really show you what we're doing. But there's...I'll give you an idea of what's going on. Sonic Pi is this tool that lets you just start writing [laughs], and it says, "There are no mistakes. There are only interesting accidents [laughs]." It's kind of what we said before. There's not exactly bugs. There's things that might not suit your inclination, so you change it.
\n\nI have a relatively new laptop. I didn't have a recent copy of Sonic Pi. I downloaded it, like, 10 minutes before we started our podcast recording. And I just went through the tutorial they've got and threw together some stuff, you know, in a few minutes and put in some loops. So, let me play what I did [chuckles]. There's no claim to greatness in music. But I just want you to see what kind of things you can do in 10 minutes in a tool like this.
\n\n[playing music]
\n\nSo, I did a few things here. I just did a loop, and this is straight out of the demo. This is just the bass drum [chuckles]. Looped that eight times. Sixteen times, I do another loop where I play some other sounds, including the drum. And then I end with a kind of a trailing sound at the end.
\n\nWhat we should do is we should play around with this a little bit. And this is pretty much just from the tutorial. I changed a couple of different sample names, but this is out-of-the-box behavior [laughs]. No brilliance from Mike. And it sounds like music, just with that little bit of time. And I thought, you know, I haven't even tried this. I was going to see what happens if I threw an offset and bass drum in there with a slightly different rate. And I don't even know what's going to happen. Do we see?
\n\n[playing music]
\n\nThere you go. It's different.
\n\nEDDY: Mike, I'm curious: can you use methods?
\n\nMIKE: Absolutely.
\n\nEDDY: Interesting.
\n\nMIKE: So, that is interesting. Should we write one?
\n\nEDDY: Yes, let's.
\n\nMIKE: Let's see what happens if we replace our bass drum here with a method.
\n\n[playing music]
\n\nThere we go. Methods work great.
\n\nEDDY: Can we do loops?
\n\nMIKE: We can, and you may have noticed that it's already doing loops. And, additionally, and I may comment this out, it allows live loops. Let's try it. We press the run button. And we can stop it. Although with it still running, we should be able to change this.
\n\nRAMSES: Does the live loop just allow you to modify the code while it's running? Is that the idea?
\n\nMIKE: That's the idea. We're going to do our bass drum again. This is straight from the demo. [playing music]. So, what if we want to change the rate of our drum? So, let's see. [playing music] No change there. [playing music] There we go. I kept the duration of the sounds that's getting clipped. [playing music] Okay. What would you have me change? Do you want me to change the tempo?
\n\nDOM: I like the total tempo right now. I think adding some complementary snares will really help the composition of our piece.
\n\nMIKE: Let's do it. [playing music] So, I would say that that kind of overrode the bass drum a little bit. What if we change that a little bit? So, I'm going to add in a snare [playing music]. It works.
\n\nEDDY: Can we add a cymbal?
\n\nMIKE: Yeah, let's do it. Let's think about how we would do this. So, first thing, we've got our bass drum, right? It pauses an eighth note and then plays our snare. And then it's going to pause for a half note minus an eighth note. So, I think what we want to do here is...let's think about it. Do we want it exactly on the same positions as our bass drum? And then we sleep for an eighth note. We play our snare drum, right? And then, let's sleep for another eighth note. That will get us to our quarter, play our cymbal again. So, I don't think I've quite got this worked out to full quarter notes yet, but we've got a little bit. Let's what we've got. First take. [playing music] There we go.
\n\nEDDY: That's really cool.
\n\nMIKE: Yeah, and then we can start adding in more sounds, right? We can start adding in stuff right in the background. Let's add in ambient dark whoosh.
\n\n[playing music]
\n\nYou get some rhythm in there.
\n\n[playing music]
\n\nCool. And we wrote some code, and we made some music.
\n\nEDDY: I actually [inaudible 32:13] kind of interesting. I went ahead and shared external examples of people who have actively developed [inaudible 32:20] some code. I thought it would be interesting to kind of hear some examples of what you can accomplish with people who have taken presumably hours trying to get the right sequence.
\n\nMIKE: Okay, cool. So, we can try one of these examples. Let's give it a try, shall we? [playing music] Nice. Writing music using code. So, we've had some fun [laughs]. We started by talking about some of that overlap between the musicians and coders, some of our background [laughs], and then put it to work, you know, talking about some of these tools.
\n\nI'm going to go back to something I said a little bit before about creation. This is all fun. And [chuckles] you might think, oh, it's just fun. Well, I am not going to do that. Well, something that I found in software development, and this has come up before in our podcast, and it's going to come up over and over again, is that communication is vital for successful software development. It's come up in this session [chuckles]. Communication is so central to what we do. We're communicating with a computer, communicating with each other. Much of what we do is maybe...almost everything what we do involves communication.
\n\nPlaying around with something like this might not seem very important, but developing shared communication together is one of the most important things that we can accomplish together as a team. You know [laughs], I'd invite anybody who listens to this to...it's maybe a little silly [chuckles] but, you know, to go spend a little time and play around with it but not alone. Here's my invitation, that you go and do it with somebody like we just did. The music that we've made together, I think, was a lot better than we would have gotten alone.
\n\nAny parting words that any of you would like to add before we end our session today?
\n\nDOM: Make sure to be on the lookout for the new Acima underground album featuring...
\n\nMIKE: [laughs]
\n\nDOM: Dirty Mike and the Boys. It's our new hit single. It's going to be awesome.
\n\nMIKE: [laughs] Thanks for the shout-out, Dom. Be on the listen for a future podcast session.
\n\nEDDY: [laughs]
\n\nMIKE: Great. Thanks again for listening to us on the Acima Development podcast. Until next time.
","summary":"","date_published":"2024-02-14T12:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/f6640176-a67f-4cc6-b708-82a8f04dbd1e.mp3","mime_type":"audio/mpeg","size_in_bytes":20638501,"duration_in_seconds":2092}]},{"id":"ccba595d-b3f7-4b2e-80a8-f6466ec40d6e","title":"Episode 38: Burnout and Work-Life Balance","url":"https://acima-development.fireside.fm/38","content_text":"The panelists discuss work-life balance and avoiding burnout. Mike shares his personal experience of burnout from continuous long hours at startups and the positive impact of transitioning to a four-day workweek, which surprisingly increased productivity. The group identifies factors contributing to burnout, such as excessive workload, lack of autonomy, and value misalignment with the company. They explore symptoms of burnout, including diminished interest, difficulty focusing, and physical symptoms like headaches.\n\nThe conversation also touches on strategies for preventing burnout, emphasizing the importance of setting boundaries, disconnecting from work, and prioritizing tasks. They discuss how a supportive work environment, where employees have autonomy and their values align with the company's, can help mitigate burnout. The podcast acknowledges that sometimes, leaving an unhealthy work environment might be the best solution for avoiding burnout.\n\nTranscript:\n\nMIKE: Hello, and welcome to another episode of the Acima Development podcast. I'm Mike. I will be hosting again today.\n\nToday, we have with us Eddy, Ramses, and Tad. You can probably tell, if you're listening to this, by the title that [chuckles] today we're going to be talking about work-life balance and avoiding burnout. \n\nSo, I'm going to start with a very personal story on this one. About, I don't know, ten years ago, I was at a startup, but not the first startup I've been at [laughs]. I had been at kind of a series of startups, where I had put in a lot of hours. And I realized that the work wasn't motivating me the way that it used to do. I felt, you know, the obligation to get the work done. But I just... it was harder and harder to focus. And I didn't enjoy it the way I once enjoyed it. I mean, coding is fun [laughs], and it just wasn't anymore. \n\nI started thinking about career changes, thinking about...in my free time, I thought about a lot of things, and they weren't work [chuckles], and that said something. Some context: I had been working at a baseline of about 50 hours a week, and sometimes up to 70-80 hours a week, not usually, but, you know, I'd put in a lot of hours, probably averaged around 60, and I had done it for years. \n\nI had worked at one place where I was the lead and sometimes the only engineer keeping things together. And this was in the days before DevOps, so [chuckles] not only did you do the engineering, you also kept the systems up. And, you know, there was, like, a data center you had to go to fix things [laughter] in case the servers went down. \n\nTAD: Unlock the rack, pull up the little cards, the keyboard, and the monitor around it, put things in.\n\nMIKE: Yeah, KVM keyboard. We did that [laughs]. I did that. [inaudible 01:50] I didn't have to go to the data center very often. But I did that, that, you know, kind of run the show thing for a lot of years. So, I went for multiple years where I didn't have any meaningful vacation. I took off one or two days here or there, and that was it. In fact, I took two days off once and I remember it feeling like the biggest vacation I'd had in, well, in years. I pulled it off. I did it. But there's a point when you start to question, even if it's not even conscious. My body was telling me maybe this isn't the right answer. \n\nAnd I suggested...I'd been reading about the four-day workweeks that some companies were going to. And we had a team meeting, and the manager I had said, \"You know, if there was anything you could have, you know, anything that you would change, what would it be?\" And I said, \"You know, what? Working less. What if we tried this four-day workweek thing?\" And he said, \"Okay.\" \n\nAnd he went and got approval from the company, and, like, the next week, we did it. So, kudos to [SP] Mutch, by the way. If you ever happen to listen to this, thank you [laughs]. That was awesome. I'm still very grateful for having such an excellent, you know, partner in things. But we did that, and we did that for quite some time, actually. I did that for probably a couple of years there. \n\nAnd here's the thing, this is the thing: we measured our output and story points. And you know what happened? It went up. It went up. It wasn't just me working four days a week. It was the entire team. We were a relatively small team. We had six or eight people, something like that. But our productivity went up. Our consistency went up, and we consistently delivered. And we were all happier. \n\nSo, I went from working 50 to 80 hours a week to working 32 to 40, and the productivity went up. It was a profound moment to see that sometimes, working harder does not make everything better or push the work forward. And killing yourself, you know, perhaps literally killing yourself with the stress and all that time and taking time away from things that are also important in life, was not particularly effective to getting more done. \n\nNow, I don't want to be misconstrued as saying [chuckles] that over no timeframe that additional work can't be helpful. Everybody who's been to college has probably stayed up late studying, stayed up for a test the next day, or finishing a paper, or finishing a coding project if you're a coder, myself included [laughs], sometimes all night for a couple of nights. But that's over a very small, fixed time interval after which it ends. And over longer time horizons, that becomes less and less effective. \n\nI've seen some research that was a big to-do...probably between 15 or 20 years ago, probably closer to 15, about somebody named...well, somebody whose pseudonym was EA_Spouse. You can look it up: EA_Spouse, EA underscore spouse. When there was a spouse of a developer at EA Games, who wrote an open letter about how their spouse was being mistreated and overworked. For some reason, it went viral, and a lot of people commented on it. \n\nAnd one of the things that came out of that was there was some research done in physical world manufacturing, not in modern information industries but back when people were working more with their bodies. (So, you could arguably debate that it doesn't quite apply, but I suspect it does.) that they measured overtime. So, they had one group of people work 60 hours a week, and one group of people work 40 hours a week. \n\nAnd they found that, initially, the people working extra hours had more productivity. But by about six weeks, the productivity was equal. So, after six weeks, the people who'd been working 60 hours a week for those six weeks had no more output, and their cumulative output was no greater. Their cumulative output was no greater than people who had worked 40 all that time. And [laughs], wow, right? \n\nImagine you're that poor group that worked 60 hours a week, only to realize you've accomplished nothing more than the people who just worked normal hours. That really resonated with me, and I've thought about it a lot in the years since. And I think about the four-day workweek. I worked the four-day workweek for several years. [inaudible 06:00] the Acima Development podcast, my first few years at Acima, I was a contractor, and I actually worked four-hour weeks, and eventually, I came on full time. \n\nAnd in order to work well with the rest of the team, I've shifted away from four-day workweeks because my burnout had healed [laughs, and I was back and loving my job again. But I know that risk is there, you know, I know that I can destroy myself. So, I've made very conscious effort in the years since to be very careful about how I spend my time. When I'm done with work, I turn it off, and I do something else. \n\nAnd I've learned that it has not affected my productivity. In fact [chuckles], if anything, I think I've done very well. I've done very well in the years since and have been able to be very successful. And part of that I ascribe, actually, to a willingness to maintain a boundary and say, \"This is where work stops.\" I have an office. And when I'm done with my workday, I leave my office, and I go and I spend time with my family. But maybe I'll do other things sometimes, too. But, you know, I leave my office, and I go and do something else. And then, when the next day comes, I go into my office, and I work hard. \n\nThere are times when I do think it's appropriate to put in some extra time. There's times where there's an urgent project, and you put in that time to get that done. But if those are anything other than the exception, I think it not only is going to be the cause of a poor personal experience, but it won't actually help. When those long hours become the rule rather than the exception, they tend to actually be counterproductive. \n\nAnd I'm speaking from anecdotal personal experience, though we did measure, you know, over a team. But there's also research backing that, that maintaining this balance and getting away from burnout is beneficial not only to individual health but to the company health, that we're able to contribute more because we're able to bring our whole selves in. \n\nAnd it's interesting. I don't think we're necessarily personally aware that our productivity is going down when we're overworked. It's as much as a person who's intoxicated has a hard time being introspective and recognizing they're intoxicated, or a person who's been sleep deprived has a hard time recognizing. And they might know that they're sleepy, but it's hard to do cognitive introspection. You don't see that your productivity is going down. It [chuckles] inhibits your ability even to be self-aware. So, regardless of whether you think you're being less productive, if you're putting those kinds of hours, you probably are.\n\nI think that there are probably some cheats, to some degree, to get you past some of those things. I know that there's some people in Silicon Valley who do, like, mindfulness meditation to find some break between things and then return to work. But there are human limits. At some point, you've got to take that break. And refusal to acknowledge those limits doesn't mean they're not there. As much as I can refuse to acknowledge that gravity affects me, but if I jump from a high place, my refusal to acknowledge its existence [laughs] is not going to make it go away. \n\nI have kind of strong feelings about this one because I think it's important. I think that developers should be, and everybody should be treated with respect. And particularly knowing that overworking people doesn't get the job done better [chuckles] leads me to argue pretty passionately that we should be treating people well, not only for their own sake but for the health of the project and the company. We do better when we give people reasonable hours of work. What thoughts does this bring up in y'alls mind? What do you think?\n\nTAD: A couple of questions that I'm curious about from you guys is, what does burnout look like? And are there other factors besides workload that contribute to burnout? Because workload is an obvious one, right? And that's what you're talking about, Mike. But I can think of other factors that would contribute to me feeling burned out, even if I'm working just a regular 40-hour week. So, those are a couple of questions for you guys. And I'm curious to see what you guys think.\n\nEDDY: I feel like we need to find what the symptoms of burnout is first, right? Maybe fatigue, like, cognitive thought goes down, et cetera. Like, maybe we can engage the room and see, like, what other people's opinion is on the symptoms to burnout. \n\nTAD: Like, just a lack of interest, right? You're like, I know I should care about what I'm doing right now, but I just can't bring myself to care enough. And I'm going to force myself and [SP] pinery, and I'll push through this. But, oh my gosh, this is a slog because I feel so indifferent right now to what I'm doing. That's something that I experience when I'm feeling burnt out. \n\nMIKE: That's really well put. And related to that, focus becomes extremely difficult. Think about intrusive thoughts. Whenever you've had intrusive thoughts, something that you keep thinking about, well, that happens to you because instead of your mind staying on it, your mind wants to go somewhere else. You lose the ability to have the kind of focus you need. \n\nAnd for software development, you need focus. It's important. It's a very focus-driven endeavor, and inability to keep your mind on it...you think, okay, I'll go for a walk, whatever it is that you do. You know, I'll go and read an article, whatever it is, you know, we all have our own things that you do to go and clear your head just because it's working.\n\nEDDY: For me, it's headaches. If I'm staring at the screen for too long or whatever, my head starts hurting. It starts throbbing a bit, and I have to stand up, you know, walk away. \n\nMIKE: It's interesting. You have to look for those things, that, you know, lost self-awareness. It's really hard to do a self-analysis. So, you have to kind of look for those things. Wait, why am I getting so many headaches? \n\nTAD: I think it's potentially harder for us because we train ourselves to tune things out and to focus, right? That's part of the job. That's part of the skill set is: I need to be able to put the blinders on and set my mind to a task. And if I'm really into something, I'll forget. I'm like, oh shoot, I should have eaten lunch, like, an hour ago, right? Which is a sign that I was doing a good job of focusing but a terrible job of being self-aware of my body's promptings, right?\n\nEDDY: So, what adds burnout? I think workload, like you said, Tad. I think that's where most of us go, right? Like, instinctively [laughs].\n\nMIKE: It's not all of it, right? \n\nEDDY: Yeah.\n\nTAD: I know that if I have this possibility for something, but I haven't been given the ability or the power to accomplish it, then that puts me in this burnout spiral, right? Like, if they're like, \"Oh, there's a very important deadline you have to meet this Friday. You have to get it done.\" And you're like, \"But the API isn't even ready yet.\" I've just coded against vapor. And I don't have the power to change that, right? Like, the responsibility without the power to accomplish what you're responsible for that disconnect often just makes me stressed and burned out, right? There's, like, a control-responsibility balance that I need.\n\nRAMSES: In hindsight, I don't know if that would be necessarily your responsibility. It's, like, the product manager's responsibility. You do what you can do, and, you know, if it's not delivered on time, that's their problem. \n\nTAD: But I've been in a situation where I was working at a startup, and they say, \"You got to take this data and build these graphs from this data.\" And I said, \"That's impossible to do.\" Like, the data just it's not the sort of data that you can graph in that manner, right? And my manager said to me, \"You're a smart guy. You'll figure it out. I need this done by Friday.\" And Friday came, and the data hadn't changed. \n\nMIKE: [laughs]\n\nTAD: The requirements hadn't changed. And I still I'm, like, you can try to match this data to this graph, but it's nonsense, right? It just isn't the right graph for the data. And that's just burnout, right? That's just stress. And --\n\nEDDY: I feel like some of that responsibility does fall to the individual, too, right? I think we need to be able to be expressive when we feel that the deadline is unrealistic. So, like, part of that is imposed by management, like, product managers [inaudible 14:34] and such. But I think as a developer, you also need to be pretty conscious about that and be expressive if you feel it's unrealistic.\n\nMIKE: Well –-\n\nTAD: Yeah. And if they say, \"You're a smart guy; you'll figure it out,\" then --\n\n[laughter]\n\nMIKE: So, that goes to your...you had mentioned...You didn't use this word, autonomy. I was going to say the same thing. You know, anytime that...and I've seen...I don't have it in front of me, though I've read about this in the past. That's the thing they mention first [chuckles]. It's often mentioned first is, when you don't have autonomy, when you have demands that you have no personal control over, autonomy or agency kind of related words, if that's taken away, it causes stress. And those are the kinds of things that lead most to burnout. \n\nAnd it says something to management that [chuckles] it's their job to provide agency and autonomy to their employees. Give people the opportunity to do what they want to do, that is, to do their job, right [chuckles]? I don't mean the autonomy to decide to go on a three-year vacation but [chuckles]—maybe in some places—but the autonomy to choose how the work gets done. And that means listening. \n\nWhen you say, \"This is what I think the requirements are,\" and the developer says, \"Well, what is the reason that you have those requirements?\" And they say, \"Well, I'm trying to solve this problem.\" And the developer says, \"Well, I can think of this way to solve the problem. It doesn't quite meet those requirements, but it solves the problem.\" Now you've had a conversation. You've done what was really requested, was solving that problem rather than meeting a set of rigid requirements.\n\nIn the case you mentioned, Tad, \"Here's this data. I need to visualize it.\" If it had been brought to you in a different way, saying, \"I've got some data I need to visualize,\" that's a very different request because it steps back and has some humility, you know, some willingness to negotiate so that the problem gets solved. There's still a problem that needs to get solved. But solving the actual problem in healthy environments...I think we've spoken before about psychological safety. In healthy environments, interesting questions are celebrated and encouraged because they lead to better solutions. In unhealthy environments, there are demands made without any feedback. \n\nAnd this is related to the idea of Agile software development, which is all around communication, recognizing it's really hard, actually, to communicate about requirements. And if you try to come up with a bunch of requirements upfront, you'll probably get them wrong. So, instead, focusing on an iterative process where there's communication at every step, you tend to get better software.\n\nA prominent example is SpaceX. They're a physical world company that tries to run things like a software company, and they do this iterative development. And they've just dominated that industry recently because that process works. It works. The heavy communication, the tight feedback loops, where the communication is kind of the center of the cycle rather than documenting rigid requirements. Well, the same thing applies to your manager. You need to have that communication loop. And if management is not communicating, they say, \"Here's our requirements. Get this done,\" then you end up with a project that runs over budget and over time, and nobody is happy. \n\nEDDY: You know, we're talking about burnout. And both Mike and Tad have mentioned that earlier in their careers, they dealt with burnout. And I can finally relate to that, and I don't know if that's a good or bad thing [laughter]. To give some context, you know, our group was assigned to accomplish not an easy feat. You know, it was a feature that needed to be out within, like, a month deadline.\n\nTAD: Yes.\n\nEDDY: And some of us found ourselves, you know, working extra hours, working over the weekend, you know, to make sure that we were meeting deadlines. And I found quickly that I was, towards the tail end of us meeting that deadline, and I found that we were missing, me personally, I was missing really simple syntax, you know, that was being called out on my peer reviews, right? \n\nThey're just like, \"Oh, Eddy, you forgot, you know, you misspelled this [inaudible 18:42].\" Oh, man. I'm like, I would have caught that any other time, right? But, like, when you're crunching and, like, you're in a tunnel vision, you know, you start missing really easy mistakes, right? And that's when I realized, I'm like, okay, after this is out, after this is in production, and there's something tangible that's working, I'm going to take a couple of days, relax --\n\nMIKE: As you should. \n\nTAD: Yeah, I find my brain is...they usually talk about, like, exercising your mind, like, working your mind. And this reminds me of...one time I was working at a company, and several of us were, like, \"Oh, Go sounds like a really interesting game. We should all teach ourselves how to play Go.\" And during our lunch hour, we would play Go against each other. \n\nAnd it's a very simple game, but you have to think really, really hard about it, right? You have to be like, okay, if he goes here, and I go here, and [vocalization]. And you have to take really many, many steps ahead. So, we'd do that over our lunch break, and then we'd get back to work. And we'd just be like, \"Ugh, I can't even, like, work. Like, I can't even focus on my code because this activity I did for an hour is exercising the same part of my brain as I was needing to write code. And I just can't bring my brain to do that still, right? Like, I need to find something different. I need to exercise a different part of my brain, right?\" Like, if I'm doing --\n\nEDDY: You need to stimulate your brain [inaudible 20:15]\n\nTAD: Yeah. Just, like, I'm doing left-brain activities, like, very intense. And I think Mike has mentioned, you know, go and listen to some music or play the piano, or, you know, interact socially, or things like that. That's an activity that's very different. And it lets that part of your brain rest and lets some other part of your brain, you know, take over and do something for a while. \n\nMIKE: My first manager in software grew roses. You got to have something different.\n\nEDDY: I play fetch with my dog because I have a backyard, sometimes.\n\nTAD: There you go. \n\nEDDY: And with us kind of transitioning over to winter, there is very less time you can do that now.\n\nMIKE: So, you need to find another outlet, you're saying? \n\nEDDY: Probably. Yeah, that sounds about right. \n\nMIKE: [laughs] So, we've talked a little bit about some of the things that lead to burnout, and we've mentioned the lost autonomy and then overwork. Anything else that any of you have experienced? You know, it doesn't even have to be necessarily work. You know, this can happen in school or other situations. \n\nTAD: Actually, I was mentioning, like you, you know, go interact with your family, things like that. Something that leads to burnout for me is isolation, where I'm just by myself. And there's been times in my career where it's...I've worked remote; I'm by myself. And the project I was given is, like, a three-month project or something like that, right? Where there's no one else I can talk to about the project. They're all doing their other things. It's just me and the project that's going to take three months. \n\nAnd it's hard for me to care as intensely on a three-month project by myself as if, you know, I'm pairing with somebody, or I get a break, or I get some kind of variety or something like that. So, it's...maybe I'm touching on some other things as well. But, for me, that isolation aspect, if it's just me by myself all day, every day for many months at a time, I start to feel it. And it's not a workload thing. It's just I miss the interaction with people. I miss being able to talk through some things. \n\nEDDY: So, that's why you go into the office is to avoid burnout [laughs]. \n\nTAD: Yeah, like, I come into the office so I can talk anime with you. And you heal my burnout, Eddy.\n\nEDDY: To the listeners out there, to avoid burnout for Tad, he likes to have conversations and go on tangents about anime [laughter].\n\nTAD: Because I know you're a huge fan. But I am someone that probably needs to pair more than maybe other developers. I've got a buddy who works for Google who his ideal situation would be he's in the forest in a glass box so that, like, you know, he's somewhat protected from the elements, but he could still see nature. And he would be able to do that all day, every day, for the rest of his life. \n\nHe doesn't need to talk to anybody. He doesn't need to have anyone check in on him. He would just sit in nature by himself. And he's content, right? He's fulfilled with just that. But if your needs aren't getting met, is when you hit burnout. And, for me, I have a social need that I need to take care of periodically, or else I get that fatigue and that burnout.\n\nEDDY: Change of scenery, Tad. I think that's awesome. It's a great idea. When you really mention it, anytime I do go physically in an office, since I do interact with more people to get that social stimulation in my brain, now that I'm thinking about it, it's very seldom that I do reach or hit burnout from the days when I do go to the office. \n\nI can't do this anymore. I have a backyard patio, and I have a bunch of trees, and I have a garden couch. The couch is designed to be outside. And I would sit down, stretch my legs because it's a long couch, right? And I'd sit back and, you know, recline a little bit. And I'd find myself just hearing the birds. Suddenly, that's kind of soothing.\n\nTAD: That's interesting because I have a spot on my balcony where I've set up a hummingbird feeder, and just going out on the balcony...every developer they get hung up on something and just kind of, like, stare off in the near distance and just kind of, like, ugh [laughs]. And just being able to watch the hummingbirds flit around while I do that has been beneficial for me. \n\nEDDY: The power of nature.\n\nMIKE: Are you familiar with the idea of forest bathing?\n\nTAD: I am, yes. \n\nMIKE: It is a Japanese idea. It's a practice of going to the forest, and it's not literal bathing of your body. It's kind of bathing of your mind. My understanding is it has been shown to be very therapeutic, nature, in particular, getting out of the office, outside into the woods and that glass box, wherever it is [laughs], someplace where you're exposed to somewhat unmodified [chuckles] universe around you. That could be the stars, right? Seeing non-human created environment changes you, and I don't have deep insight as to why that is, but I do have deep experience. That is very therapeutic for me. And I wonder if it's somewhat related to the socializing and that you're communing with the universe in some way.\n\nEDDY: I haven't necessarily done forest bathing, unless you consider listening to a soundtrack of a forest. That's what I've done before trying to fall asleep, you know, and I take my mind elsewhere. I will say, like, \"Hey, Alexa, play some sounds from the forest,\" you know, and just hearing birds chirping, and, like, the wind and trees being brushed and stuff like that, maybe it has a similar effect.\n\nMIKE: Why wouldn't it, right? [laughs] Whether it's visual or audio, it's all a similar experience. I was thinking, as were talking about isolation, in prisons, they will put somebody in solitary confinement sometimes. Sometimes, that's treated as punishment. And whether or not it's treated as punishment or just keeping somebody safe, I read that it's associated with severe negative effects on mental health. It's, in general, not good for people to be alone, and, usually, it doesn't result in very good software either, oh, not as good; I'll say that. You know, software, in general, is done better in a social context like most things.\n\nEDDY: You know, I'm pretty sure I've read something, like, a psychological somewhere a long time ago, where we've done studies that, actually, isolation is, actually, bad for individuals. And prolonged isolation does horrendous things to the body. I'm not saying that being a developer is coexisting with isolation [crosstalk 27:03].\n\nTAD: It makes you [inaudible 27:04] crazy?\n\nEDDY: [laughs] I'm not saying it makes you crazy, and it's relatable to prison. But --\n\nMIKE: Right. They're different in degree, for sure. And I don't want to diminish the suffering of somebody who's in that degree of isolation; rather, to give an example of an extreme case and the deep trauma it perpetrates against your mind. And in a much lesser degree, like with my experience at work, you know, could lead to burnout. \n\nEDDY: What are some of the actions or the things that you guys do while working to help productivity and also, in essence, avoiding burnout? I feel like some of us would say we listen to music. Anything else?\n\nMIKE: I can't listen to music while working. I love music. \n\nTAD: [laughs] --\n\nMIKE: And that's why I can't listen to music while working because I can't do both [laughs]. I used to do it when I was younger. And if I need to have deep focus, I cannot also have something else that is taking my focus. You know, some people have ambient music that they can pay less attention to. To me, that's hard. I'm somebody who likes to think about the structure of the music. \n\nPart of my experience of the music is maybe decomposing a little bit, thinking about the parts, thinking about the baseline, drums, you name it, or, you know, thinking about the harmonies or, like, oh, there's a key change, and kind of self-evaluating how it makes me feel. And with music I like, I'm going to go listen to it thinking about the lyrics, you know. I can't listen to music. It's stressful for me because it requires me to focus on two things at once. \n\nTAD: Would something like the sound of rain or, you know, the ocean or something like that where it's maybe got some pattern, but it's not really musical and that structured...To be a developer, a lot of times you have to have a very analytical mind. And I'm guessing that deconstructing music is kind of the same muscle as breaking down code and analyzing code. So, that's going to be competing in your mind, right?\n\nMIKE: You got a point. I bet I could listen to rain, and it would probably be fine and help push the other things away because it's close to white noise. It has a beautiful structure but one that's largely chaotic; you know, there's not a pattern that can distract. It's a good thought. Maybe I should give it a try.\n\nTAD: I've kind of been thinking about different things. Maybe there's a lot of things that cause burnout for me. But I was thinking about a startup I worked at, and their value proposition was all the other people in this industry take your data, analyze your data, sell your data, invade your privacy, you know, all these things, and we don't, right? And that was their sales pitch. And that was their special niche that they're like, we only sell your data if you want us to, you know, we could partner up. We'll sell it. We'll give you a little bit of a kickback. But by and large, we store it, encrypt it, and it's private, and all these things. \n\nAnd that was something that I really kind of believed in. And I'm like, yeah, like, people's privacy, and we don't sell their data. And I'm kind of proud that we're the only people in this particular segment of the industry that are doing that. Then, the company got sold to a much bigger company. And one of the first things they did is like, oh, yeah, we're going to make a ton of money by selling off analytics of everybody's data. \n\nAnd when those values shifted, so they didn't align with my values anymore, suddenly, my enthusiasm for my job just went way down. I'm like, oh, okay [laughs], we're doing the same things that everyone else is doing. And we're not cool and awesome and an ally for people. We're just exploiting people [laughs] like everybody else. And that probably caused some burnout for me, just because I didn't care. This isn't cool. This is just a job that I'm slogging through now. And it's kind of something I'm doing. And I don't necessarily love myself when I do this. It's causing friction against my personal values. \n\nSPEAKER: And I think that it happens with every change in management, when there's a big change in management and the philosophy changes. That's what happens because you are used to have the same vision. And it happened to me. I was working at a startup. And we were, like, disrupting the proptech ecosystem in Mexico. And there was a CEO, did something wrong, and they needed to replace him. \n\nAnd this guy was, like, a big person in the ecosystem. But it was an old guy, like, really married to how things were done 50 years ago, and he wanted to take the company back to that. And I was very happy on how we were disrupting. And when this person came, it's like, the whole happiness of me working there it was off.\n\nTAD: Would you say that caused burnout for you?\n\nSPEAKER: Yeah, it was like, oh, no more happiness when you wake up. And, you know, you don't feel like going to work. And it's like, oh, this guy is going to ask...what [inaudible 32:27] project is he going to ask now? [laughs]\n\nMIKE: Similar experience I had working for a company that got bought out. The company that bought us out started doing some things I found really shady. [laughs] And it bothered me more and more till one day I left [laughs]. At first, you know, things were fine. But as things got shadier, I got more and more uncomfortable; not just me, but the entire development team actually walked out. Not a good thing for your company, by the way, when your entire development team walks out [laughs]. Try to avoid doing shady stuff.\n\nTAD: [laughs] It sounds like values and culture are big factors, yeah. I'm actually able to handle a higher workload if I enjoy the people I'm working with and I believe in what I'm doing. \n\nEDDY: I hope I attribute to that.\n\nTAD: [laughs] Of course.\n\nEDDY: [laughs]\n\nMIKE: We've identified several things that cause burnout. And if these are the factors that cause burnout, what's the opposite of that? Because I think we can take practical steps to avoid each of those things. And I think that'd be a great way to round out our time here. And the first one we all jumped to was overwork. So, what did we do? \n\nRAMSES: I think you mentioned this earlier, Mike, but one of the main things, at least, I try to do, with my own work is set boundaries. I try not to work too much. I personally try to get up from my desk at least every hour. It's a little bit harder because my chair is so comfortable [laughter], so I can sit there all day. And then outside of work, I just try not to think about work too much; you know, I might be working on a problem in my head, but you just have to put it away until the next day. \n\nMIKE: You know, and our listeners don't know, but Ramses is a machine. He gets a ton of code written. Realize that when he's saying he takes breaks, that means he's exceptionally effective with the time he has. \n\nTAD: It feels like the Pomodoro thing sweeps through the software development community periodically, where you work for maybe 25 minutes, and then you take 5 minutes of break. And then you work for 25 minutes, and you take, like, 5 minutes of break. And in those 25 minutes, if something comes up, like, oh, that's a distracting thought, you could write it in a notebook, knowing you'll give yourself 5 minutes to address it later on. And you could free your brain from worrying about it, right? And I don't do that well, but there have been times where, you know, doing that kind of timeboxing has been effective for me. \n\nEDDY: Disconnecting from work, I think, is crucial to avoiding burnout. In certain occasions, I've wanted to uninstall Slack on my phone, on the weekends. It's one of those things where I instinctively check to make sure nothing's on fire. But you can't really disconnect from work if you always have that connection wherever you go. I actually hid the icon...\n\nMIKE: [laughs]\n\nEDDY: Somewhere else where I'm not used to looking for it as a way for me to...if I [inaudible 35:31] try to go for it, I have to go out of my way to find it. And then I catch myself, and I'm like, oh, okay, no, I shouldn't be checking it. So, I think disconnection from work I think it's important. And also, try to avoid thinking about stuff over the weekend.\n\nMIKE: And it's hard if you're on-call. You know, if you're responsible for a project, you have that obligation, but you can still timebox it. You can say, \"Well, you know, I need to check on this. So, I'm going to check it at...\" and you pick your time and then set it aside, unless there is an active push notification, you know, something that's pulling you in. And you can set up your notification preferences appropriately; you don't go back. There's more of that boundary setting. \n\nI get off work. I do have Slack on, you know, if somebody needs to get a hold of me or they text me. I put my phone in my pocket, and I walk away. Yeah, maybe I'll use my phone to read something, but I will walk away from my desk. And that willingness to walk away has made such a difference. I used to really struggle with that, having that boundary, having an edge. But I've learned that, you know, I need to if I want to be effective at either side of that [inaudible 36:35].\n\nEDDY: Early on, my wife would catch me on there, right? And she would be like, \"What are you doing?\" \"Oh, I'm just answering the message in Slack on my phone.\"\n\nTAD: [laughs]\n\nEDDY: And she's just like, \"Why? Aren't you off work?\" I'm like, \"Yeah, but I can provide input. Like, let me go ahead and do this.\" Eventually, like, she's like, \"Babe, like, you're off work. Distance yourself [inaudible 36:54]. They'll live without you until tomorrow.\" Imagine I wasn't on-call. \n\nMIKE: Well, and I schedule some time. I know that people might have some needs. So, I generally try to take 15 minutes to check Slack in the morning and in the evening, so I'm keeping, you know, a regular cadence. So, if people are stuck, I can do that. \n\nSometimes, in my current role [laughs], I have a lot of requests. I'm looking at 65 right now, and I recognize that it's not even possible for me to get to all of them. And you have to make a choice that you're going to be okay with that, that you can't get it all done. So, you have to prioritize and do what's most important, and then walk away. And that's really uncomfortable because I think we all want to do everything. And that recognition that we can't is hard but necessary. \n\nTAD: The hard thing is that answering people's questions, helping things out, I mean, that's part of your job, and that's part of the reward of doing your job. If you didn't enjoy that stuff, then you would have a different job. So, it's hard, but it's something that you enjoy where you get positive feedback from it. Like, if Eddy is on, you know, helping me out with something, I'll be like, \"Hey, Eddy. Thanks,\" you know, thumbs up, high-fives, and stuff like that. And it's hard to put that away sometimes.\n\nMIKE: And we have to remember that we're not an unlimited well. You can drain it dry. That water table has to be replenished. And if you're not in a healthy spot, it's hard to help anybody else out. There are finite boundaries. We absolutely should celebrate, I think, that willingness to help and also recognize that, you know, if you destroy that ability to help, you're not helping anybody, and those boundaries make a difference. \n\nLiving without boundaries will only destroy yourself, and that's a difficult thing to realize. The answer is no [laughs]. You can't do it all, so you have to choose, but vital. And the same thing applies in lots of different contexts. If your business can't do everything you'd like to do, you got to choose. And in our personal lives, we have to choose. You have to choose to do the things you can do within your allotted time and then be done. \n\nSo, there's a lot to be said for choosing wisely, spending your day saying, \"Well, these are the things I need to get done today. I'm going to work on the most important things first,\" or else you get to get the end of the day, and you're going to have that lost autonomy because you haven't done the most important things, and you're stressed out because they're not done. And you feel like they were taken away from you. But a lot of times, we do have some agency there. We can choose what we do first, and that, I think, goes a long way. \n\nEDDY: You mentioned something that kind of harmonized with me where you said, you have to be comfortable being uncomfortable with doing so, right? Well, I'm paraphrasing, and you said [inaudible 39:35]\n\nMIKE: I think you said it better than I did [laughs]. \n\nEDDY: The thing is, at least for me, it was a lot harder to do that early on in my transition to a developer. When I first started, and I'm going on five months now, it was really hard to disconnect because I really wanted to hit the ground running. I was pushing 200 miles per hour, trying to make sure that, like, no one made mistakes, and I'm providing the value that I said I would, so I'm not trying to make a liar out of anyone. \n\nBut the longer you go, you know, the more experience you get; I think it becomes easier to disconnect and be putting yourself in those uncomfortable situations. So, for anyone listening who's starting to transition or starting to get their foot in the door, just know that it gets easier the more experienced and more wise you grow. \n\nMIKE: It stays uncomfortable [laughs]; I can say that. But like you say, you become more mature at it and okay with it. You've made a conscious choice to embrace imperfection. A lot more gets done when it doesn't have to be perfect. So, we've talked about priorities and how vital it is to set priorities. That also helps some with autonomy. It helps with your time because it allows you to set those boundaries and give yourself some time. \n\nSo, boundary setting, prioritizing, and I don't know if there's much else to be said about the autonomy aspect because priorities has a lot to do with that. It was also mentioned that willingness to communicate is important, that when you see something you don't like, you say something. \n\nTAD: It's nice if you're safe saying something. \n\nMIKE: Yes. And that kind of yields the final point. If you're at a place where you don't have autonomy, when unethical things are happening around you or things that don't coincide with your values, and where you're being overworked, the answer is you probably need to leave. And, again, sometimes you just need to make that choice. Look around yourself and say, \"Well, this is not the right environment for me.\" And that's an okay decision. You'll live through it [laughs]. \n\nAnd maybe that's a good place to end today. We've talked about the problems. We've talked about the solutions. Thank you to everybody who's participated today. I think we had a great discussion. For our listeners, thank you for joining us again on the Acima Development podcast. You'll hear us next time.","content_html":"The panelists discuss work-life balance and avoiding burnout. Mike shares his personal experience of burnout from continuous long hours at startups and the positive impact of transitioning to a four-day workweek, which surprisingly increased productivity. The group identifies factors contributing to burnout, such as excessive workload, lack of autonomy, and value misalignment with the company. They explore symptoms of burnout, including diminished interest, difficulty focusing, and physical symptoms like headaches.
\n\nThe conversation also touches on strategies for preventing burnout, emphasizing the importance of setting boundaries, disconnecting from work, and prioritizing tasks. They discuss how a supportive work environment, where employees have autonomy and their values align with the company's, can help mitigate burnout. The podcast acknowledges that sometimes, leaving an unhealthy work environment might be the best solution for avoiding burnout.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development podcast. I'm Mike. I will be hosting again today.
\n\nToday, we have with us Eddy, Ramses, and Tad. You can probably tell, if you're listening to this, by the title that [chuckles] today we're going to be talking about work-life balance and avoiding burnout.
\n\nSo, I'm going to start with a very personal story on this one. About, I don't know, ten years ago, I was at a startup, but not the first startup I've been at [laughs]. I had been at kind of a series of startups, where I had put in a lot of hours. And I realized that the work wasn't motivating me the way that it used to do. I felt, you know, the obligation to get the work done. But I just... it was harder and harder to focus. And I didn't enjoy it the way I once enjoyed it. I mean, coding is fun [laughs], and it just wasn't anymore.
\n\nI started thinking about career changes, thinking about...in my free time, I thought about a lot of things, and they weren't work [chuckles], and that said something. Some context: I had been working at a baseline of about 50 hours a week, and sometimes up to 70-80 hours a week, not usually, but, you know, I'd put in a lot of hours, probably averaged around 60, and I had done it for years.
\n\nI had worked at one place where I was the lead and sometimes the only engineer keeping things together. And this was in the days before DevOps, so [chuckles] not only did you do the engineering, you also kept the systems up. And, you know, there was, like, a data center you had to go to fix things [laughter] in case the servers went down.
\n\nTAD: Unlock the rack, pull up the little cards, the keyboard, and the monitor around it, put things in.
\n\nMIKE: Yeah, KVM keyboard. We did that [laughs]. I did that. [inaudible 01:50] I didn't have to go to the data center very often. But I did that, that, you know, kind of run the show thing for a lot of years. So, I went for multiple years where I didn't have any meaningful vacation. I took off one or two days here or there, and that was it. In fact, I took two days off once and I remember it feeling like the biggest vacation I'd had in, well, in years. I pulled it off. I did it. But there's a point when you start to question, even if it's not even conscious. My body was telling me maybe this isn't the right answer.
\n\nAnd I suggested...I'd been reading about the four-day workweeks that some companies were going to. And we had a team meeting, and the manager I had said, "You know, if there was anything you could have, you know, anything that you would change, what would it be?" And I said, "You know, what? Working less. What if we tried this four-day workweek thing?" And he said, "Okay."
\n\nAnd he went and got approval from the company, and, like, the next week, we did it. So, kudos to [SP] Mutch, by the way. If you ever happen to listen to this, thank you [laughs]. That was awesome. I'm still very grateful for having such an excellent, you know, partner in things. But we did that, and we did that for quite some time, actually. I did that for probably a couple of years there.
\n\nAnd here's the thing, this is the thing: we measured our output and story points. And you know what happened? It went up. It went up. It wasn't just me working four days a week. It was the entire team. We were a relatively small team. We had six or eight people, something like that. But our productivity went up. Our consistency went up, and we consistently delivered. And we were all happier.
\n\nSo, I went from working 50 to 80 hours a week to working 32 to 40, and the productivity went up. It was a profound moment to see that sometimes, working harder does not make everything better or push the work forward. And killing yourself, you know, perhaps literally killing yourself with the stress and all that time and taking time away from things that are also important in life, was not particularly effective to getting more done.
\n\nNow, I don't want to be misconstrued as saying [chuckles] that over no timeframe that additional work can't be helpful. Everybody who's been to college has probably stayed up late studying, stayed up for a test the next day, or finishing a paper, or finishing a coding project if you're a coder, myself included [laughs], sometimes all night for a couple of nights. But that's over a very small, fixed time interval after which it ends. And over longer time horizons, that becomes less and less effective.
\n\nI've seen some research that was a big to-do...probably between 15 or 20 years ago, probably closer to 15, about somebody named...well, somebody whose pseudonym was EA_Spouse. You can look it up: EA_Spouse, EA underscore spouse. When there was a spouse of a developer at EA Games, who wrote an open letter about how their spouse was being mistreated and overworked. For some reason, it went viral, and a lot of people commented on it.
\n\nAnd one of the things that came out of that was there was some research done in physical world manufacturing, not in modern information industries but back when people were working more with their bodies. (So, you could arguably debate that it doesn't quite apply, but I suspect it does.) that they measured overtime. So, they had one group of people work 60 hours a week, and one group of people work 40 hours a week.
\n\nAnd they found that, initially, the people working extra hours had more productivity. But by about six weeks, the productivity was equal. So, after six weeks, the people who'd been working 60 hours a week for those six weeks had no more output, and their cumulative output was no greater. Their cumulative output was no greater than people who had worked 40 all that time. And [laughs], wow, right?
\n\nImagine you're that poor group that worked 60 hours a week, only to realize you've accomplished nothing more than the people who just worked normal hours. That really resonated with me, and I've thought about it a lot in the years since. And I think about the four-day workweek. I worked the four-day workweek for several years. [inaudible 06:00] the Acima Development podcast, my first few years at Acima, I was a contractor, and I actually worked four-hour weeks, and eventually, I came on full time.
\n\nAnd in order to work well with the rest of the team, I've shifted away from four-day workweeks because my burnout had healed [laughs, and I was back and loving my job again. But I know that risk is there, you know, I know that I can destroy myself. So, I've made very conscious effort in the years since to be very careful about how I spend my time. When I'm done with work, I turn it off, and I do something else.
\n\nAnd I've learned that it has not affected my productivity. In fact [chuckles], if anything, I think I've done very well. I've done very well in the years since and have been able to be very successful. And part of that I ascribe, actually, to a willingness to maintain a boundary and say, "This is where work stops." I have an office. And when I'm done with my workday, I leave my office, and I go and I spend time with my family. But maybe I'll do other things sometimes, too. But, you know, I leave my office, and I go and do something else. And then, when the next day comes, I go into my office, and I work hard.
\n\nThere are times when I do think it's appropriate to put in some extra time. There's times where there's an urgent project, and you put in that time to get that done. But if those are anything other than the exception, I think it not only is going to be the cause of a poor personal experience, but it won't actually help. When those long hours become the rule rather than the exception, they tend to actually be counterproductive.
\n\nAnd I'm speaking from anecdotal personal experience, though we did measure, you know, over a team. But there's also research backing that, that maintaining this balance and getting away from burnout is beneficial not only to individual health but to the company health, that we're able to contribute more because we're able to bring our whole selves in.
\n\nAnd it's interesting. I don't think we're necessarily personally aware that our productivity is going down when we're overworked. It's as much as a person who's intoxicated has a hard time being introspective and recognizing they're intoxicated, or a person who's been sleep deprived has a hard time recognizing. And they might know that they're sleepy, but it's hard to do cognitive introspection. You don't see that your productivity is going down. It [chuckles] inhibits your ability even to be self-aware. So, regardless of whether you think you're being less productive, if you're putting those kinds of hours, you probably are.
\n\nI think that there are probably some cheats, to some degree, to get you past some of those things. I know that there's some people in Silicon Valley who do, like, mindfulness meditation to find some break between things and then return to work. But there are human limits. At some point, you've got to take that break. And refusal to acknowledge those limits doesn't mean they're not there. As much as I can refuse to acknowledge that gravity affects me, but if I jump from a high place, my refusal to acknowledge its existence [laughs] is not going to make it go away.
\n\nI have kind of strong feelings about this one because I think it's important. I think that developers should be, and everybody should be treated with respect. And particularly knowing that overworking people doesn't get the job done better [chuckles] leads me to argue pretty passionately that we should be treating people well, not only for their own sake but for the health of the project and the company. We do better when we give people reasonable hours of work. What thoughts does this bring up in y'alls mind? What do you think?
\n\nTAD: A couple of questions that I'm curious about from you guys is, what does burnout look like? And are there other factors besides workload that contribute to burnout? Because workload is an obvious one, right? And that's what you're talking about, Mike. But I can think of other factors that would contribute to me feeling burned out, even if I'm working just a regular 40-hour week. So, those are a couple of questions for you guys. And I'm curious to see what you guys think.
\n\nEDDY: I feel like we need to find what the symptoms of burnout is first, right? Maybe fatigue, like, cognitive thought goes down, et cetera. Like, maybe we can engage the room and see, like, what other people's opinion is on the symptoms to burnout.
\n\nTAD: Like, just a lack of interest, right? You're like, I know I should care about what I'm doing right now, but I just can't bring myself to care enough. And I'm going to force myself and [SP] pinery, and I'll push through this. But, oh my gosh, this is a slog because I feel so indifferent right now to what I'm doing. That's something that I experience when I'm feeling burnt out.
\n\nMIKE: That's really well put. And related to that, focus becomes extremely difficult. Think about intrusive thoughts. Whenever you've had intrusive thoughts, something that you keep thinking about, well, that happens to you because instead of your mind staying on it, your mind wants to go somewhere else. You lose the ability to have the kind of focus you need.
\n\nAnd for software development, you need focus. It's important. It's a very focus-driven endeavor, and inability to keep your mind on it...you think, okay, I'll go for a walk, whatever it is that you do. You know, I'll go and read an article, whatever it is, you know, we all have our own things that you do to go and clear your head just because it's working.
\n\nEDDY: For me, it's headaches. If I'm staring at the screen for too long or whatever, my head starts hurting. It starts throbbing a bit, and I have to stand up, you know, walk away.
\n\nMIKE: It's interesting. You have to look for those things, that, you know, lost self-awareness. It's really hard to do a self-analysis. So, you have to kind of look for those things. Wait, why am I getting so many headaches?
\n\nTAD: I think it's potentially harder for us because we train ourselves to tune things out and to focus, right? That's part of the job. That's part of the skill set is: I need to be able to put the blinders on and set my mind to a task. And if I'm really into something, I'll forget. I'm like, oh shoot, I should have eaten lunch, like, an hour ago, right? Which is a sign that I was doing a good job of focusing but a terrible job of being self-aware of my body's promptings, right?
\n\nEDDY: So, what adds burnout? I think workload, like you said, Tad. I think that's where most of us go, right? Like, instinctively [laughs].
\n\nMIKE: It's not all of it, right?
\n\nEDDY: Yeah.
\n\nTAD: I know that if I have this possibility for something, but I haven't been given the ability or the power to accomplish it, then that puts me in this burnout spiral, right? Like, if they're like, "Oh, there's a very important deadline you have to meet this Friday. You have to get it done." And you're like, "But the API isn't even ready yet." I've just coded against vapor. And I don't have the power to change that, right? Like, the responsibility without the power to accomplish what you're responsible for that disconnect often just makes me stressed and burned out, right? There's, like, a control-responsibility balance that I need.
\n\nRAMSES: In hindsight, I don't know if that would be necessarily your responsibility. It's, like, the product manager's responsibility. You do what you can do, and, you know, if it's not delivered on time, that's their problem.
\n\nTAD: But I've been in a situation where I was working at a startup, and they say, "You got to take this data and build these graphs from this data." And I said, "That's impossible to do." Like, the data just it's not the sort of data that you can graph in that manner, right? And my manager said to me, "You're a smart guy. You'll figure it out. I need this done by Friday." And Friday came, and the data hadn't changed.
\n\nMIKE: [laughs]
\n\nTAD: The requirements hadn't changed. And I still I'm, like, you can try to match this data to this graph, but it's nonsense, right? It just isn't the right graph for the data. And that's just burnout, right? That's just stress. And --
\n\nEDDY: I feel like some of that responsibility does fall to the individual, too, right? I think we need to be able to be expressive when we feel that the deadline is unrealistic. So, like, part of that is imposed by management, like, product managers [inaudible 14:34] and such. But I think as a developer, you also need to be pretty conscious about that and be expressive if you feel it's unrealistic.
\n\nMIKE: Well –-
\n\nTAD: Yeah. And if they say, "You're a smart guy; you'll figure it out," then --
\n\n[laughter]
\n\nMIKE: So, that goes to your...you had mentioned...You didn't use this word, autonomy. I was going to say the same thing. You know, anytime that...and I've seen...I don't have it in front of me, though I've read about this in the past. That's the thing they mention first [chuckles]. It's often mentioned first is, when you don't have autonomy, when you have demands that you have no personal control over, autonomy or agency kind of related words, if that's taken away, it causes stress. And those are the kinds of things that lead most to burnout.
\n\nAnd it says something to management that [chuckles] it's their job to provide agency and autonomy to their employees. Give people the opportunity to do what they want to do, that is, to do their job, right [chuckles]? I don't mean the autonomy to decide to go on a three-year vacation but [chuckles]—maybe in some places—but the autonomy to choose how the work gets done. And that means listening.
\n\nWhen you say, "This is what I think the requirements are," and the developer says, "Well, what is the reason that you have those requirements?" And they say, "Well, I'm trying to solve this problem." And the developer says, "Well, I can think of this way to solve the problem. It doesn't quite meet those requirements, but it solves the problem." Now you've had a conversation. You've done what was really requested, was solving that problem rather than meeting a set of rigid requirements.
\n\nIn the case you mentioned, Tad, "Here's this data. I need to visualize it." If it had been brought to you in a different way, saying, "I've got some data I need to visualize," that's a very different request because it steps back and has some humility, you know, some willingness to negotiate so that the problem gets solved. There's still a problem that needs to get solved. But solving the actual problem in healthy environments...I think we've spoken before about psychological safety. In healthy environments, interesting questions are celebrated and encouraged because they lead to better solutions. In unhealthy environments, there are demands made without any feedback.
\n\nAnd this is related to the idea of Agile software development, which is all around communication, recognizing it's really hard, actually, to communicate about requirements. And if you try to come up with a bunch of requirements upfront, you'll probably get them wrong. So, instead, focusing on an iterative process where there's communication at every step, you tend to get better software.
\n\nA prominent example is SpaceX. They're a physical world company that tries to run things like a software company, and they do this iterative development. And they've just dominated that industry recently because that process works. It works. The heavy communication, the tight feedback loops, where the communication is kind of the center of the cycle rather than documenting rigid requirements. Well, the same thing applies to your manager. You need to have that communication loop. And if management is not communicating, they say, "Here's our requirements. Get this done," then you end up with a project that runs over budget and over time, and nobody is happy.
\n\nEDDY: You know, we're talking about burnout. And both Mike and Tad have mentioned that earlier in their careers, they dealt with burnout. And I can finally relate to that, and I don't know if that's a good or bad thing [laughter]. To give some context, you know, our group was assigned to accomplish not an easy feat. You know, it was a feature that needed to be out within, like, a month deadline.
\n\nTAD: Yes.
\n\nEDDY: And some of us found ourselves, you know, working extra hours, working over the weekend, you know, to make sure that we were meeting deadlines. And I found quickly that I was, towards the tail end of us meeting that deadline, and I found that we were missing, me personally, I was missing really simple syntax, you know, that was being called out on my peer reviews, right?
\n\nThey're just like, "Oh, Eddy, you forgot, you know, you misspelled this [inaudible 18:42]." Oh, man. I'm like, I would have caught that any other time, right? But, like, when you're crunching and, like, you're in a tunnel vision, you know, you start missing really easy mistakes, right? And that's when I realized, I'm like, okay, after this is out, after this is in production, and there's something tangible that's working, I'm going to take a couple of days, relax --
\n\nMIKE: As you should.
\n\nTAD: Yeah, I find my brain is...they usually talk about, like, exercising your mind, like, working your mind. And this reminds me of...one time I was working at a company, and several of us were, like, "Oh, Go sounds like a really interesting game. We should all teach ourselves how to play Go." And during our lunch hour, we would play Go against each other.
\n\nAnd it's a very simple game, but you have to think really, really hard about it, right? You have to be like, okay, if he goes here, and I go here, and [vocalization]. And you have to take really many, many steps ahead. So, we'd do that over our lunch break, and then we'd get back to work. And we'd just be like, "Ugh, I can't even, like, work. Like, I can't even focus on my code because this activity I did for an hour is exercising the same part of my brain as I was needing to write code. And I just can't bring my brain to do that still, right? Like, I need to find something different. I need to exercise a different part of my brain, right?" Like, if I'm doing --
\n\nEDDY: You need to stimulate your brain [inaudible 20:15]
\n\nTAD: Yeah. Just, like, I'm doing left-brain activities, like, very intense. And I think Mike has mentioned, you know, go and listen to some music or play the piano, or, you know, interact socially, or things like that. That's an activity that's very different. And it lets that part of your brain rest and lets some other part of your brain, you know, take over and do something for a while.
\n\nMIKE: My first manager in software grew roses. You got to have something different.
\n\nEDDY: I play fetch with my dog because I have a backyard, sometimes.
\n\nTAD: There you go.
\n\nEDDY: And with us kind of transitioning over to winter, there is very less time you can do that now.
\n\nMIKE: So, you need to find another outlet, you're saying?
\n\nEDDY: Probably. Yeah, that sounds about right.
\n\nMIKE: [laughs] So, we've talked a little bit about some of the things that lead to burnout, and we've mentioned the lost autonomy and then overwork. Anything else that any of you have experienced? You know, it doesn't even have to be necessarily work. You know, this can happen in school or other situations.
\n\nTAD: Actually, I was mentioning, like you, you know, go interact with your family, things like that. Something that leads to burnout for me is isolation, where I'm just by myself. And there's been times in my career where it's...I've worked remote; I'm by myself. And the project I was given is, like, a three-month project or something like that, right? Where there's no one else I can talk to about the project. They're all doing their other things. It's just me and the project that's going to take three months.
\n\nAnd it's hard for me to care as intensely on a three-month project by myself as if, you know, I'm pairing with somebody, or I get a break, or I get some kind of variety or something like that. So, it's...maybe I'm touching on some other things as well. But, for me, that isolation aspect, if it's just me by myself all day, every day for many months at a time, I start to feel it. And it's not a workload thing. It's just I miss the interaction with people. I miss being able to talk through some things.
\n\nEDDY: So, that's why you go into the office is to avoid burnout [laughs].
\n\nTAD: Yeah, like, I come into the office so I can talk anime with you. And you heal my burnout, Eddy.
\n\nEDDY: To the listeners out there, to avoid burnout for Tad, he likes to have conversations and go on tangents about anime [laughter].
\n\nTAD: Because I know you're a huge fan. But I am someone that probably needs to pair more than maybe other developers. I've got a buddy who works for Google who his ideal situation would be he's in the forest in a glass box so that, like, you know, he's somewhat protected from the elements, but he could still see nature. And he would be able to do that all day, every day, for the rest of his life.
\n\nHe doesn't need to talk to anybody. He doesn't need to have anyone check in on him. He would just sit in nature by himself. And he's content, right? He's fulfilled with just that. But if your needs aren't getting met, is when you hit burnout. And, for me, I have a social need that I need to take care of periodically, or else I get that fatigue and that burnout.
\n\nEDDY: Change of scenery, Tad. I think that's awesome. It's a great idea. When you really mention it, anytime I do go physically in an office, since I do interact with more people to get that social stimulation in my brain, now that I'm thinking about it, it's very seldom that I do reach or hit burnout from the days when I do go to the office.
\n\nI can't do this anymore. I have a backyard patio, and I have a bunch of trees, and I have a garden couch. The couch is designed to be outside. And I would sit down, stretch my legs because it's a long couch, right? And I'd sit back and, you know, recline a little bit. And I'd find myself just hearing the birds. Suddenly, that's kind of soothing.
\n\nTAD: That's interesting because I have a spot on my balcony where I've set up a hummingbird feeder, and just going out on the balcony...every developer they get hung up on something and just kind of, like, stare off in the near distance and just kind of, like, ugh [laughs]. And just being able to watch the hummingbirds flit around while I do that has been beneficial for me.
\n\nEDDY: The power of nature.
\n\nMIKE: Are you familiar with the idea of forest bathing?
\n\nTAD: I am, yes.
\n\nMIKE: It is a Japanese idea. It's a practice of going to the forest, and it's not literal bathing of your body. It's kind of bathing of your mind. My understanding is it has been shown to be very therapeutic, nature, in particular, getting out of the office, outside into the woods and that glass box, wherever it is [laughs], someplace where you're exposed to somewhat unmodified [chuckles] universe around you. That could be the stars, right? Seeing non-human created environment changes you, and I don't have deep insight as to why that is, but I do have deep experience. That is very therapeutic for me. And I wonder if it's somewhat related to the socializing and that you're communing with the universe in some way.
\n\nEDDY: I haven't necessarily done forest bathing, unless you consider listening to a soundtrack of a forest. That's what I've done before trying to fall asleep, you know, and I take my mind elsewhere. I will say, like, "Hey, Alexa, play some sounds from the forest," you know, and just hearing birds chirping, and, like, the wind and trees being brushed and stuff like that, maybe it has a similar effect.
\n\nMIKE: Why wouldn't it, right? [laughs] Whether it's visual or audio, it's all a similar experience. I was thinking, as were talking about isolation, in prisons, they will put somebody in solitary confinement sometimes. Sometimes, that's treated as punishment. And whether or not it's treated as punishment or just keeping somebody safe, I read that it's associated with severe negative effects on mental health. It's, in general, not good for people to be alone, and, usually, it doesn't result in very good software either, oh, not as good; I'll say that. You know, software, in general, is done better in a social context like most things.
\n\nEDDY: You know, I'm pretty sure I've read something, like, a psychological somewhere a long time ago, where we've done studies that, actually, isolation is, actually, bad for individuals. And prolonged isolation does horrendous things to the body. I'm not saying that being a developer is coexisting with isolation [crosstalk 27:03].
\n\nTAD: It makes you [inaudible 27:04] crazy?
\n\nEDDY: [laughs] I'm not saying it makes you crazy, and it's relatable to prison. But --
\n\nMIKE: Right. They're different in degree, for sure. And I don't want to diminish the suffering of somebody who's in that degree of isolation; rather, to give an example of an extreme case and the deep trauma it perpetrates against your mind. And in a much lesser degree, like with my experience at work, you know, could lead to burnout.
\n\nEDDY: What are some of the actions or the things that you guys do while working to help productivity and also, in essence, avoiding burnout? I feel like some of us would say we listen to music. Anything else?
\n\nMIKE: I can't listen to music while working. I love music.
\n\nTAD: [laughs] --
\n\nMIKE: And that's why I can't listen to music while working because I can't do both [laughs]. I used to do it when I was younger. And if I need to have deep focus, I cannot also have something else that is taking my focus. You know, some people have ambient music that they can pay less attention to. To me, that's hard. I'm somebody who likes to think about the structure of the music.
\n\nPart of my experience of the music is maybe decomposing a little bit, thinking about the parts, thinking about the baseline, drums, you name it, or, you know, thinking about the harmonies or, like, oh, there's a key change, and kind of self-evaluating how it makes me feel. And with music I like, I'm going to go listen to it thinking about the lyrics, you know. I can't listen to music. It's stressful for me because it requires me to focus on two things at once.
\n\nTAD: Would something like the sound of rain or, you know, the ocean or something like that where it's maybe got some pattern, but it's not really musical and that structured...To be a developer, a lot of times you have to have a very analytical mind. And I'm guessing that deconstructing music is kind of the same muscle as breaking down code and analyzing code. So, that's going to be competing in your mind, right?
\n\nMIKE: You got a point. I bet I could listen to rain, and it would probably be fine and help push the other things away because it's close to white noise. It has a beautiful structure but one that's largely chaotic; you know, there's not a pattern that can distract. It's a good thought. Maybe I should give it a try.
\n\nTAD: I've kind of been thinking about different things. Maybe there's a lot of things that cause burnout for me. But I was thinking about a startup I worked at, and their value proposition was all the other people in this industry take your data, analyze your data, sell your data, invade your privacy, you know, all these things, and we don't, right? And that was their sales pitch. And that was their special niche that they're like, we only sell your data if you want us to, you know, we could partner up. We'll sell it. We'll give you a little bit of a kickback. But by and large, we store it, encrypt it, and it's private, and all these things.
\n\nAnd that was something that I really kind of believed in. And I'm like, yeah, like, people's privacy, and we don't sell their data. And I'm kind of proud that we're the only people in this particular segment of the industry that are doing that. Then, the company got sold to a much bigger company. And one of the first things they did is like, oh, yeah, we're going to make a ton of money by selling off analytics of everybody's data.
\n\nAnd when those values shifted, so they didn't align with my values anymore, suddenly, my enthusiasm for my job just went way down. I'm like, oh, okay [laughs], we're doing the same things that everyone else is doing. And we're not cool and awesome and an ally for people. We're just exploiting people [laughs] like everybody else. And that probably caused some burnout for me, just because I didn't care. This isn't cool. This is just a job that I'm slogging through now. And it's kind of something I'm doing. And I don't necessarily love myself when I do this. It's causing friction against my personal values.
\n\nSPEAKER: And I think that it happens with every change in management, when there's a big change in management and the philosophy changes. That's what happens because you are used to have the same vision. And it happened to me. I was working at a startup. And we were, like, disrupting the proptech ecosystem in Mexico. And there was a CEO, did something wrong, and they needed to replace him.
\n\nAnd this guy was, like, a big person in the ecosystem. But it was an old guy, like, really married to how things were done 50 years ago, and he wanted to take the company back to that. And I was very happy on how we were disrupting. And when this person came, it's like, the whole happiness of me working there it was off.
\n\nTAD: Would you say that caused burnout for you?
\n\nSPEAKER: Yeah, it was like, oh, no more happiness when you wake up. And, you know, you don't feel like going to work. And it's like, oh, this guy is going to ask...what [inaudible 32:27] project is he going to ask now? [laughs]
\n\nMIKE: Similar experience I had working for a company that got bought out. The company that bought us out started doing some things I found really shady. [laughs] And it bothered me more and more till one day I left [laughs]. At first, you know, things were fine. But as things got shadier, I got more and more uncomfortable; not just me, but the entire development team actually walked out. Not a good thing for your company, by the way, when your entire development team walks out [laughs]. Try to avoid doing shady stuff.
\n\nTAD: [laughs] It sounds like values and culture are big factors, yeah. I'm actually able to handle a higher workload if I enjoy the people I'm working with and I believe in what I'm doing.
\n\nEDDY: I hope I attribute to that.
\n\nTAD: [laughs] Of course.
\n\nEDDY: [laughs]
\n\nMIKE: We've identified several things that cause burnout. And if these are the factors that cause burnout, what's the opposite of that? Because I think we can take practical steps to avoid each of those things. And I think that'd be a great way to round out our time here. And the first one we all jumped to was overwork. So, what did we do?
\n\nRAMSES: I think you mentioned this earlier, Mike, but one of the main things, at least, I try to do, with my own work is set boundaries. I try not to work too much. I personally try to get up from my desk at least every hour. It's a little bit harder because my chair is so comfortable [laughter], so I can sit there all day. And then outside of work, I just try not to think about work too much; you know, I might be working on a problem in my head, but you just have to put it away until the next day.
\n\nMIKE: You know, and our listeners don't know, but Ramses is a machine. He gets a ton of code written. Realize that when he's saying he takes breaks, that means he's exceptionally effective with the time he has.
\n\nTAD: It feels like the Pomodoro thing sweeps through the software development community periodically, where you work for maybe 25 minutes, and then you take 5 minutes of break. And then you work for 25 minutes, and you take, like, 5 minutes of break. And in those 25 minutes, if something comes up, like, oh, that's a distracting thought, you could write it in a notebook, knowing you'll give yourself 5 minutes to address it later on. And you could free your brain from worrying about it, right? And I don't do that well, but there have been times where, you know, doing that kind of timeboxing has been effective for me.
\n\nEDDY: Disconnecting from work, I think, is crucial to avoiding burnout. In certain occasions, I've wanted to uninstall Slack on my phone, on the weekends. It's one of those things where I instinctively check to make sure nothing's on fire. But you can't really disconnect from work if you always have that connection wherever you go. I actually hid the icon...
\n\nMIKE: [laughs]
\n\nEDDY: Somewhere else where I'm not used to looking for it as a way for me to...if I [inaudible 35:31] try to go for it, I have to go out of my way to find it. And then I catch myself, and I'm like, oh, okay, no, I shouldn't be checking it. So, I think disconnection from work I think it's important. And also, try to avoid thinking about stuff over the weekend.
\n\nMIKE: And it's hard if you're on-call. You know, if you're responsible for a project, you have that obligation, but you can still timebox it. You can say, "Well, you know, I need to check on this. So, I'm going to check it at..." and you pick your time and then set it aside, unless there is an active push notification, you know, something that's pulling you in. And you can set up your notification preferences appropriately; you don't go back. There's more of that boundary setting.
\n\nI get off work. I do have Slack on, you know, if somebody needs to get a hold of me or they text me. I put my phone in my pocket, and I walk away. Yeah, maybe I'll use my phone to read something, but I will walk away from my desk. And that willingness to walk away has made such a difference. I used to really struggle with that, having that boundary, having an edge. But I've learned that, you know, I need to if I want to be effective at either side of that [inaudible 36:35].
\n\nEDDY: Early on, my wife would catch me on there, right? And she would be like, "What are you doing?" "Oh, I'm just answering the message in Slack on my phone."
\n\nTAD: [laughs]
\n\nEDDY: And she's just like, "Why? Aren't you off work?" I'm like, "Yeah, but I can provide input. Like, let me go ahead and do this." Eventually, like, she's like, "Babe, like, you're off work. Distance yourself [inaudible 36:54]. They'll live without you until tomorrow." Imagine I wasn't on-call.
\n\nMIKE: Well, and I schedule some time. I know that people might have some needs. So, I generally try to take 15 minutes to check Slack in the morning and in the evening, so I'm keeping, you know, a regular cadence. So, if people are stuck, I can do that.
\n\nSometimes, in my current role [laughs], I have a lot of requests. I'm looking at 65 right now, and I recognize that it's not even possible for me to get to all of them. And you have to make a choice that you're going to be okay with that, that you can't get it all done. So, you have to prioritize and do what's most important, and then walk away. And that's really uncomfortable because I think we all want to do everything. And that recognition that we can't is hard but necessary.
\n\nTAD: The hard thing is that answering people's questions, helping things out, I mean, that's part of your job, and that's part of the reward of doing your job. If you didn't enjoy that stuff, then you would have a different job. So, it's hard, but it's something that you enjoy where you get positive feedback from it. Like, if Eddy is on, you know, helping me out with something, I'll be like, "Hey, Eddy. Thanks," you know, thumbs up, high-fives, and stuff like that. And it's hard to put that away sometimes.
\n\nMIKE: And we have to remember that we're not an unlimited well. You can drain it dry. That water table has to be replenished. And if you're not in a healthy spot, it's hard to help anybody else out. There are finite boundaries. We absolutely should celebrate, I think, that willingness to help and also recognize that, you know, if you destroy that ability to help, you're not helping anybody, and those boundaries make a difference.
\n\nLiving without boundaries will only destroy yourself, and that's a difficult thing to realize. The answer is no [laughs]. You can't do it all, so you have to choose, but vital. And the same thing applies in lots of different contexts. If your business can't do everything you'd like to do, you got to choose. And in our personal lives, we have to choose. You have to choose to do the things you can do within your allotted time and then be done.
\n\nSo, there's a lot to be said for choosing wisely, spending your day saying, "Well, these are the things I need to get done today. I'm going to work on the most important things first," or else you get to get the end of the day, and you're going to have that lost autonomy because you haven't done the most important things, and you're stressed out because they're not done. And you feel like they were taken away from you. But a lot of times, we do have some agency there. We can choose what we do first, and that, I think, goes a long way.
\n\nEDDY: You mentioned something that kind of harmonized with me where you said, you have to be comfortable being uncomfortable with doing so, right? Well, I'm paraphrasing, and you said [inaudible 39:35]
\n\nMIKE: I think you said it better than I did [laughs].
\n\nEDDY: The thing is, at least for me, it was a lot harder to do that early on in my transition to a developer. When I first started, and I'm going on five months now, it was really hard to disconnect because I really wanted to hit the ground running. I was pushing 200 miles per hour, trying to make sure that, like, no one made mistakes, and I'm providing the value that I said I would, so I'm not trying to make a liar out of anyone.
\n\nBut the longer you go, you know, the more experience you get; I think it becomes easier to disconnect and be putting yourself in those uncomfortable situations. So, for anyone listening who's starting to transition or starting to get their foot in the door, just know that it gets easier the more experienced and more wise you grow.
\n\nMIKE: It stays uncomfortable [laughs]; I can say that. But like you say, you become more mature at it and okay with it. You've made a conscious choice to embrace imperfection. A lot more gets done when it doesn't have to be perfect. So, we've talked about priorities and how vital it is to set priorities. That also helps some with autonomy. It helps with your time because it allows you to set those boundaries and give yourself some time.
\n\nSo, boundary setting, prioritizing, and I don't know if there's much else to be said about the autonomy aspect because priorities has a lot to do with that. It was also mentioned that willingness to communicate is important, that when you see something you don't like, you say something.
\n\nTAD: It's nice if you're safe saying something.
\n\nMIKE: Yes. And that kind of yields the final point. If you're at a place where you don't have autonomy, when unethical things are happening around you or things that don't coincide with your values, and where you're being overworked, the answer is you probably need to leave. And, again, sometimes you just need to make that choice. Look around yourself and say, "Well, this is not the right environment for me." And that's an okay decision. You'll live through it [laughs].
\n\nAnd maybe that's a good place to end today. We've talked about the problems. We've talked about the solutions. Thank you to everybody who's participated today. I think we had a great discussion. For our listeners, thank you for joining us again on the Acima Development podcast. You'll hear us next time.
","summary":"","date_published":"2024-01-31T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/ccba595d-b3f7-4b2e-80a8-f6466ec40d6e.mp3","mime_type":"audio/mpeg","size_in_bytes":21211008,"duration_in_seconds":2518}]},{"id":"b4646d0a-12e6-4ca7-ae64-a3df9a704d11","title":"Episode 37: Introduction to Ruby","url":"https://acima-development.fireside.fm/37","content_text":"The panelists discuss Ruby, a primary programming language at Acima, notable for its popularity in startups and major companies like Shopify and GitHub. They attribute its success to the Ruby on Rails framework and the language's community support. Mike shares a personal story to parallel the complexity of understanding Ruby, linking it to its creator, Yukihiro Matsumoto (Matz), who views Ruby as a language of love, embodying a philosophy of developer happiness and care. \n\nAdditionally, the group explores Ruby's technical aspects, focusing on its object-oriented and functional programming features and syntax that mirrors spoken language, simplifying programming. They discuss Ruby's history, its influences from languages like Perl, Smalltalk, and Lisp, and its evolution with Ruby on Rails. Additionally, they touch upon Ruby's versatility beyond web development, its role in shell scripting, and considerations regarding its scalability. They end with an endorsement of Ruby for its user-friendly approach to programming, prioritizing problem-solving and user experience!\n\nTranscript:\n\nMIKE: Hello, and welcome to another episode of the Acima Development podcast. I'm Mike. I'll be hosting again today. We've got a group of us here with me. But yeah, kind of starting, we've got Sergio, Eddy, Dom, and Jonathan.\n\nToday is a topic that I have been interested in for almost decades now, which is the Ruby programming language. At Acima, we do a lot with Ruby, and it's been our primary language. It is not the only one we do, but we've done a lot of Ruby for a long time. And I've done Ruby for a long time. A lot of us here have done Ruby for a long time. \n\nAnd certainly, there's reasons to do Ruby, you know, it's got a community. Ruby on Rails framework has been popular for a while. It was particularly influential, like, I don't know, 15 to 18 years ago [laughs] and has continued to be used a lot by startups in particular. And there are some, you know, major companies using it, such as Shopify or GitHub. There's a community out there of Ruby users. And there's reasons just for that.\n\nBut today, we're going to talk about the language itself and what it is. So, if you're interested in a quick whirlwind tour of Ruby, that's what we're doing today. And I'd like to start with a story. I think a story is a great way to begin a podcast. When I was in ninth grade, I remember an essay assignment I was given. And I remember because I had no idea what to say. [laughs] And I think we were studying Romeo and Juliet, and we were supposed to write some essay about love. And I don't even remember what exactly about love we were supposed to say, but we were supposed to write something about love. \n\nAnd I remember that I thought about it, and I didn't know what to do. So, I wrote some sort of silliness about how love is poorly defined and lots of people see it differently. And I spent all of my time talking about the question rather than actually answering it. It was probably a pretty lousy essay [laughs]. I probably wouldn't even remember it. I think I stumbled upon it some years later, and I read through that [laughs]. \n\nBut, you know, I had this question. At that age, I really wasn't sure. I didn't know how to define love very well. And there are a lot of different answers to that in the world. Well, there's one very interesting answer to that question. The Ruby programming language was created by a guy named...I'll try to pronounce his name right. It's Yukihiro Matsumoto, and he's lovingly referred to by the community as just Matz. They shortened his name to just Matz. And he's very much beloved by the community. \n\nHe has said on more than one occasion that the Ruby language is love, and that says a lot about what the Ruby language is. And I'm going to talk a little bit more about the history [laughs]. But the Ruby language was created to be an embodiment of that idea of, you know, I care about you. I want to make your life better. \n\nThe Ruby language is built on ethos. And, in fact, there's a saying within the community, \"Matz is nice, and so we are nice,\" MINASWAN [laughs]. The creator is nice. He wants to be nice to us. He tries to be nice to us. He reaches out with his language and also just his demeanor. If you've ever seen him speak, he's just a soft-spoken, super nice guy. And the language reflects that aspect of Matz, the creator. \n\nIf there's kind of one thing you leave with about what Ruby is, it is this language that's supposed to make you feel good [laughs] and then lift you up as a person. And, hey, well, a programming language does that? Well, it's kind of its goal. Different programming languages have different goals. Some languages have been intended to be very high-performing. They're really good at running fast, and that's a great goal, right? We should have some languages to do that. \n\nOther languages take a particular idea, like being functional, and take it to its extreme. What would happen if we made a purely functional language? And I'm thinking about Haskell here. But there's some other languages that go that direction. Other languages focus maybe on type safety or on whatever particular problem they have at the time. \n\nWell, Ruby focuses on developer happiness. It's a language that was designed from the beginning to try to make developers happy so that if you're a software engineer and you use this language, it makes your day a little better. And that's what Ruby is about, as opposed to other languages. It doesn't mean the other languages are bad. In fact, Ruby is not written in Ruby; most implementations of it are not anyway [laughs]. Ruby is written primarily in C, which is one of those high-performing languages. So, every language has its purpose. But Ruby is intended to make your life happier as a developer. Did Matz succeed? [laughs] Do you feel loved?\n\nEDDY: I'm curious about the time why the name Ruby was given. Was it just because it signified or represented love at the time, or is there some sort of correlation with the name and happiness?\n\nMIKE: That's a good question. The one thing that I have heard about Ruby is Matz was inspired by Perl, which is another precious stone [chuckles]. And he came up with Ruby to kind of mimic that idea and [inaudible 05:08] Ruby is following kind of a similar niche, where it's an effective scripting language, easy to use. And it may be that Ruby references some of that a lot, you know, it's this red stone. And it's kind of heart-shaped frequently in its cut.\n\nSo, I can't speak to that for sure. I don't know the answer. You'd have to ask Matz. I have not heard about that. If anybody knows, you know, please speak up. But I was having the same thoughts as I was talking about it. Well, he says Ruby, the language, is love. That stone could represent love. And so, it [laughs] might actually be a symbol that's suggesting that gift he's trying to give back with. Have you felt the love when using Ruby?\n\nEDDY: It's easy to pick up, I will say that. You take the layer of complexity of syntax out of the equation, and suddenly, you're one step closer to thinking as a programmer.\n\nMIKE: Ruby is a language that's designed to read a lot like spoken language. That definitely changes the way you think [laughs]. Instead of trying to think like a machine, you think more like a person. Certainly, you do have to think somewhat like a machine for developers [laughs]. But the syntax fits a little more naturally to the way that humans speak. \n\nLet's talk about that. Let's talk a little about the history and why that might be. So, Ruby, the first release—and I've looked this up—the first version of the Ruby programming language was released on the 21st of December 1995, so we're going on 30 years. It's been around for a long time. And Ruby was and certainly inspired by other programming languages. I'm going to try to quote Matz a bit [chuckles] in several ways.\n\nBut he said that he was inspired by several other languages. I'm going to point out three of them: Perl, Smalltalk, and Lisp. Perl is this kind of utility knife of a language. You use it for scripting. A lot of early websites...Perl isn't used as much for this anymore. But a lot of the early web applications were built in Perl because it's this really useful text processing language that was originally kind of used more for shell scripts but, well, for other text scripting scenarios like you have with a web app. So, Perl was a big inspiration for Ruby.\n\nAnd Smalltalk–and I'm going to talk about that next; Smalltalk is a pure object-oriented language. It's not just a language. It's like an environment. You get, like, this Smalltalk environment you interact with, which was actually influential in a lot of other languages. Object-oriented coding has really taken off in the years since, but it was really experimental and new when Smalltalk came out. \n\nAnd the thinking that everything could be an object was kind of a radical departure from some of the ways other languages think about things, and Ruby embraces that. In Ruby, everything is an object, and when I say everything, I mean everything. An integer is an object. You can call functions on an integer. A string is an object. You can call functions on a string. There are no true primitives in the way that a lot of other languages have. Well, here's the, like, when you think about Java, you have primitives that you don't call things on. They're a different thing from everything else. In Ruby, that's not the case. Everything is an object, kind of taking that Smalltalk inspiration. \n\nAnd the other language that I'm going to call out is that Lisp, which is a very functional language, kind of the archetypical functional language that other functional languages have drawn from. In functional languages, you think about everything as a function, you know, the unit in functional languages is the function. In object-oriented languages, you think about...you structure your modules with objects, right? And your object is your unit. You have classes, and you build objects from those. Well, functional programming thinks about things a little differently. It groups things in functions, [inaudible 08:47] that objects don't have functions. But when you're thinking about kind of the primary organizational idea in functional languages is functions, and Ruby embraced that from Lisp. \n\nIn Ruby, every expression has a return value, which means that you can write anything that could reasonably evaluate as an expression in Ruby, and it has a meaningful return value. If you write the number one, you can run a Ruby program with just the number one in it, and that is a valid Ruby program. In some other languages, that wouldn't make any sense, but in Ruby, that makes sense. It's an expression. It's the number one. It has a return value of one. [inaudible 09:23] doing something, right? It's expressing this number, and it even has a return value. \n\nAnd that changes the way you think about things, this idea that comes from functional programming where everything is an expression. Everything has an implicit return value because that expression evaluates to some value. And that idea is deeply embedded in Ruby as well. Not only is it object-oriented, where everything is an object, everything is also an expression, which implicitly has a return value, which means you could think about every expression as somewhat implicitly being a function as well. It also leans heavily into the idea of anonymous functions, but I'm going to hold off on that for a little bit and go back to this idea of its creation. \n\nSo, I want to give you a little history of Ruby. Ruby is this language that takes these big ideas of functional programming and object-oriented programming and smashes them together into a scripting language. And it gives you Ruby to try to make this tool that makes developers happy. Ruby was created in Japan. Matz is Japanese. He lives in Japan. I believe he still lives there [laughs]. And has developed there for a long time. \n\nBecause Ruby was originally in Japan and had documentation in Japanese, it became fairly popular in Japan. It became a popular programming language there because you could get documentation in Japanese. All of us like to be able to read things in our native tongue, so [laughs] it makes a lot of sense. So, it became kind of this niche language that was popular in Japan. Eventually, it started reaching out of Japan as other people discovered it. In particular, in the mid-2000s, there was a development team that decided that they would use Ruby to build a new web framework called Ruby on Rails. \n\nAnd I believe that Ruby on Rails was—I'd have to go look this up—was released around 2005. It made a big splash in the web application community/web development community by its usage of convention over configuration [laughs]. At the time, most web development involved setting up lots of configuration files for everything. Anybody who did Java development back in the day, you know what I'm talking about [laughs], so many XML files.\n\nThe Ruby on Rails, this framework, cut through a lot of that and said, oh yeah, let's just do the obvious thing by default. You don't even have to configure it. And the object-relational mapper it had called Active Record, as a result, was really easy to use in a way a lot of other systems weren't. Now, other frameworks have borrowed a lot of those ideas. So, Ruby on Rails really isn't this path setter anymore. It's not in the vanguard because other frameworks have taken the same ideas, which is fantastic. Web development is better as a result. \n\nBut it meant that Ruby made a big splash and was heavily used by startups in the United States. You know, it had left Japan, still there in Japan, but it became heavily used throughout the world by largely web developers because of the Ruby on Rails framework. It's been somewhat in decline in recent years. Some other languages have become more prominent, but it's still got a thriving community behind it.\n\nEDDY: Who did the transcribing for when it left Japan, do you know? Like, who did all the documentation translations and --?\n\nMIKE: That's a great question. I don't personally know the answer to that. I know that Matz himself is, you know, bilingual. He speaks English [laughs]. Japanese is his primary language, but he knows English. He has spent some time in the United States, which I think has helped a lot [laughs], helped him to document things in more languages than one. \n\nLet's talk a little bit more about the language then. We've talked a little bit about how Ruby is object-oriented all the way down. And it's also functional, deeply functional all the way down. So, I gave an example of how you can just write any expression. You could write a string or an integer. That's a valid Ruby program. Just put a string into a file; that is valid Ruby. It's not very useful [laughs], mind you. But you could run that as a Ruby file and give it a Ruby extension. You don't even need a Ruby extension. Call the Ruby interpreter, and it will be interpreted successfully and will run because every expression is valid Ruby that can be written in Ruby.\n\nThat has some side effects in that if you have a function written in Ruby, you rarely need explicit return values, and, in fact, most Rubyists don't use them. And this is common among functional languages, that the value of the final expression in the function is implicitly...because everything has a value, right? Every expression evaluates to a value. That is the return value of the function. So, to return something in Ruby, you just simply write the expression you want to be returned as the final line in your function. \n\nAnd for those who've been using more procedural languages, that is weird. But I'm not going to tell it to return things [laughs]. But, in Ruby, it's not that way. Instead, you think about, well, what does this mean? Well, it's saying something. Well, that's what it's returning, the thing it said. You don't have to say, \"Hey, this is the thing I want to say.\" It's already implied because I've already said it. And that idea, going back to this idea of convention over configuration, kind of goes all the way down. Everything is an expression. \n\nI'll take that a little bit further. Ruby does not require parentheses in function calls. So, you can call functions without using parentheses; just put some spaces in there. [inaudible 14:30] put commas between your parameters. That means in cases where you have a function that doesn't take any parameters, it's indistinguishable. If you don't put parentheses, it's indistinguishable from another expression. And that can feel kind of weird if you want to be able to tell the difference. Ruby actually kind of leans into that; some Ruby actually kind of leans into that. \n\nSo, when you're reading the code, you don't have to know if a given line is an expression or a function because it's kind of both. And it allows you to build out domain-specific languages; that is, you can write out code that looks more like configuration than it does, like, a traditional programming language. And you can write out little sub-languages within Ruby that look very much like their own language where some of these things that look like keywords are really just function calls. But they appear to be a keyword because you don't need the parentheses. It makes for some very legible tools; tools such as RSpec, a popular testing framework in Ruby are built in that way. \n\nOne other thing about Ruby is that there is...I want to be careful how I say this. It is implicitly typed. We do not use explicit typing in Ruby. So, if I set a variable equal to an integer, I never had to declare that that variable was an integer. However, I can't then go and add that integer to a string. That doesn't make sense. So, it is strong typed in that there's not implicit casting; rather, everything is typed. It's just implicitly typed. \n\nThat also allows you to do some really cool stuff. Unlike in other languages where you might need to write five different copies of a function to take five different types of incoming parameters, you can just write a single method signature that can take the incoming parameter and expect the incoming parameter to be an object. In fact, that's how Ruby expects things to work. \n\nSince everything is an object, you can pass an object into anything, and they handle the type later. It allows for really clean calling syntax. If for some reason I did want to add a string to an integer, I could write code to do that and make it very transparent. I could make it very transparent so that other people didn't have to know about it. It would just work within my program. I'm not saying that's a good idea, mind you [laughs]. But if you had some need where you needed to add two of your own kinds of objects that were neither integers nor strings, you use a plus sign. It's easy to just define that method to do so and put them together. \n\nI can take this a little bit further. And this is both a strength and a weakness. Ruby leans into what we call duck typing. That is, if it walks like a duck, talks like a duck, quacks like a duck, it must be a duck [laughs]. And so, what you see commonly in Ruby code is that you don't have a lot of validation on parameters that get passed into functions. You kind of expect the callers to do the right thing. \n\nSo, if something meets the requirements of what your function needs, you're not going to ask about its type and, instead, you're just going to assume that they gave you what you needed. In other languages, you might use some templating features built into the language. Ruby, you don't need to do that. It's kind of implicitly a template. We're just going to assume that you're going to do the right thing. \n\nAnd, of course, if you want to do validation, you're more than welcome to do so, but you need to be explicit about it, and it's not going to be built into the language. Again, this is a strength and a weakness. It means that you can have very easy refactoring of your code where you can pass in a different kind of object to a function, and it'll still work. \n\nOn the flip side, you don't get some of the type safety guarantees that you get in strongly typed languages that put a lot of validation on type. And it means you get different kinds of bugs. It means your code tends to be a lot shorter…a lot easier to reason about in Ruby. However, you can get some type safety bugs that you would not get in other languages because I think it's a big thing to notice. \n\nThis wading into, hey, you know, everything's an object; you can pass anything anywhere; it allows you to write code that's just amazing, legible, and terse, and easy to refactor. It also means that you can end up with subtle bugs sometimes because type safety bugs are hard to face. I'm not saying that it's a showstopper. But depending on your domain, you know, some people would argue that's a serious problem. \n\nAnd there actually are several different tools within the Ruby community for dealing with this, for adding type, some that add type within the language, and some that add it by adding an additional file. It's kind of experimental, but you can add a type file adjacent, you know, kind of next to your Ruby file to add typing to it. So, you can get some of that type safety you get from other languages. \n\nRAMSES: Yeah. There's tools like Sorbet that provides the type checking, which is very interesting. \n\nMIKE: And for large companies, like, Sorbet came...did that come out of Shopify? I'm trying to remember -- \n\nRAMSES: Yeah, yeah, I believe so. \n\nMIKE: I believe so, too. They built this tool because they wanted to have the best of both worlds. They wanted the expressiveness and ease of use of Ruby but still have the type safety. So, they've built some tooling to provide that. So, there's tools available to give you the type safety that you'd like to have in Ruby, if that's something that's important to your use case. And I think that it's important to a lot of use cases, something that I actually encourage leaning into in a new Ruby project. It avoids certain kinds of bugs and allows you to be explicit about what you intended to happen. \n\nThe next thing I'd like to talk about that Ruby does...we talked about everything is an object. We talked [laughs] about some of the things it does, getting those advantages of being truly purely object-oriented where everything is an object. Actually, I'm going to talk a little bit more about that. [inaudible 20:06] everything is an object. It also has some sort of class, you know, that prototype that you use to define it. And you do not have to completely define that class before your code runs. It can be written at runtime. It also means that you can reopen classes and start adding functions to them or even change their behavior at runtime. \n\nComing back to this Lisp idea [chuckles], I mentioned Lisp before as one of the inspirations for Ruby. In Lisp, you can rewrite the program. The program can write itself as it runs. And that's a really weird idea when you first hear about it. We actually do it all the time in Ruby. We have code that writes code. \n\nI mentioned the Object Relational Mapper in Ruby on Rails, ActiveRecord. It accomplishes a lot of what it does by what people call magic, but not exactly magic. It just uses Ruby's features to go in and look at your database, check out the table name, and figure out where the columns are, and let's go ahead and write some functions. Go ahead and write some functions at runtime into your class to be accessors to those column names within a record. \n\nAnd so, rather than having to explicitly define something that's already there, it can just look it up and generate it on the fly. You're not usually going to do that in your code, but for a framework, that's amazing. It means that a lot of the configuration...if something is discoverable in the world, the code can write itself. It can go out and write methods at runtime that didn't have to be conceived of [laughs] by the people who wrote the framework. They just had to write code that's able to do that perception of the outside world and deal with it accordingly. \n\nIt's amazingly powerful. And it's one of the strongest aspects of the Ruby on Rails framework because it allows it to be very terse and very easy to understand. So, it's a practical use, right? Why would a code want to write code? Well, it's because you don't necessarily know, when you're writing a framework, what code you're going to be working with. And you don't want to have to explicitly say all those things because it's discoverable. So, code that can discover some things about the world around itself and write new code within itself to deal with those things is actually incredibly useful. \n\nListeners can probably think, oh yeah, well, what's some things I could discover? Well, maybe you're working with some web service that tells you about the weather. Well, you could have code that goes and pulls that and figures out what fields are available and then creates functions to tell you. And then, again, while running live, it could do some self-analysis, some reflection on itself to determine what things are available, to determine what could be printed out to a screen. \n\nIt's a different way of thinking about things than thinking about things as just text processing. It leans into this idea of, well, this is an object, and I can learn some things about this object and use that for display. And this is just an idea popped up with-it might not even be a good one—off the top of my head. But it allows you to think about the world differently, think about the ability to create objects that represent the world on the fly that you didn't know about when your program launched. That's a level of usability that is really great [laughs]. And it may feel weird when you first hear about it, but it ends up being exceptionally useful. \n\nThe next feature I'd like to mention about Ruby that I think is maybe the most idiomatic of all of the Ruby features, and I've mentioned some things that are very Ruby-ish, but there's one that's the most Ruby-ish of all Ruby things, which is that Matz built-in language support with special syntax for anonymous functions. And that is fundamental to your development as a Rubyist. \n\nWe've talked a lot about the object-oriented features. Now, we're going to talk about some of the functional features. Again, Ruby has a built-in syntax with special scoping rules for anonymous functions. They call those anonymous functions blocks. And people who've started using Ruby might not even think about it that way. Like, a block is a function? Well, yeah, it's a function [laughs]. It's a section of code that takes parameters and can execute those parameters. Yeah, that's a function. And that's how Matz talks about them. He designed blocks to be anonymous functions in the Ruby language. \n\nBut, again, they have special scoping rules. These anonymous functions have special scoping rules such that their return semantics will return from the surrounding explicit function. So, if you have a function with this anonymous function inside, the anonymous function will return from the wrapping function rather than from itself if you have an explicit return statement. That allows you to not have to worry about defining it as a..., and this is a fundamental difference between Ruby blocks and anonymous functions in other languages. \n\nYou can return from a Ruby block and return from the enclosing function rather than just returning from itself and then having to figure out what to do. It allows you to build lots of these little lightweight functions throughout your code and not have to worry about handling the return values and then passing them up and then handling a return value and passing them up. Because they'll do just kind of what you expect. Again, Ruby is about trying to make things friendly. It pretty much does what you expect. \n\nIt also means that these anonymous functions are used ubiquitously within Ruby to the point that Ruby almost never uses looping constructs. I say almost never, occasionally, you'll see a loop. Maybe you'll see a while loop that runs forever in some sort of, like, web service listener where something really should run forever. So, infinite loops are actually more common in Ruby than non-infinite loops if it's done explicitly. Because, in most cases, when you have something that can be enumerated over, that is you can step through a thing, you'll just pass an anonymous function to it. You'll pass one of these Ruby blocks. Give a block to it. \n\nAnd instead of having all of the bug-prone, hard-to-understand syntax issues that you get around for loops, or while loops, and maintaining a loop counter, all that just goes away because Ruby is built in containers like arrays, and what's called a lot of different things in a lot of different languages: an associative array, or a dictionary, or a map. Ruby calls it hash. Those are all the same thing. Ruby just happens to call them hashes. I'm talking about kind of the implementation behind it. So, an array, a hash, or a dictionary, whatever you want to call it, and those are, of course, the primary ones. \n\nBut there's some other subtypes of those like sets. You can enumerate over those by just passing an anonymous function to it. There is an array in each method. And there is an integer or a times method. You can do three dot times, pass it a block, and it'll run that block three times. It's a revelation for those of you who [inaudible 26:24] in other languages before you came to Ruby [laughs]. It's like, what? I can do that? [laughs] Yes, you can. Yes, you can. \n\nLike I said, this is the most Ruby-ish thing that you can do in Ruby is you pass these anonymous functions to anything. And because of the nice scoping rules and these are a function, you can do some really nice setup and tear down. So, if, for example, you wanted to set up a connection to some remote service, do something, and then tear down that connection, well, that's great because you can have that in the function, right? You can build that into a function that will do all the setup and tear down and then just run the function that they passed in, in between.\n\nIt allows you to really wrap any piece of code in some setup and tear down and execute that code inside of it. Of course, you can do that in different contexts as well, but being able to pass the function in is just really convenient. In other languages, you do it all the time. If you look at JavaScript, it uses functions, anonymous functions everywhere. But it doesn't have the advantage of the friendly return context that Ruby has where you have to do lots of kind of weird binding sometimes in JavaScript to get the right returning values and get it to return the right thing [laughs] from the right place, where Ruby just kind of does what you'd expect, which is really convenient. \n\nAnybody who's listening to this and you're not looking at the code, you're like, \"Huh, well, what do I make of this?\" Well, go look at some Ruby code [laughs]. And those of you who've been Rubyists for a little while, this may be the most; for me, it was really illuminating. Well, people are telling me about these blocks. This is weird syntax. What is this? Well, it's just an anonymous function. It's an anonymous function with special return semantics. And that allows you to just call this section of code, hand off this section of code to another section of code. \n\nAnd it's really, really useful to be able to hand a section code to another section of code. That idea comes from other languages. Of course, it's not unique to Ruby. These are inspired some, again, by Lisp and macros and by...anonymous function [inaudible 28:19] other languages, but Ruby really leans into it. It means a for loop will almost never be found. I can't remember the last time I saw a for loop in Ruby. They just don't use them because you don't need them. \n\nIn fact, I can't really think of the last time I saw much of an explicit looping structure at all because you think about it functionally. You call map. You call reduce. When you think about your code, it's a series of change and transformations, much as the functional language people do. And I think it's a very effective and less error-prone way to write code. \n\nDOM: You're talking about, like, enumerables and being able to iterate through things. And I actually remember, Mike, it was when you first interviewed me, like, two summers ago. You blew my mind. You were like, \"You will never ever see a for loop in any of our codebase, like, at all whatsoever.\" And I was like, that's not physically possible. Everything I've ever done in my entire –- \n\nMIKE: [laughs]\n\nDOM: Software engineering career has included a for loop. It was awesome to see that you can use these block statements, and they're just so powerful. There's so much you can do to just information while you're running with them. And coming from a language like Java, it was a happy surprise. I was super stoked that I could do dot each and dot map and not have to worry about writing for int i, i is less than counter, i plus plus, you know, all that stuff.\n\nMIKE: And was I right? Have you encountered any for loops in our code? \n\nDOM: No, no. I have not.\n\nMIKE: [laughs]\n\nDOM: And I have adapted the map mentality, never using each ever again.\n\nMIKE: Yeah. --\n\nEDDY: That is an interesting observation. I've never actually noticed that we didn't use [inaudible 29:56] [laughs] in our codebase. I actually wanted to fact-check that really quick. And I went through my IDE, and I wanted to make sure I did global search before. Well, it did pull up some results, but it was just comments [laughter]. Nothing explicitly calling, like, for action on something, which is a really interesting observation I haven't noticed.\n\nMIKE: It makes a big deal into the way you write your code. One thing that has happened in the evolution of programming languages for years is that we try to hand more and more off to the language instead of doing something yourself. We [inaudible 30:31] compilers to figure out the machine language so that we don't have to write the zeros and ones [chuckles] because we want to think about it at a higher level. And we don't use assembly language much anymore in most contexts unless you're maybe writing some sort of embedded software, writing device drivers, or something. \n\nYou write code that thinks at a higher level and then compiles down to that assembly language. Because, honestly, a compiler does a better job of thinking about problems than you do. Because there's been generations of smart people who've been improving those compilers to think about how to solve problems. And in almost all cases, they're going to solve the problem better than you can. And, likewise, now we've got interpreted languages. And there's a range of popular interpreted languages today: Python, JavaScript, Ruby, for example. \n\nAnd if you let the language do the work, you're going to have fewer bugs, and your code is probably going to perform better. If you're writing the loop yourself, you might do it wrong. If you let the language do it, the language is going to get it right. Let the language do it. If there's one thing you take away from this, let the language do the work. If you're doing it yourself, you're doing it the wrong way. The people who designed the tool...if you think you can do it better, you're probably not right. \n\nThere's a lot of people who've been thinking about how to solve this problem within the language you're using, whatever that language is, and the language will probably do it better than you can because it's been designed to. It's been designed to. We shouldn't do the looping. We should let the language do the looping. This is a very functional way to think about things [chuckles]. Functional languages very much lean into this. You shouldn't be doing the looping yourself; let the language do it. Because it lets you think about what the problem is, rather than how you're going to solve the problem. \n\nWell, here's the problem; I want to go through each of these things. Well, let the language go through each of the things. Don't do it yourself. As Dom was saying, use map [laughs], you know, tell the language to return a value from each one of these things that you can enumerate over. Don't do each where you're going to explicitly go through and figure what we're doing for each one. Usually, what you want is to transform a set of things into another set of things. And thinking about the code in terms of that transformation is transformational in the way you think about the problem.\n\nEDDY: I do want to add more to sort of, like, the scope of what Ruby can be used for. When I first started, I initially thought, oh yeah, Ruby, you can do it for web development. And that's what is its intention, and that's what its functionality is for. We did a Skill Clinic project a few months back, going a little bit over a year, where we wrote a service purely on Ruby, right? To go ahead and do some of our assignments, you know, for pull requests. \n\nAnd that really kind of dawned on me, right? Like, Ruby is a lot more dynamic than just web development, right? I mean, granted, you can do web development, like, but it can do, like, web servers, like, data processing, scraping, et cetera. So, it's [chuckles] much more broad than just web development. And I think that's something, for me anyways, that was a little bit of an epiphany when I realized just how dynamic it can be.\n\nMIKE: Yeah, and it's used a lot as a shell scripting language like Perl. We've been talking a lot about web development because, again, that Rails framework. But there's a lot of shell scripting that goes on in Ruby as well. And some popular DevOps frameworks are written in Ruby; kind of think of it as the new Perl [chuckles]. Perl is still around, by the way. And it's an interesting language, if anybody's curious; not as popular as it once was, but still an interesting language. So, we've done kind of a whirlwind tour here. \n\nSERGIO: Yeah, I just wondering why Ruby the popularity has been declining by the years, for example, in comparison with Python [laughs]. I don't know why. Because all the people say that it's because of its slowness, but no, I don't think so. Because many of the company has been using Ruby for a long time. So yeah, I don't know why. \n\nMIKE: Yeah. No, honestly, I think Ruby sometimes outperforms Python, but they are kind of sibling languages. They're languages that fill a very similar role. Python happened to catch on within the machine learning community, which is, like, rocket fuel in the last few years [laughs]. And, really, I think that's it. Python happened to catch on really well within the machine-learning community, which has caused it to explode in popularity. And JavaScript is another interpreted language that's simpler than either Ruby or Python, and yeah, that's got pros and cons, right? [chuckles] \n\nSERGIO: [inaudible 34:50]\n\nMIKE: Simple is good in some ways and not as capable in other ways. But, JavaScript, you have to learn to do web development. So, everybody who has written any front-end code has to learn JavaScript.\n\nSo, when JavaScript became available on the server side, a lot of people said, \"Well, why should I learn more than one language? I'll just go with one language.\" So, JavaScript, in some ways, has become...has filled a lot of a similar role as well. So, I don't know that it's so much that Ruby has failed anyway. It continues to be a popular language. But there are other languages that fill in the same niche, you know, they kind of do the same thing that are popular for other reasons. And that's great. Again, I'm not criticizing JavaScript or Python. I think that they're both very useful within their areas as well. \n\nEDDY: I feel like there is a bit of a stigma behind scalability with Ruby, probably with Ruby on Rails as a whole. But I think the reason to why a lot of us get the impression, well, I'm speaking for myself, is that a huge factor to that was when Twitter decided, hey, it is not scalable. Let's switch away from Ruby on Rails and use a different framework, right? So, for me, that sort of just keeps ringing, right? I'm like, huh, yeah, no, maybe it's good for a quick startup, you know, but not necessarily scalable. And I've realized that that's not true [laughs].\n\nMIKE: Well, I've read about this, I read a really interesting article about this many years ago, so I couldn't tell you where it is, about Twitter specifically. Twitter was originally using MySQL or MySQL, or whatever you want to call it, the database as a router for messages. And that didn't scale. And that's not speaking anything wrong about the database or about the engineers who built the application. It was a good way to do things initially, but that didn't scale as they grew because it wasn't the purpose of the database. The database is not intended to be like a telephony switch. It's not a telecommunications tool. And at scale, because that's not what it's designed for, the intense levels of reads and writes just didn't work. \n\nAnd so, they decided to build their own layer to handle [inaudible 36:48] messaging and all the kinds of caching that go on top of it. And to do that, they did want to have something that was high-performing. And it made sense not to write that in Ruby, right? To use that using a very high-performing language. I believe they did it in Scala, didn't they? Scala, Scala, however, you pronounce it. And which was a kind of a preferred tool of the developer who did it. \n\nAnd I don't object to any of those decisions. But none of that has anything to do with the scalability of Ruby at all, right? Ruby worked great for handling the web front end. But I wouldn't want to use Ruby to do something, you know, some high-performance computing. I'm not going to use Ruby to program a supercomputer because that's not what it's designed for. \n\nYou probably do want once you reach the kind of scale that formerly Twitter, now X, was [inaudible 37:33]. You're going to have to optimize certain parts of your stack. That is advisable regardless of the language that you're using. So, I think we had a lot of those claims. There was kind of some talk around that at the time that Twitter [inaudible 37:48] that I think was just really misleading. \n\nAnd [laughs] if it didn't work, then why are big companies like Shopify and GitHub still using Ruby? Obviously, it works for large companies. That's not really where the concern was, but rather, they just had specific business needs. And really, yeah, they shouldn't be using Ruby for what those specific business needs were or really any language x, right? [laughs] Use the right tool for the job. Whether that'd have been Java, or JavaScript, or Python, anybody who reached that scale would probably have changed languages for that portion of their code, and rightly so. \n\nIn fact, the machine learning aspects, like the deep, nitty-gritty stuff that goes on in Python, isn't written in Python either. It's written in some variant of C, C++. The lower-level tools are not written in Python. But just like in Ruby, you can have extensions in other languages. Python does the same thing. \n\nIf I can go back to where I was at, we've been through this whirlwind tour [laughs] of talking about this language. And, of course, this is a podcast. You're listening to it. You can't see the code. I hope that if you haven't done Ruby, it's given you a taste of what Ruby does and what it's about, and, hopefully, some of why it might be really friendly to developers, why your developer happiness might be increased using that language. \n\nYou can think about things functionally. You don't have to do a lot of things that you would do in other languages, like working around the limitations of integers, of primitives, or having to do all the looping yourself. You can really think about problems in a way that maps well to natural language because it's designed to think more like humans do. \n\nI love Ruby. I have done Ruby now for a long time, close to 20 years. And I've loved it. Again, there's no perfect tool. But I have been very grateful. Matz, if you ever happen to listen to this podcast, thank you. Thank you for your active love toward us in the development community.\n\nEDDY: You know, I actually wanted to retort a bit earlier in the podcast and say, oh, yeah, it's developer happiness, and that's true. Until you have a nasty bug that you can't find for the whole day [laughter]. \n\nSERGIO: But you can find the same issue in whatever language, you know. So, it's in the language the issue.\n\nMIKE: Yeah. And there are people who've complained about Ruby because it makes some things too easy, some of that magic [laughs]. \n\nSERGIO: Yeah, yeah, I heard that before.\n\nMIKE: That you can't find anywhere [laughs]. It's really hard to find because it doesn't exist. So, there are some things that are absolutely harder to find because of that, and we've got to deal with that. So, there's a mindset issue here [chuckles] that you need to learn to think about problems in a different way, and that requires a different set of tools. It's a good call out. Thank you. \n\nI hope that if you're curious, you do go give Ruby a chance. It's a great language. And if not, if Ruby isn't your language, that you've learned some things, to think about problems a little bit differently, and you can use some of the strengths of Ruby in whatever language you are writing. With that, until next time on the Acima Development podcast.","content_html":"The panelists discuss Ruby, a primary programming language at Acima, notable for its popularity in startups and major companies like Shopify and GitHub. They attribute its success to the Ruby on Rails framework and the language's community support. Mike shares a personal story to parallel the complexity of understanding Ruby, linking it to its creator, Yukihiro Matsumoto (Matz), who views Ruby as a language of love, embodying a philosophy of developer happiness and care.
\n\nAdditionally, the group explores Ruby's technical aspects, focusing on its object-oriented and functional programming features and syntax that mirrors spoken language, simplifying programming. They discuss Ruby's history, its influences from languages like Perl, Smalltalk, and Lisp, and its evolution with Ruby on Rails. Additionally, they touch upon Ruby's versatility beyond web development, its role in shell scripting, and considerations regarding its scalability. They end with an endorsement of Ruby for its user-friendly approach to programming, prioritizing problem-solving and user experience!
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development podcast. I'm Mike. I'll be hosting again today. We've got a group of us here with me. But yeah, kind of starting, we've got Sergio, Eddy, Dom, and Jonathan.
\n\nToday is a topic that I have been interested in for almost decades now, which is the Ruby programming language. At Acima, we do a lot with Ruby, and it's been our primary language. It is not the only one we do, but we've done a lot of Ruby for a long time. And I've done Ruby for a long time. A lot of us here have done Ruby for a long time.
\n\nAnd certainly, there's reasons to do Ruby, you know, it's got a community. Ruby on Rails framework has been popular for a while. It was particularly influential, like, I don't know, 15 to 18 years ago [laughs] and has continued to be used a lot by startups in particular. And there are some, you know, major companies using it, such as Shopify or GitHub. There's a community out there of Ruby users. And there's reasons just for that.
\n\nBut today, we're going to talk about the language itself and what it is. So, if you're interested in a quick whirlwind tour of Ruby, that's what we're doing today. And I'd like to start with a story. I think a story is a great way to begin a podcast. When I was in ninth grade, I remember an essay assignment I was given. And I remember because I had no idea what to say. [laughs] And I think we were studying Romeo and Juliet, and we were supposed to write some essay about love. And I don't even remember what exactly about love we were supposed to say, but we were supposed to write something about love.
\n\nAnd I remember that I thought about it, and I didn't know what to do. So, I wrote some sort of silliness about how love is poorly defined and lots of people see it differently. And I spent all of my time talking about the question rather than actually answering it. It was probably a pretty lousy essay [laughs]. I probably wouldn't even remember it. I think I stumbled upon it some years later, and I read through that [laughs].
\n\nBut, you know, I had this question. At that age, I really wasn't sure. I didn't know how to define love very well. And there are a lot of different answers to that in the world. Well, there's one very interesting answer to that question. The Ruby programming language was created by a guy named...I'll try to pronounce his name right. It's Yukihiro Matsumoto, and he's lovingly referred to by the community as just Matz. They shortened his name to just Matz. And he's very much beloved by the community.
\n\nHe has said on more than one occasion that the Ruby language is love, and that says a lot about what the Ruby language is. And I'm going to talk a little bit more about the history [laughs]. But the Ruby language was created to be an embodiment of that idea of, you know, I care about you. I want to make your life better.
\n\nThe Ruby language is built on ethos. And, in fact, there's a saying within the community, "Matz is nice, and so we are nice," MINASWAN [laughs]. The creator is nice. He wants to be nice to us. He tries to be nice to us. He reaches out with his language and also just his demeanor. If you've ever seen him speak, he's just a soft-spoken, super nice guy. And the language reflects that aspect of Matz, the creator.
\n\nIf there's kind of one thing you leave with about what Ruby is, it is this language that's supposed to make you feel good [laughs] and then lift you up as a person. And, hey, well, a programming language does that? Well, it's kind of its goal. Different programming languages have different goals. Some languages have been intended to be very high-performing. They're really good at running fast, and that's a great goal, right? We should have some languages to do that.
\n\nOther languages take a particular idea, like being functional, and take it to its extreme. What would happen if we made a purely functional language? And I'm thinking about Haskell here. But there's some other languages that go that direction. Other languages focus maybe on type safety or on whatever particular problem they have at the time.
\n\nWell, Ruby focuses on developer happiness. It's a language that was designed from the beginning to try to make developers happy so that if you're a software engineer and you use this language, it makes your day a little better. And that's what Ruby is about, as opposed to other languages. It doesn't mean the other languages are bad. In fact, Ruby is not written in Ruby; most implementations of it are not anyway [laughs]. Ruby is written primarily in C, which is one of those high-performing languages. So, every language has its purpose. But Ruby is intended to make your life happier as a developer. Did Matz succeed? [laughs] Do you feel loved?
\n\nEDDY: I'm curious about the time why the name Ruby was given. Was it just because it signified or represented love at the time, or is there some sort of correlation with the name and happiness?
\n\nMIKE: That's a good question. The one thing that I have heard about Ruby is Matz was inspired by Perl, which is another precious stone [chuckles]. And he came up with Ruby to kind of mimic that idea and [inaudible 05:08] Ruby is following kind of a similar niche, where it's an effective scripting language, easy to use. And it may be that Ruby references some of that a lot, you know, it's this red stone. And it's kind of heart-shaped frequently in its cut.
\n\nSo, I can't speak to that for sure. I don't know the answer. You'd have to ask Matz. I have not heard about that. If anybody knows, you know, please speak up. But I was having the same thoughts as I was talking about it. Well, he says Ruby, the language, is love. That stone could represent love. And so, it [laughs] might actually be a symbol that's suggesting that gift he's trying to give back with. Have you felt the love when using Ruby?
\n\nEDDY: It's easy to pick up, I will say that. You take the layer of complexity of syntax out of the equation, and suddenly, you're one step closer to thinking as a programmer.
\n\nMIKE: Ruby is a language that's designed to read a lot like spoken language. That definitely changes the way you think [laughs]. Instead of trying to think like a machine, you think more like a person. Certainly, you do have to think somewhat like a machine for developers [laughs]. But the syntax fits a little more naturally to the way that humans speak.
\n\nLet's talk about that. Let's talk a little about the history and why that might be. So, Ruby, the first release—and I've looked this up—the first version of the Ruby programming language was released on the 21st of December 1995, so we're going on 30 years. It's been around for a long time. And Ruby was and certainly inspired by other programming languages. I'm going to try to quote Matz a bit [chuckles] in several ways.
\n\nBut he said that he was inspired by several other languages. I'm going to point out three of them: Perl, Smalltalk, and Lisp. Perl is this kind of utility knife of a language. You use it for scripting. A lot of early websites...Perl isn't used as much for this anymore. But a lot of the early web applications were built in Perl because it's this really useful text processing language that was originally kind of used more for shell scripts but, well, for other text scripting scenarios like you have with a web app. So, Perl was a big inspiration for Ruby.
\n\nAnd Smalltalk–and I'm going to talk about that next; Smalltalk is a pure object-oriented language. It's not just a language. It's like an environment. You get, like, this Smalltalk environment you interact with, which was actually influential in a lot of other languages. Object-oriented coding has really taken off in the years since, but it was really experimental and new when Smalltalk came out.
\n\nAnd the thinking that everything could be an object was kind of a radical departure from some of the ways other languages think about things, and Ruby embraces that. In Ruby, everything is an object, and when I say everything, I mean everything. An integer is an object. You can call functions on an integer. A string is an object. You can call functions on a string. There are no true primitives in the way that a lot of other languages have. Well, here's the, like, when you think about Java, you have primitives that you don't call things on. They're a different thing from everything else. In Ruby, that's not the case. Everything is an object, kind of taking that Smalltalk inspiration.
\n\nAnd the other language that I'm going to call out is that Lisp, which is a very functional language, kind of the archetypical functional language that other functional languages have drawn from. In functional languages, you think about everything as a function, you know, the unit in functional languages is the function. In object-oriented languages, you think about...you structure your modules with objects, right? And your object is your unit. You have classes, and you build objects from those. Well, functional programming thinks about things a little differently. It groups things in functions, [inaudible 08:47] that objects don't have functions. But when you're thinking about kind of the primary organizational idea in functional languages is functions, and Ruby embraced that from Lisp.
\n\nIn Ruby, every expression has a return value, which means that you can write anything that could reasonably evaluate as an expression in Ruby, and it has a meaningful return value. If you write the number one, you can run a Ruby program with just the number one in it, and that is a valid Ruby program. In some other languages, that wouldn't make any sense, but in Ruby, that makes sense. It's an expression. It's the number one. It has a return value of one. [inaudible 09:23] doing something, right? It's expressing this number, and it even has a return value.
\n\nAnd that changes the way you think about things, this idea that comes from functional programming where everything is an expression. Everything has an implicit return value because that expression evaluates to some value. And that idea is deeply embedded in Ruby as well. Not only is it object-oriented, where everything is an object, everything is also an expression, which implicitly has a return value, which means you could think about every expression as somewhat implicitly being a function as well. It also leans heavily into the idea of anonymous functions, but I'm going to hold off on that for a little bit and go back to this idea of its creation.
\n\nSo, I want to give you a little history of Ruby. Ruby is this language that takes these big ideas of functional programming and object-oriented programming and smashes them together into a scripting language. And it gives you Ruby to try to make this tool that makes developers happy. Ruby was created in Japan. Matz is Japanese. He lives in Japan. I believe he still lives there [laughs]. And has developed there for a long time.
\n\nBecause Ruby was originally in Japan and had documentation in Japanese, it became fairly popular in Japan. It became a popular programming language there because you could get documentation in Japanese. All of us like to be able to read things in our native tongue, so [laughs] it makes a lot of sense. So, it became kind of this niche language that was popular in Japan. Eventually, it started reaching out of Japan as other people discovered it. In particular, in the mid-2000s, there was a development team that decided that they would use Ruby to build a new web framework called Ruby on Rails.
\n\nAnd I believe that Ruby on Rails was—I'd have to go look this up—was released around 2005. It made a big splash in the web application community/web development community by its usage of convention over configuration [laughs]. At the time, most web development involved setting up lots of configuration files for everything. Anybody who did Java development back in the day, you know what I'm talking about [laughs], so many XML files.
\n\nThe Ruby on Rails, this framework, cut through a lot of that and said, oh yeah, let's just do the obvious thing by default. You don't even have to configure it. And the object-relational mapper it had called Active Record, as a result, was really easy to use in a way a lot of other systems weren't. Now, other frameworks have borrowed a lot of those ideas. So, Ruby on Rails really isn't this path setter anymore. It's not in the vanguard because other frameworks have taken the same ideas, which is fantastic. Web development is better as a result.
\n\nBut it meant that Ruby made a big splash and was heavily used by startups in the United States. You know, it had left Japan, still there in Japan, but it became heavily used throughout the world by largely web developers because of the Ruby on Rails framework. It's been somewhat in decline in recent years. Some other languages have become more prominent, but it's still got a thriving community behind it.
\n\nEDDY: Who did the transcribing for when it left Japan, do you know? Like, who did all the documentation translations and --?
\n\nMIKE: That's a great question. I don't personally know the answer to that. I know that Matz himself is, you know, bilingual. He speaks English [laughs]. Japanese is his primary language, but he knows English. He has spent some time in the United States, which I think has helped a lot [laughs], helped him to document things in more languages than one.
\n\nLet's talk a little bit more about the language then. We've talked a little bit about how Ruby is object-oriented all the way down. And it's also functional, deeply functional all the way down. So, I gave an example of how you can just write any expression. You could write a string or an integer. That's a valid Ruby program. Just put a string into a file; that is valid Ruby. It's not very useful [laughs], mind you. But you could run that as a Ruby file and give it a Ruby extension. You don't even need a Ruby extension. Call the Ruby interpreter, and it will be interpreted successfully and will run because every expression is valid Ruby that can be written in Ruby.
\n\nThat has some side effects in that if you have a function written in Ruby, you rarely need explicit return values, and, in fact, most Rubyists don't use them. And this is common among functional languages, that the value of the final expression in the function is implicitly...because everything has a value, right? Every expression evaluates to a value. That is the return value of the function. So, to return something in Ruby, you just simply write the expression you want to be returned as the final line in your function.
\n\nAnd for those who've been using more procedural languages, that is weird. But I'm not going to tell it to return things [laughs]. But, in Ruby, it's not that way. Instead, you think about, well, what does this mean? Well, it's saying something. Well, that's what it's returning, the thing it said. You don't have to say, "Hey, this is the thing I want to say." It's already implied because I've already said it. And that idea, going back to this idea of convention over configuration, kind of goes all the way down. Everything is an expression.
\n\nI'll take that a little bit further. Ruby does not require parentheses in function calls. So, you can call functions without using parentheses; just put some spaces in there. [inaudible 14:30] put commas between your parameters. That means in cases where you have a function that doesn't take any parameters, it's indistinguishable. If you don't put parentheses, it's indistinguishable from another expression. And that can feel kind of weird if you want to be able to tell the difference. Ruby actually kind of leans into that; some Ruby actually kind of leans into that.
\n\nSo, when you're reading the code, you don't have to know if a given line is an expression or a function because it's kind of both. And it allows you to build out domain-specific languages; that is, you can write out code that looks more like configuration than it does, like, a traditional programming language. And you can write out little sub-languages within Ruby that look very much like their own language where some of these things that look like keywords are really just function calls. But they appear to be a keyword because you don't need the parentheses. It makes for some very legible tools; tools such as RSpec, a popular testing framework in Ruby are built in that way.
\n\nOne other thing about Ruby is that there is...I want to be careful how I say this. It is implicitly typed. We do not use explicit typing in Ruby. So, if I set a variable equal to an integer, I never had to declare that that variable was an integer. However, I can't then go and add that integer to a string. That doesn't make sense. So, it is strong typed in that there's not implicit casting; rather, everything is typed. It's just implicitly typed.
\n\nThat also allows you to do some really cool stuff. Unlike in other languages where you might need to write five different copies of a function to take five different types of incoming parameters, you can just write a single method signature that can take the incoming parameter and expect the incoming parameter to be an object. In fact, that's how Ruby expects things to work.
\n\nSince everything is an object, you can pass an object into anything, and they handle the type later. It allows for really clean calling syntax. If for some reason I did want to add a string to an integer, I could write code to do that and make it very transparent. I could make it very transparent so that other people didn't have to know about it. It would just work within my program. I'm not saying that's a good idea, mind you [laughs]. But if you had some need where you needed to add two of your own kinds of objects that were neither integers nor strings, you use a plus sign. It's easy to just define that method to do so and put them together.
\n\nI can take this a little bit further. And this is both a strength and a weakness. Ruby leans into what we call duck typing. That is, if it walks like a duck, talks like a duck, quacks like a duck, it must be a duck [laughs]. And so, what you see commonly in Ruby code is that you don't have a lot of validation on parameters that get passed into functions. You kind of expect the callers to do the right thing.
\n\nSo, if something meets the requirements of what your function needs, you're not going to ask about its type and, instead, you're just going to assume that they gave you what you needed. In other languages, you might use some templating features built into the language. Ruby, you don't need to do that. It's kind of implicitly a template. We're just going to assume that you're going to do the right thing.
\n\nAnd, of course, if you want to do validation, you're more than welcome to do so, but you need to be explicit about it, and it's not going to be built into the language. Again, this is a strength and a weakness. It means that you can have very easy refactoring of your code where you can pass in a different kind of object to a function, and it'll still work.
\n\nOn the flip side, you don't get some of the type safety guarantees that you get in strongly typed languages that put a lot of validation on type. And it means you get different kinds of bugs. It means your code tends to be a lot shorter…a lot easier to reason about in Ruby. However, you can get some type safety bugs that you would not get in other languages because I think it's a big thing to notice.
\n\nThis wading into, hey, you know, everything's an object; you can pass anything anywhere; it allows you to write code that's just amazing, legible, and terse, and easy to refactor. It also means that you can end up with subtle bugs sometimes because type safety bugs are hard to face. I'm not saying that it's a showstopper. But depending on your domain, you know, some people would argue that's a serious problem.
\n\nAnd there actually are several different tools within the Ruby community for dealing with this, for adding type, some that add type within the language, and some that add it by adding an additional file. It's kind of experimental, but you can add a type file adjacent, you know, kind of next to your Ruby file to add typing to it. So, you can get some of that type safety you get from other languages.
\n\nRAMSES: Yeah. There's tools like Sorbet that provides the type checking, which is very interesting.
\n\nMIKE: And for large companies, like, Sorbet came...did that come out of Shopify? I'm trying to remember --
\n\nRAMSES: Yeah, yeah, I believe so.
\n\nMIKE: I believe so, too. They built this tool because they wanted to have the best of both worlds. They wanted the expressiveness and ease of use of Ruby but still have the type safety. So, they've built some tooling to provide that. So, there's tools available to give you the type safety that you'd like to have in Ruby, if that's something that's important to your use case. And I think that it's important to a lot of use cases, something that I actually encourage leaning into in a new Ruby project. It avoids certain kinds of bugs and allows you to be explicit about what you intended to happen.
\n\nThe next thing I'd like to talk about that Ruby does...we talked about everything is an object. We talked [laughs] about some of the things it does, getting those advantages of being truly purely object-oriented where everything is an object. Actually, I'm going to talk a little bit more about that. [inaudible 20:06] everything is an object. It also has some sort of class, you know, that prototype that you use to define it. And you do not have to completely define that class before your code runs. It can be written at runtime. It also means that you can reopen classes and start adding functions to them or even change their behavior at runtime.
\n\nComing back to this Lisp idea [chuckles], I mentioned Lisp before as one of the inspirations for Ruby. In Lisp, you can rewrite the program. The program can write itself as it runs. And that's a really weird idea when you first hear about it. We actually do it all the time in Ruby. We have code that writes code.
\n\nI mentioned the Object Relational Mapper in Ruby on Rails, ActiveRecord. It accomplishes a lot of what it does by what people call magic, but not exactly magic. It just uses Ruby's features to go in and look at your database, check out the table name, and figure out where the columns are, and let's go ahead and write some functions. Go ahead and write some functions at runtime into your class to be accessors to those column names within a record.
\n\nAnd so, rather than having to explicitly define something that's already there, it can just look it up and generate it on the fly. You're not usually going to do that in your code, but for a framework, that's amazing. It means that a lot of the configuration...if something is discoverable in the world, the code can write itself. It can go out and write methods at runtime that didn't have to be conceived of [laughs] by the people who wrote the framework. They just had to write code that's able to do that perception of the outside world and deal with it accordingly.
\n\nIt's amazingly powerful. And it's one of the strongest aspects of the Ruby on Rails framework because it allows it to be very terse and very easy to understand. So, it's a practical use, right? Why would a code want to write code? Well, it's because you don't necessarily know, when you're writing a framework, what code you're going to be working with. And you don't want to have to explicitly say all those things because it's discoverable. So, code that can discover some things about the world around itself and write new code within itself to deal with those things is actually incredibly useful.
\n\nListeners can probably think, oh yeah, well, what's some things I could discover? Well, maybe you're working with some web service that tells you about the weather. Well, you could have code that goes and pulls that and figures out what fields are available and then creates functions to tell you. And then, again, while running live, it could do some self-analysis, some reflection on itself to determine what things are available, to determine what could be printed out to a screen.
\n\nIt's a different way of thinking about things than thinking about things as just text processing. It leans into this idea of, well, this is an object, and I can learn some things about this object and use that for display. And this is just an idea popped up with-it might not even be a good one—off the top of my head. But it allows you to think about the world differently, think about the ability to create objects that represent the world on the fly that you didn't know about when your program launched. That's a level of usability that is really great [laughs]. And it may feel weird when you first hear about it, but it ends up being exceptionally useful.
\n\nThe next feature I'd like to mention about Ruby that I think is maybe the most idiomatic of all of the Ruby features, and I've mentioned some things that are very Ruby-ish, but there's one that's the most Ruby-ish of all Ruby things, which is that Matz built-in language support with special syntax for anonymous functions. And that is fundamental to your development as a Rubyist.
\n\nWe've talked a lot about the object-oriented features. Now, we're going to talk about some of the functional features. Again, Ruby has a built-in syntax with special scoping rules for anonymous functions. They call those anonymous functions blocks. And people who've started using Ruby might not even think about it that way. Like, a block is a function? Well, yeah, it's a function [laughs]. It's a section of code that takes parameters and can execute those parameters. Yeah, that's a function. And that's how Matz talks about them. He designed blocks to be anonymous functions in the Ruby language.
\n\nBut, again, they have special scoping rules. These anonymous functions have special scoping rules such that their return semantics will return from the surrounding explicit function. So, if you have a function with this anonymous function inside, the anonymous function will return from the wrapping function rather than from itself if you have an explicit return statement. That allows you to not have to worry about defining it as a..., and this is a fundamental difference between Ruby blocks and anonymous functions in other languages.
\n\nYou can return from a Ruby block and return from the enclosing function rather than just returning from itself and then having to figure out what to do. It allows you to build lots of these little lightweight functions throughout your code and not have to worry about handling the return values and then passing them up and then handling a return value and passing them up. Because they'll do just kind of what you expect. Again, Ruby is about trying to make things friendly. It pretty much does what you expect.
\n\nIt also means that these anonymous functions are used ubiquitously within Ruby to the point that Ruby almost never uses looping constructs. I say almost never, occasionally, you'll see a loop. Maybe you'll see a while loop that runs forever in some sort of, like, web service listener where something really should run forever. So, infinite loops are actually more common in Ruby than non-infinite loops if it's done explicitly. Because, in most cases, when you have something that can be enumerated over, that is you can step through a thing, you'll just pass an anonymous function to it. You'll pass one of these Ruby blocks. Give a block to it.
\n\nAnd instead of having all of the bug-prone, hard-to-understand syntax issues that you get around for loops, or while loops, and maintaining a loop counter, all that just goes away because Ruby is built in containers like arrays, and what's called a lot of different things in a lot of different languages: an associative array, or a dictionary, or a map. Ruby calls it hash. Those are all the same thing. Ruby just happens to call them hashes. I'm talking about kind of the implementation behind it. So, an array, a hash, or a dictionary, whatever you want to call it, and those are, of course, the primary ones.
\n\nBut there's some other subtypes of those like sets. You can enumerate over those by just passing an anonymous function to it. There is an array in each method. And there is an integer or a times method. You can do three dot times, pass it a block, and it'll run that block three times. It's a revelation for those of you who [inaudible 26:24] in other languages before you came to Ruby [laughs]. It's like, what? I can do that? [laughs] Yes, you can. Yes, you can.
\n\nLike I said, this is the most Ruby-ish thing that you can do in Ruby is you pass these anonymous functions to anything. And because of the nice scoping rules and these are a function, you can do some really nice setup and tear down. So, if, for example, you wanted to set up a connection to some remote service, do something, and then tear down that connection, well, that's great because you can have that in the function, right? You can build that into a function that will do all the setup and tear down and then just run the function that they passed in, in between.
\n\nIt allows you to really wrap any piece of code in some setup and tear down and execute that code inside of it. Of course, you can do that in different contexts as well, but being able to pass the function in is just really convenient. In other languages, you do it all the time. If you look at JavaScript, it uses functions, anonymous functions everywhere. But it doesn't have the advantage of the friendly return context that Ruby has where you have to do lots of kind of weird binding sometimes in JavaScript to get the right returning values and get it to return the right thing [laughs] from the right place, where Ruby just kind of does what you'd expect, which is really convenient.
\n\nAnybody who's listening to this and you're not looking at the code, you're like, "Huh, well, what do I make of this?" Well, go look at some Ruby code [laughs]. And those of you who've been Rubyists for a little while, this may be the most; for me, it was really illuminating. Well, people are telling me about these blocks. This is weird syntax. What is this? Well, it's just an anonymous function. It's an anonymous function with special return semantics. And that allows you to just call this section of code, hand off this section of code to another section of code.
\n\nAnd it's really, really useful to be able to hand a section code to another section of code. That idea comes from other languages. Of course, it's not unique to Ruby. These are inspired some, again, by Lisp and macros and by...anonymous function [inaudible 28:19] other languages, but Ruby really leans into it. It means a for loop will almost never be found. I can't remember the last time I saw a for loop in Ruby. They just don't use them because you don't need them.
\n\nIn fact, I can't really think of the last time I saw much of an explicit looping structure at all because you think about it functionally. You call map. You call reduce. When you think about your code, it's a series of change and transformations, much as the functional language people do. And I think it's a very effective and less error-prone way to write code.
\n\nDOM: You're talking about, like, enumerables and being able to iterate through things. And I actually remember, Mike, it was when you first interviewed me, like, two summers ago. You blew my mind. You were like, "You will never ever see a for loop in any of our codebase, like, at all whatsoever." And I was like, that's not physically possible. Everything I've ever done in my entire –-
\n\nMIKE: [laughs]
\n\nDOM: Software engineering career has included a for loop. It was awesome to see that you can use these block statements, and they're just so powerful. There's so much you can do to just information while you're running with them. And coming from a language like Java, it was a happy surprise. I was super stoked that I could do dot each and dot map and not have to worry about writing for int i, i is less than counter, i plus plus, you know, all that stuff.
\n\nMIKE: And was I right? Have you encountered any for loops in our code?
\n\nDOM: No, no. I have not.
\n\nMIKE: [laughs]
\n\nDOM: And I have adapted the map mentality, never using each ever again.
\n\nMIKE: Yeah. --
\n\nEDDY: That is an interesting observation. I've never actually noticed that we didn't use [inaudible 29:56] [laughs] in our codebase. I actually wanted to fact-check that really quick. And I went through my IDE, and I wanted to make sure I did global search before. Well, it did pull up some results, but it was just comments [laughter]. Nothing explicitly calling, like, for action on something, which is a really interesting observation I haven't noticed.
\n\nMIKE: It makes a big deal into the way you write your code. One thing that has happened in the evolution of programming languages for years is that we try to hand more and more off to the language instead of doing something yourself. We [inaudible 30:31] compilers to figure out the machine language so that we don't have to write the zeros and ones [chuckles] because we want to think about it at a higher level. And we don't use assembly language much anymore in most contexts unless you're maybe writing some sort of embedded software, writing device drivers, or something.
\n\nYou write code that thinks at a higher level and then compiles down to that assembly language. Because, honestly, a compiler does a better job of thinking about problems than you do. Because there's been generations of smart people who've been improving those compilers to think about how to solve problems. And in almost all cases, they're going to solve the problem better than you can. And, likewise, now we've got interpreted languages. And there's a range of popular interpreted languages today: Python, JavaScript, Ruby, for example.
\n\nAnd if you let the language do the work, you're going to have fewer bugs, and your code is probably going to perform better. If you're writing the loop yourself, you might do it wrong. If you let the language do it, the language is going to get it right. Let the language do it. If there's one thing you take away from this, let the language do the work. If you're doing it yourself, you're doing it the wrong way. The people who designed the tool...if you think you can do it better, you're probably not right.
\n\nThere's a lot of people who've been thinking about how to solve this problem within the language you're using, whatever that language is, and the language will probably do it better than you can because it's been designed to. It's been designed to. We shouldn't do the looping. We should let the language do the looping. This is a very functional way to think about things [chuckles]. Functional languages very much lean into this. You shouldn't be doing the looping yourself; let the language do it. Because it lets you think about what the problem is, rather than how you're going to solve the problem.
\n\nWell, here's the problem; I want to go through each of these things. Well, let the language go through each of the things. Don't do it yourself. As Dom was saying, use map [laughs], you know, tell the language to return a value from each one of these things that you can enumerate over. Don't do each where you're going to explicitly go through and figure what we're doing for each one. Usually, what you want is to transform a set of things into another set of things. And thinking about the code in terms of that transformation is transformational in the way you think about the problem.
\n\nEDDY: I do want to add more to sort of, like, the scope of what Ruby can be used for. When I first started, I initially thought, oh yeah, Ruby, you can do it for web development. And that's what is its intention, and that's what its functionality is for. We did a Skill Clinic project a few months back, going a little bit over a year, where we wrote a service purely on Ruby, right? To go ahead and do some of our assignments, you know, for pull requests.
\n\nAnd that really kind of dawned on me, right? Like, Ruby is a lot more dynamic than just web development, right? I mean, granted, you can do web development, like, but it can do, like, web servers, like, data processing, scraping, et cetera. So, it's [chuckles] much more broad than just web development. And I think that's something, for me anyways, that was a little bit of an epiphany when I realized just how dynamic it can be.
\n\nMIKE: Yeah, and it's used a lot as a shell scripting language like Perl. We've been talking a lot about web development because, again, that Rails framework. But there's a lot of shell scripting that goes on in Ruby as well. And some popular DevOps frameworks are written in Ruby; kind of think of it as the new Perl [chuckles]. Perl is still around, by the way. And it's an interesting language, if anybody's curious; not as popular as it once was, but still an interesting language. So, we've done kind of a whirlwind tour here.
\n\nSERGIO: Yeah, I just wondering why Ruby the popularity has been declining by the years, for example, in comparison with Python [laughs]. I don't know why. Because all the people say that it's because of its slowness, but no, I don't think so. Because many of the company has been using Ruby for a long time. So yeah, I don't know why.
\n\nMIKE: Yeah. No, honestly, I think Ruby sometimes outperforms Python, but they are kind of sibling languages. They're languages that fill a very similar role. Python happened to catch on within the machine learning community, which is, like, rocket fuel in the last few years [laughs]. And, really, I think that's it. Python happened to catch on really well within the machine-learning community, which has caused it to explode in popularity. And JavaScript is another interpreted language that's simpler than either Ruby or Python, and yeah, that's got pros and cons, right? [chuckles]
\n\nSERGIO: [inaudible 34:50]
\n\nMIKE: Simple is good in some ways and not as capable in other ways. But, JavaScript, you have to learn to do web development. So, everybody who has written any front-end code has to learn JavaScript.
\n\nSo, when JavaScript became available on the server side, a lot of people said, "Well, why should I learn more than one language? I'll just go with one language." So, JavaScript, in some ways, has become...has filled a lot of a similar role as well. So, I don't know that it's so much that Ruby has failed anyway. It continues to be a popular language. But there are other languages that fill in the same niche, you know, they kind of do the same thing that are popular for other reasons. And that's great. Again, I'm not criticizing JavaScript or Python. I think that they're both very useful within their areas as well.
\n\nEDDY: I feel like there is a bit of a stigma behind scalability with Ruby, probably with Ruby on Rails as a whole. But I think the reason to why a lot of us get the impression, well, I'm speaking for myself, is that a huge factor to that was when Twitter decided, hey, it is not scalable. Let's switch away from Ruby on Rails and use a different framework, right? So, for me, that sort of just keeps ringing, right? I'm like, huh, yeah, no, maybe it's good for a quick startup, you know, but not necessarily scalable. And I've realized that that's not true [laughs].
\n\nMIKE: Well, I've read about this, I read a really interesting article about this many years ago, so I couldn't tell you where it is, about Twitter specifically. Twitter was originally using MySQL or MySQL, or whatever you want to call it, the database as a router for messages. And that didn't scale. And that's not speaking anything wrong about the database or about the engineers who built the application. It was a good way to do things initially, but that didn't scale as they grew because it wasn't the purpose of the database. The database is not intended to be like a telephony switch. It's not a telecommunications tool. And at scale, because that's not what it's designed for, the intense levels of reads and writes just didn't work.
\n\nAnd so, they decided to build their own layer to handle [inaudible 36:48] messaging and all the kinds of caching that go on top of it. And to do that, they did want to have something that was high-performing. And it made sense not to write that in Ruby, right? To use that using a very high-performing language. I believe they did it in Scala, didn't they? Scala, Scala, however, you pronounce it. And which was a kind of a preferred tool of the developer who did it.
\n\nAnd I don't object to any of those decisions. But none of that has anything to do with the scalability of Ruby at all, right? Ruby worked great for handling the web front end. But I wouldn't want to use Ruby to do something, you know, some high-performance computing. I'm not going to use Ruby to program a supercomputer because that's not what it's designed for.
\n\nYou probably do want once you reach the kind of scale that formerly Twitter, now X, was [inaudible 37:33]. You're going to have to optimize certain parts of your stack. That is advisable regardless of the language that you're using. So, I think we had a lot of those claims. There was kind of some talk around that at the time that Twitter [inaudible 37:48] that I think was just really misleading.
\n\nAnd [laughs] if it didn't work, then why are big companies like Shopify and GitHub still using Ruby? Obviously, it works for large companies. That's not really where the concern was, but rather, they just had specific business needs. And really, yeah, they shouldn't be using Ruby for what those specific business needs were or really any language x, right? [laughs] Use the right tool for the job. Whether that'd have been Java, or JavaScript, or Python, anybody who reached that scale would probably have changed languages for that portion of their code, and rightly so.
\n\nIn fact, the machine learning aspects, like the deep, nitty-gritty stuff that goes on in Python, isn't written in Python either. It's written in some variant of C, C++. The lower-level tools are not written in Python. But just like in Ruby, you can have extensions in other languages. Python does the same thing.
\n\nIf I can go back to where I was at, we've been through this whirlwind tour [laughs] of talking about this language. And, of course, this is a podcast. You're listening to it. You can't see the code. I hope that if you haven't done Ruby, it's given you a taste of what Ruby does and what it's about, and, hopefully, some of why it might be really friendly to developers, why your developer happiness might be increased using that language.
\n\nYou can think about things functionally. You don't have to do a lot of things that you would do in other languages, like working around the limitations of integers, of primitives, or having to do all the looping yourself. You can really think about problems in a way that maps well to natural language because it's designed to think more like humans do.
\n\nI love Ruby. I have done Ruby now for a long time, close to 20 years. And I've loved it. Again, there's no perfect tool. But I have been very grateful. Matz, if you ever happen to listen to this podcast, thank you. Thank you for your active love toward us in the development community.
\n\nEDDY: You know, I actually wanted to retort a bit earlier in the podcast and say, oh, yeah, it's developer happiness, and that's true. Until you have a nasty bug that you can't find for the whole day [laughter].
\n\nSERGIO: But you can find the same issue in whatever language, you know. So, it's in the language the issue.
\n\nMIKE: Yeah. And there are people who've complained about Ruby because it makes some things too easy, some of that magic [laughs].
\n\nSERGIO: Yeah, yeah, I heard that before.
\n\nMIKE: That you can't find anywhere [laughs]. It's really hard to find because it doesn't exist. So, there are some things that are absolutely harder to find because of that, and we've got to deal with that. So, there's a mindset issue here [chuckles] that you need to learn to think about problems in a different way, and that requires a different set of tools. It's a good call out. Thank you.
\n\nI hope that if you're curious, you do go give Ruby a chance. It's a great language. And if not, if Ruby isn't your language, that you've learned some things, to think about problems a little bit differently, and you can use some of the strengths of Ruby in whatever language you are writing. With that, until next time on the Acima Development podcast.
","summary":"","date_published":"2024-01-17T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/b4646d0a-12e6-4ca7-ae64-a3df9a704d11.mp3","mime_type":"audio/mpeg","size_in_bytes":19732118,"duration_in_seconds":2456}]},{"id":"950baf66-c07d-4a81-90aa-e6e069a7df13","title":"Episode 36: Dubugging Tools","url":"https://acima-development.fireside.fm/36","content_text":"The panelists discuss the nature of debugging in software development. What even is a bug? Various perspectives are shared, highlighting that bugs often result from unexpected behavior in software despite the software doing exactly what it was programmed to do. Sometimes bugs, sometimes seen as errors, can become features or lead to new insights.\n\nThe discussion shifts to more philosophical and methodological aspects of debugging. It's pointed out that encountering bugs in software implies a need for more understanding of the program or the problem it solves. This realization opens avenues for deeper exploration and learning rather than fixing a fault. The role of testing in avoiding bugs is emphasized, particularly the importance of understanding and aligning with user expectations. The group also touches on the evolution of debugging techniques over time, moving from simple console printouts to more sophisticated methods but still acknowledging the effectiveness of basic approaches in specific scenarios.\n\nAdditionally, they talk about the complexities of debugging in a modern, service-based architecture, where bugs might involve multiple services and systems. Strategies like dividing the problem space, creating narratives or models to understand the issue, and ensuring environmental consistency are discussed, and the conversation ends with a focus on the human aspect of debugging, including the necessity of taking breaks, the value of teamwork and peer review, and recognizing one's own cognitive limitations during the debugging process.\n\nTranscript:\n\nDAVID: Hello, and welcome to the Acima developer podcast. I'm David Brady, and we are going to talk about debugging today. And we put out the call that we're going to talk about debugging, and we got quite a quorum. So, it's exciting. We've got just a whole pile of people on. When you jump in the call, just tell us who you are, and we'll just go from there. Debugging, why?\n\nTAD: Well, should we even get more simple than that? \n\nDAVID: Sure.\n\nTAD: What exactly is a bug? What would you call -- \n\nDAVID: Okay, yeah.\n\nTAD: Is it bad values? Is it bad process? Is it bad behavior? Like --\n\nEDDY: I would like to premise that bugs, historically, have led to some really good features. \n\nDAVID: Minor trivia bit: the very first bug was an actual bug. Google that if you want. Grace Hopper fished an actual moth out of one of the relays, one of the very first computers. And there's a picture of it online. She taped it in her journal and saved it for posterity.\n\nMIKE: Well, that says something about what a bug is, though. She went and pulled that out of the relay because there was unexpected behavior. \n\nDAVID: Yes.\n\nMIKE: [laughs] And the software does exactly what we tell it to do. The problem is sometimes that doesn't match our expectations. And that can be a minor inconvenience, or a neutral, even a positive thing, or it can be catastrophic [laughs]. I worked at a plant nursery many years ago. And my boss asked me, \"What's a weed?\" And I tried to give some explanation. And he says, \"A weed is any plant that's growing where you don't want it.\" Bugs is kind of the same thing. I think it's unexpected behavior.\n\nDAVID: One of the best things that somebody told me really early on in my career is kind of an intellectual ego check. He said, \"Whenever you have a defect in your software or a bug in your software, it means you don't understand your program.\" And I'm like, \"But yes, I do,\" oh, no, I don't. Provably, I do not because I think it will do this, and the computer is doing something else. \n\nAnd that kind of opens you up to the wonder and puts you in a positive frame of mind of like, well, I need to figure out why this is doing this, rather than, like, I'm dumb, or the computer is dumb. Just like, okay, I wanted this, but I got that. Let's figure out why. \n\nMATT: And that could also mean that you don't understand the problem that you're trying to solve.\n\nDAVID: Or the solution, right? You don't understand the solution you're trying to do. \n\nTAD: I thought it was really interesting...last week, David and I wrote some code together, and we put it in production. And they had us pull it back out. And some of the people in management are like, \"Well, you should have tested it better.\" And the thing is, we had written a bunch of tests for it, and the behavior was exactly what we thought the behavior should be. \n\nBut when we put that in production, the people who were using it were like, \"Wait, this isn't what I wanted. This wasn't what I expected.\" This wasn't [laughs]...like, the tests proved that the behavior was exactly what we thought it should be. But it was unintended, unexpected behavior by the end user. And so, technically, is that a bug? I guess if it's unintended behavior, and it's from somebody's perspective that's using it.\n\nMATT: And maybe we can talk about how do we prevent these bugs, right? I think it starts with a clear understanding of requirements, a clear definition of requirements, and testing, too, those requirements. Because a lot of times in software, the business side will have a lot different expectation than we do on the engineering side of what should happen, right? And I think if you can clearly define those things, then we run into fewer, what we call, bugs.\n\nDAVID: That's an interesting definition. One of the early things that we talked about when unit testing was getting popular in the early days of XP, so, like, we're talking, like, Y2K, like, 20 years ago, they mentioned that one of the great things about a unit test is that it restates the problem or, you know, it kind of describes the behavior at a higher level. \n\nAnd it gives you this ability to go to, like, the end user and say, \"Is this not what you wanted it to do? Because if this is what you wanted it to do, I've got green dots. I can prove that it does this. But this is that, right?\" It's like, \"No, that's not what I wanted it to do. I wanted this other thing.\"\n\nMATT: Yeah. You know, many, many, many moons ago, before all of these testing frameworks existed, we were writing code based on our expectations, right? The early days, old PHP days, Perl days, those are the languages I was in primarily, you know, 20-plus years ago. We were creating our expected behavior, and it was really hard to meet the needs of the requester because there was no clear test case to prove that you're meeting those needs. So, you run into a lot of unintended consequences and a lot of downstream problems. \n\nJUSTIN: One of the things I've seen as well in my career was, initially, I was programming to meet the requirements. And then, I was programming to meet the requirements, assuming that the customer is an idiot. And now I'm programming to assume that the customer is malevolent. So, it goes along to, you know, really define what your requirements are and what your limits are.\n\nDAVID: You've moved from programming Murphy's computer to programming Satan's computer, right?\n\nJUSTIN: [laughs]\n\nDAVID: The actual quote from a security talk I went to a while ago which is that Murphy's computer, anything that can go wrong, will go wrong. Satan's computer, everything that can go wrong will go wrong, at the same time, at the worst possible moment because that's what an attacker will engineer, right? \n\nMATT: That being said, what happens when we introduce a bug? How do we track them down? What tools are we using to find them? And what is everyone doing? Because I imagine everyone in this room and on this call uses some different techniques.\n\nMIKE: Can I say something here on this one? In some groups, I'm an outlier; in some groups, I'm not. Early in my software development career, I learned to be kind of shy of debuggers because they sometimes got in my way [laughs]. You know, they're great when they work, and other times, they're slow, and they break. And then, you could spend a lot of time wrestling with the tool rather than solving the problem. \n\nSo, almost all of my career, I may print out a line to the console debugger more than anything else. I'll go in my code, have it print something out. It works in every language. You can have a consistent process that you just know what to expect. You can get good at it. You can get it to print something out. You run the code. You exercise it. You know that you're exercising that code because you get something printed out. You get good at filtering through logs. It's a really straightforward process that anybody can do.\n\nI don't want to say that debuggers can't be useful, and sometimes they can be really useful. I might have used, like, a C debugger to debug Ruby to try to get down to some really gnarly stuff before, but I do that very, very rarely. And I find that just printing out stuff to the console is extremely effective. Because, for me, the most important thing I'm wanting to do when I'm debugging is figure out what's going on somewhere. If the bug is something that's unexpected, then there's something in there that I don't understand. \n\nAnd so, I want to document, you know, to have some documentation thrown out from the code saying, \"This is what's going on here,\" so I can figure out where my expectations are not being met. And I think that we'll probably talk about more sophisticated tools than that. But I think that kind of helps set the stage for further conversation is that what we're really trying to do is figure out what's going on. And simple tools, honestly, I've been doing this for a long time, and they've served me very well. \n\nMATT: Seeing your output, right? Because, generally, that's the bug is you're getting output that is unexpected. And just seeing the output as you step through your methods or your classes it's powerful. And that's generally how I track them down as well.\n\nTAD: Some of the hardest bugs I've ever had have been bugs with, like, timing issues, where the IO of a put statement or a print statement throws off the timing. And so, putting print statements in fixes the problem, and taking the print statements out reintroduces the problem. \n\nMATT: Nice.\n\nDAVID: Nice, a wicked Heisenberg.\n\nEDDY: What's a Heisenberg?\n\nDAVID: Oh, sorry --\n\nMIKE: Ooh, you're learning a beautiful, new word [laughs].\n\nDAVID: Yes. So, it's a corruption of the Heisenberg Principle, which is that at the quantum level, you cannot observe a thing without changing it because the act of bouncing a photon off of an electron moves the electron, right? You can't observe something, so... And so, yeah, Heisenberg is a bug that when you look at it, it changes, or it goes away. \n\nMy favorite demonstration of this is some code, and you're teaching somebody to step through it in the debugger. So, you write a loop. It's like ten times do, and then you seed the random number generator with time dot now. And then you say, print, you know, puts, you know, rand, and it puts rand 10, right? And so, you run it, and you step through it in the debugger, step, step, step, three, step, step, step, five, step, step, step nine, right?\n\nAnd then you take out the debugger, and you run it, and you get 7777777. It's all sevens. And you're like, what? Time dot now returns time down to the second. If your entire program runs inside one second, you're seeding the random number [inaudible 09:24]. But if you're standing there going, 'next instruction' in the debugger, you're burning down the clock. And that changes the state of the time input.\n\nEDDY: So, it's actually really interesting. Mike, you mentioned...you said that you, early in your career, you printed stuff out, right? Do you actively use that as part of your go-to resource in order to debug something, or has that –- \n\nMIKE: It's almost my exclusive resource still, after decades. [crosstalk 09:50]\n\nJUSTIN: So, when you print stuff out, at what logging level are you printing it out? \n\nMIKE: Oh, good question. So, guys, nothing against using log levels, right? Using a logger saying...my default, it depends [laughs]. It depends. If I'm in a local environment, I'll probably use debug. That way, it's harmless if it actually went into production [laughs] because production doesn't have debug turned on. It's a nice little safety thing. \n\nJUSTIN: I'd like to push back on that just a little bit because I have seen releases to production with the debug turned on because it didn't understand which environment it was in. And that resulted in passwords being [laughs] put out in the logs. \n\nMIKE: Oooh.\n\nDAVID: Oooh.\n\nJUSTIN: So, that was a fun time. But I think that even if you are debugging or you're doing a debug log level, you shouldn't ever debug with PII data. And so, either mask that or log something else that will help you debug. That's my only advice there, so...\n\nMATT: And for context, to our listeners who are not going to visually see this, that was Justin who was just speaking. And he is on the Acima security team. [laughter] \n\nJUSTIN: Yes.\n\nDAVID: You guys are actually implicitly talking about something that I think is really, really interesting. I will debug with puts statement. I won't even use logger.debug. I'll use puts. \n\nMIKE: I do, too.\n\nDAVID: It's sloppy. It works great from localhost. And we have a code quality checker that will say, \"Don't use puts; use logger.\" I'm like, no. What I want is to delete this, right? \n\nMIKE: Exactly.\n\nDAVID: But I don't --\n\nMIKE: That's actually what I usually do as well, too [laughs].\n\nMATT: I do the same. I use Awesome Print because it formats for me and makes things look a little nicer.\n\nDAVID: Oooh. Awesome Print is a tool I haven't looked at. That, I'll have to check that one out.\n\nEDDY: Can you explain what Awesome Print is? When you're done, Dave.\n\nDAVID: Yes. I was just going to say the converse is that if I'm running something on preflight, I don't have access to the IO console, or if I'm...well, in production. This week, I got access to preflight, so I can see things that go to the console there. But, like, in production, I don't have that. So, going to a logger is really good. \n\nBut you know what also falls down in production? Is running the debugger because I can't stop the server, you know, remotely. I mean, I can. Right now, I can. Justin would stop me if I did, at least in production. But, like, that's a bad idea, right? Bringing down the entire website just so you can debug something in one thread, probably a bad idea. So, there's trade-offs here. It's fantastic. Eddy, you were asking about Awesome Print. Matt, tell us about Awesome Print. \n\nMATT: It's a Ruby thing. It's a gem. It will just output to your console, but it formats for you. It'll color-code hashes, you know, just make things really readable and legible. I use it every single day, and that's my go-to usually. Second would probably be Pry. But I also still do some really old-school techniques, and that is just tail dash f my development log, and that way, I can see live output.\n\nDAVID: There's a lovely thing...we got to see if we can track down Charity Majors see if she would come on. She loves talking on and on and on about observability. And she works at a company that does logging and metrics, and so she's all about that. But when you talk to somebody about this, you start realizing that's all debugging really is, right? Is we've got all these questions, like, what's going on, and how can I look into this? Where can I get some observability into my data, or pretty-printing, console debugging, and logging, right? \n\nI will say, as a person who came from, like, the C world and debugging, I spent a ton of time down in, like, Ruby debug land. I love using, like, Byebug because I can watch a variable. I can do a thing where it's like, I don't know who's changing this, but I can stop the program when they do. And I can, you know, put a breakpoint on this. And then I can walk away and go do another thing. And then boom, it hits. It triggers. That's a little harder to deal with. \n\nBut, I guess, with the puts, you could go in and say, you know, \"Print when this happens.\" But if it's like a variable, like a change on a variable, you can track that. And that's very, very exciting to watch something, you know, live, but have the thing actually fire a trigger and say, \"No, no, no, no, hang on. We want to talk about this.\" And that's, like, a great observability tool.\n\nMATT: Yeah, and for things like Ruby, you can step through with debuggers, and a lot of the IDEs just provide them. And that's nice. I rarely use them because, generally, the things that I am looking for I know where to look. But that's really powerful if things are happening deeper in your stack, and you don't know what you're looking for.\n\nDAVID: Yeah. The downside compared to Pry of, like, Byebug or Ruby debug is that your REPL, your little read-eval-print loop thing, is just kind of, like, a one-line thing. You can evaluate a statement in Byebug, and it will return you the value, but, like, modifying code on the fly is a little bit trickier. \n\nI know that the folks that use Pry love this because it basically gives you an IRB prompt. You can rewrite a function and then rerun it. I am not super fluent in that. Is somebody here...does anybody on the call like to do it that way? If not, we can tell people to go Google it. But does anybody here debug that way, that's good at that way, that can talk to that?\n\nMATT: I've done it a little bit. If I have an idea of a change, if I'm in the right console, occasionally, I'll make that change, and then see if the output is what I expect, and then go make the change in the code. I wouldn't say I do it often, but I certainly have done it.\n\nEDDY: I think I use it religiously, honestly. \n\nDAVID: You do? \n\nEDDY: Yeah. Like, I'll inspect something, and I'm like, cool, is this outputting whatever I expect it to output? Or, you know, if I have a check in place, you know, like, if current user dot permission granted, or whatever, and like, I'm trying to make sure that it does have the right rules or whatever. Or if I'm checking for a bool output, I want to make sure that that [inaudible 15:43] class is doing what I expect it to do. It could be a typo, you know; it could be checking something that I wasn't expecting. So, being able to manipulate the data inside that session is pretty nice.\n\nDAVID: Fantastic. Does anybody here use, like, the code rewriting ability by Pry? Because that gives an IRB prompt. You can literally just, like, open a class and jam in a method. There's a related technique that I also don't do, which is writing code at an IRB prompt or at a Rails console. Does anybody use that technique? \n\nMATT: That's what I was referring to. Like, if I have a class method that is doing something unexpected and I have an idea for a change, I'll just put the entire method in and rewrite it inside of the console.\n\nDAVID: Okay, yeah.\n\nMIKE: I do a REPL all the time, you know, that's why I use simple, you know, print statement out to the, you know, standard out. And then when I want to test something, I'll pull up, you know, the interactive console and play with it. Software isn't quite tangible. That's about as close as you get to tangible [laughs]. \n\nDAVID: Oh yeah. It's [crosstalk 16:42]. Yeah, you can actually manipulate it.\n\nMIKE: I'll often write methods where I put...and you almost never use semicolons in Ruby. You're like, you can't use semicolons in Ruby? Well, you can, but nobody does. But when I'm doing interactive coding with a console, I do that all the time. I'll have my method written with semicolons between it, so I just tap my up arrow, go back and modify it, run it, tap my up arrow, go back and modify it. It's just really easy.\n\nMATT: We use the semicolons a lot in the production environment. So, we don't get output when we're loading models.\n\nDAVID: Oh yeah. It's like load user semicolon nil. \n\nMATT: Yep. And I'm finding a little bit of a pattern here. I'm noticing that those of us who have, and, you know, I don't want to state age, but those of us who are a little bit older and been around for a long time use a lot of very similar tactics. And we have what one may refer to as old-school methods.\n\nDAVID: Yeah. I'm actually coming from a different side of the old school, right? Where for me, I almost never code at the console or an IRB. For me, it's the code, compile, test mentality. So, like, if I want to play with something, I'll open it in the editor. I'll tweak it, and then I'll rerun it, and then, you know, tweak it and rerun it. And then I'll, like, edit the test and then rerun the spec. And that's an instinct to me. \n\nModifying something in IRB is great. Like, if I'm trying to explore, like, I don't know how this thing works, I love going into IRB and doing this. But, like, if I'm actually trying to write the function, I want to be in my editor so that when it does work, I'm done, rather than having to pull it out and drop the code into an editor. Like, I want to be done. I don't want to have an extra step.\n\nMIKE: For me, I care about how long is it? If it fits in one line, I'll do it in IRB.\n\nDAVID: In IRB, sure.\n\nMIKE: I'll do it in IRB. If it doesn't comfortably fit there, then I will pull up a file and do it that way because I don't want to have to restructure everything and fight with that. So, for me, it largely [chuckles] comes down to just I want to do less typing, you know, lazy developer.\n\nTAD: So, Dave, is that debugging? Or is that just writing code, or is that both?\n\nDAVID: For me, both. With debugging, it will be a lot...I guess what I'd say is if debugging, I probably won't edit code. It's, like, I don't program at an IRB kind of thing. But I'll crack up an IRB to explore or a Rails console to explore and find out, like, where is this coming from? And who is doing this to me? That sort of thing. \n\nIt's very, very rare that I will grab object dot method, colon, method name dot source location. I'll do that at a console all day long. It's like, you know what? Ask Ruby to tell me where this source code is so that I can track it down. I think I've done that once or twice from inside code, but very, very rare.\n\nJUSTIN: One question I have for the group is, like, what is your strategy if you get handed a bug from production? \n\nMATT: That was a little bit of where I was about to go. \n\nJUSTIN: Oh, perfect. \n\nMATT: What I was going to say is we've talked a lot about a bug inside of our codebase. However, we operate in a large ecosystem of services. What happens when you get a report of a bug from your production environment that is hitting five or six different services? And then, how do we debug that, and what kind of things can we do and put in place to make that easier on us?\n\nDAVID: I have a first technique that I will go to, which is Newton's approximation, which is to split a thing in half and then subdivide it. And, man, I learned this soldering radios back in high school working, like, ham radio stuff. If you get a circuit, a long-convoluted circuit, and it doesn't work, and there's 1,000 components on it, you pick a point roughly in the middle, and you inspect. Like, you get in, and you basically say, \"The data at this point, is it messed up already, or is it still good?\" If it's still good, the 500 things upstream are probably okay. The bug is probably downstream at that point. I've just eliminated 500 candidates from the list. \n\nAnd if it's bad already, then I know it's upstream, right? Then you split again 250. You split again 125. You keep splitting, splitting. And if you've got 1,000 components in 10 splits, you can come down to the line of code or to the specific component that is causing that thing. And I learned that with a soldering iron, you know, trying to isolate, you know, is this is a bad capacitor or a bad transistor? And it translated so easily onto, like, systems programming. And I was like, well, yeah, it makes sense.\n\nJUSTIN: Did you understand the entire thing? Because sometimes, with a big, complicated system, it's hard to understand, like, all the parts to it, right?\n\nDAVID: Mm-hmm. Mm-hmm.\n\nMIKE: For me, I think a lot of the place I start is...and I don't know if I took this quite explicitly. I'm thinking about the conversation I [inaudible 21:18] earlier. What's the story here? You're probably not going to do very well; just kind of random cherry-picking. Well, might it be over here? Might it be over here? Instead, you say, \"Well, what was the process that led to this? Who was the user that caused this? What steps did they go through to get it?\" You know, and part of why steps to replicate are so critical to being able to diagnose problems. How did they replicate it, and what was the exact outcome?\n\nAnd you can start thinking through what's possible and filtering down with that story. Narrative structures really work well with our brains, I think. And having that structure gives you a place to start. So, if you don't have the story, you've got almost nothing, you know, you've got a whole bunch of letters and numbers, and that doesn't do you very much. But if you have a story, well, I can do something with that. \n\nDAVID: If you don't have a story, your brain has a working memory of about seven items. So, you know, a system with seven components, you can debug. You need a story if you want to go bigger than that.\n\nEDDY: I think the most challenging part [crosstalk 22:15] of debugging stuff is when you can't replicate stuff in lower environments, and you're just playing with, like, I'll just shoot up in the air, and hopefully this fixes it, right? Like, how do you go about debugging something like that that isn't reproducible in a controlled environment?\n\nTAD: Can you debug something that you can't reproduce, that you can't tell the story about?\n\nMIKE: Those are the hardest ones [laughs]. But I think the answer is still the same. It's about becoming a really good storyteller [chuckles], honestly. You think, well, I don't know what's going on here, and I can't reproduce it somewhere else. But I can think about what's going on in this environment. And then you start asking questions, well, how does that environment differ from my local environment?\n\nMATT: Yeah, there's a Latin term called ceteris paribus used all the time in economic principles, and what that means is all things being equal. So, one of the first things—and we have learned our lesson a few times with this—is we need to check our environments. Are they equal? Are they set up the same? Do we have the proper feature flags in place in one versus another environment? You know, we've been caught a few times with that. That's a really important thing to take into consideration. \n\nAnd a lot of times, we overthink a problem when we're trying to solve it instead of thinking in the simplest terms. And if you can think of the simplest things first, a high percentage of the time, that's the cause.\n\nTAD: Is this just science where I observe, I form a theory, I test my theory, I observe, I form a theory, I test my theory? \n\nDAVID: Yeah, the method of hypothesis makes sense. \n\nMIKE: I think it is. I was going to say something slightly different that there's been a number of times and probably a lot of times when I've had a bug that I couldn't understand, and I said, \"Well, this is impossible.\" And I think every time I've ever thought that I was right [chuckles]. Going back to what Matt said, I was absolutely right because my mental model of the situation had a critical flaw [chuckles]. And if it had happened the way I was thinking it was happening, it wasn't possible. \n\nSo, going to what Matt was saying [chuckles], stepping back to think, well, all this is equal; apparently, something is wrong. Something is different here that I am not thinking about. And I have to think about, well, if this is impossible, that means I'm the one who's wrong. I'm thinking about this problem wrong. And I have to start exploring options as to what might be possible, which means that my focus is too narrow. And it's usually kind of a meta thing. Like, maybe the environment is different [chuckles]. Well, what is different about my environment?\n\nTAD: I actually had a manager, and he'd say something like, \"Well, did you drop the apple?\" right? But that meant, did you test the gravity is working right now? Something that you assume is always true. Like, I'm going to drop this apple. It's always going to fall. Gravity is always working. And it's always attractive, da, da, da, right? Like, a fundamental assumption that I totally believe.\n\nAnd it's like, okay, I've established that assumption. Okay, maybe I need to back up and drop some apples and test all these assumptions that I'm making and see, oh, this assumption that I believed was always correct is 90% correct, right? Or there is something that I assumed to be absolutely the thing isn't actually the thing.\n\nDAVID: There's a thing that I'll do in RSpec called writing a cockroach test, and it's the opposite of a canary in the coal mine. A canary is any little breeze kills your spec, right? It's literally a flaky spec. A cockroach spec is if you've ever worked on any of the projects I've worked on, you will find me doing expect 42 to equal 42. I have seen that test fail, and when that test fails, it means gravity isn't working. \n\nOkay, to be fair, it wasn't that 42 wasn't equal to 42. It was that RSpec was broken. And we all thought it was working the way we thought it was, and it wasn't all. Like, the whole framework was broken. So yeah, dropping the apple, I'm going to steal that. I like that.\n\nMATT: There are also some things we can do to make our lives easier, especially in service-based architecture. One of the things we do here at Acima is we create a request ID for any request that gets passed along to all of our services. So, if we go look in our logs, we can search by that request ID and track it through each of our systems, you know. And I think being proactive is also something that we need to be really conscious of as well.\n\nJUSTIN: I like how you said proactive, and I'm a big believer in logging and logging all the paths you're on, and especially logging that enables monitoring. So, logging enables monitoring so you know when things go wrong. And, you know, logging your request IDs is good, but also, looking at the path that the user went through at each level is really helpful for understanding the history of that user or that request and seeing if it took the anticipated path. Of course, any errors are really useful with that as well. So, I think the request ID is attached to that error case, isn't it? When an error gets logged.\n\nMATT: It depends on where we're logging and what we're looking at. For instance, in, like, our Grafana logs, that request ID is attached to everything. \n\nJUSTIN: Perfect.\n\nMATT: Rollbar may or may not be. It depends on how the engineer logged it when they were catching errors.\n\nMIKE: And Rollbar catches exceptions [chuckles], so things that are unexpected. You may not have access to everything you wish you had.\n\nDAVID: Matt, when you say proactive, what do you mean?\n\nMATT: Exactly what it sounds like. Put things in place so if you do run into bugs, it makes them easier to track down. \n\nDAVID: Okay, okay.\n\nJUSTIN: Catching and logging those exceptions. \n\nMATT: Yeah, but --\n\nDAVID: Knowing we're definitely going to need this. Let's go ahead and do it now. \n\nMATT: Right. Right. The more preventative you can be, the fewer bugs you're going to run into. And let's be real with each other; bugs are inevitable at some point. I have never seen a piece of software that is bug-free, again, because we are humans, and we build software. But the easier we can make those bugs to crack down, the easier it is to fix and the fewer we're going to have.\n\nDAVID: There's an interesting epiphany you guys have given me as we talk through this, which is a thing that I got told years and years ago is that debugging doesn't stop when you run out of answers. Debugging stops when you run out of questions. And the epiphany that I'm getting from talking here in the call is that the best debugging skills is knowing which questions are going to eliminate the most false candidates from a thing. And I'm liking this. \n\nYeah, it's like, if I need to trace this down and I don't have the request ID, and if I have to go at every step and go, okay, when you pass this to this system, you got back that ID, okay, now we have to switch to that ID to trace through. Make it easier to track down the data you need. That totally makes sense.\n\nMATT: And a lot of it just comes with experience, you know, it's trial and error. You find what works for you. Everybody's workflow is going to be a little bit different. And we find what works for us, and then we just go with it. And we improve on it. And listen to your peers; other engineers are an amazing resource for this stuff.\n\nEDDY: I was actually going to say that one of my tools that's always my go-to is seeking help with people who are more experienced than me because they have a leg up. They've been through that before, you know, and they've had that ingrained in their head on, like, what their go-to is to debug something. So, not only is rubber debugging, for me, supercritical for debugging something, but, like, interacting with someone else in my team who is also involved and can help me get unstuck.\n\nMATT: And then after that, you're more experienced, right? \n\nMIKE: Experience helps. I liked the framing that Tad gave. It's just a science [laughs]. It is. In modern science, they don't use the word...they do talk about theories and that that is real, but a lot of times, they talk more about modeling. What we're doing is modeling the problem. You observe. You try to create a model that describes the behavior, and then you start testing your model. Does it actually work? I'm not saying that theory isn't a thing, but model is kind of a broader idea. It captures not just your idea of what's going on or your hypothesis, but it's provable. It's something that is...not provable but disprovable [laughs]. Disprovability is the key aspect. \n\nDoes this work in this scenario? Does this work in this scenario? And you start looking for holes in your model, right? And, hopefully, you find some because that means that there's new things to learn. And, likewise, when you've got a bug [laughs], you're like, well, what's the problem here? And then you already have some mental model, right? But maybe it is weak. And so, you try to come up with a better model, and then you test that model. Does this actually explain the behavior? And you try to disprove it, right? [laughs] And if you can't disprove it, then it's pretty reliably going to be your answer. \n\nAnd thinking about that methodically, in that way, about problem-solving, I think, is extremely valuable, and it can be a shortcut. Because otherwise, again, you just got a sea of text and a problem, and there's no relationship between the two. And modeling is that process of giving it structure in your mind and maybe even having something written down. You know, what's the structure here? So that you can understand it and start trying to test your model for reproducibility.\n\nEDDY: And staying calm.\n\nMIKE: The hardest problem I ever had to debug was working with a library that...it was a messaging library that was intended to run in a kind of a sidecar thread. So, you had your request come through, and it would fire off a new thread as soon as the request came through. And it actually tried to be persistent. It lived permanently between requests. So, this thread lived in the background, and it would spawn multiple other threads. So, it had multiple threads running concurrently to do messaging. And so, it ran in the background. And the publishing was asynchronous...it was concurrent like that. \n\nAnd it was also grabbing messages by pulling from the remote server with this concurrent set of threads. But it was also distributed because you're communicating between your system and another system. So, you had multiple systems, you know, there were multiple separate systems, generally, two, which is nice. It didn't have, like, eight, but you had two separate. So, you had a distributed system that was also concurrent at both ends.\n\nAnd I was asked to fix a problem with the messaging. There was something that wasn't working: figure out what's going on. And it turns out that the library I was using had multiple critical bugs in it. And the messaging was unreliable. We were dealing with messaging that was a little bit flaky. So, the messaging was unreliable. I had to deal with concurrency, something distributed. \n\nAnd [laughs] the code that I was expected to depend on that was supposed to be doing the work didn't always work. And I did get through it. But it took me about a month to do something that I thought would take me a day or two. And every day, I was just so defeated [laughs]. Like, at first, I'd, like, you know, after a couple of days, I saw, like, okay, this is a hard problem, but I can get through this. \n\nBut to your point, Eddy, about staying calm, I've believed this for a long time: that software development is about frustration management as much as anything else [laughs]. Just keeping on looking for flaws in my modeling of this problem. Just saying, you know what? I'm just going to keep on working on it and not get broken by it. It eventually got through, you know, that was a trial. You know, that's kind of an extreme example. It will probably lead to other discussions, too, where people say, \"Oh, this is the other one I fixed.\" But it illustrates some of those things. \n\nSometimes, you're working with some hard things that don't line up, so your log messages could come in random order. You can't trust the code that you're calling. You have to jump from system to system. The transfer layer is unreliable. And there are so many things that can go wrong, and that that randomness in the system is one of the hardest things. Anything that has randomness in it is really hard to debug, but continuing to just work at it and not give up [laughs]. \n\nAnd you think, well, I wouldn't actually give up. My job is to keep working on it. But it is; it's easy to, at least some part of you, to just kind of tune out. You're like, well, there's nothing I can do. And just taking a moment to calm down [laughs], take a step back, maybe go for a walk, and think, well, how do I tackle this problem next? Matters a huge deal.\n\nJUSTIN: So, I'm curious, Mike. What was your solution there? Is this something that you could summarize very quickly? \n\nMIKE: Yeah. So, that's a great question. So, what I ended up doing was focusing on smaller parts of the problem. I knew that there were problems in messaging between two systems. And that's just so ambiguous, you know, sometimes the messages weren't getting through. And the systems were running slowly, too. And the unit tests I was using weren't really unit tests. They were all integration tests, too. They were actually calling the live message [inaudible 34:50] [laughs]. So, I was handed that kind of testing. \n\nSo, there's a couple of things I did that were really critical. One of the things I did was essentially throw out the unit tests that I had been trying to get working because integration tests run incredibly slowly, and that was costing me a ton of time and not giving me what I wanted. I needed to get information and instead, they weren't really giving information. \n\nSo, I started with a smaller...I mocked out the actual messaging so I could focus on just what I was looking at. And by mocking that out, I restricted the scope of the problem I was looking at. That helped a lot. And then, I could look at just one particular request. What's going wrong with this particular request? And then look even smaller, like, well, sometimes this works, sometimes it doesn't. Why would that be? Which eventually led me to look into the library and think, well, again, this is impossible if the library is working.\n\nSo [laughs], I go into the library and put in some logging there and find the line like, oh, wait, this is spawning up a new thread. I don't remember the exact details of it. But, I found the problem in the library was using an array rather than a set. So, things weren't actually unique when we thought they were, something like that. And I find the library, and that freed me up a little bit, right? [laughs] And then I looked for...well, is it working now? No, it's not. There are still some other aspects of the problem. \n\nSo, then I focus down on the smallest component I possibly can. The bigger the problem you're trying to solve, the bigger the scope, the more you have to deal with. And getting out as much stuff as you possibly can so you can narrow down a tiny, little slice of the problem helps a great deal. And then find something wrong in the app in the way it's calling the library. I remember fixing some of that. \n\nIt actually ended up firing off more than one thread when it should only have been firing off one. Fixing that solved a problem because then things started running faster because you only had one thread running multiple. And it still wasn't working, again, just working on piece by piece. Focusing down on the smallest possible piece you can work on was incredibly helpful.\n\nDAVID: You said focusing down, and you mentioned at the start that you had, like, a many to many, like, many distributed in, many distributing out on it. And coming from the debugger side where I want to jump onto a console and I want to interrupt the code flow, you can't do that if there's 20 nodes. And you don't know which node is going to... logging would be a good solution, right? We just put logging on all of the nodes. Is that --\n\nMIKE: It is. Logging actually works. \n\nDAVID: Yes.\n\nMIKE: So, this is something a debugger doesn't [laughs], and logging does. \n\nDAVID: Yes.\n\nMIKE: And you think, well, I need a more sophisticated tool, and the answer is no. The last thing you need is a more sophisticated tool. You need the simplest tool possible. It was really counterintuitive. You think, for a tricky problem, you need a more sophisticated tool. And, no, for this problem, I needed the most basic kind of tool possible because it would work [chuckles] in this kind of environment. That's a really good observation. \n\nJUSTIN: And the log entry would contain all the information you need, like the thread ID.\n\nMIKE: Right. \n\nJUSTIN: The time entry and things like that. \n\nMIKE: Yeah. And knowing which thread it is in matters a great deal, right? [laughs] And being able to say that and then logging the threads, like, ooh, I see. This actually happened in this thread. I thought it was going to happen in this one, or these are out of order. That means that some of my locking and the semaphore stuff was going wrong. And bringing those kinds of things out, yeah, is a huge deal. \n\nEDDY: You know, I kind of want to propose a scenario if we're okay. Let's suppose that you do merge something in production, and it's a bug that wasn't caught. Our natural instinct would be, oh, shoot, roll back [laughs]. Let's roll back. Let's go. Let's get rid of the bug. Let's make sure that we step back and, you know, we can work on this. \n\nBut what if it's already further along? You know, you've gone a couple of weeks, and it wasn't caught. And suddenly, rolling back after it's been so long, you know, just isn't really feasible, right? But suddenly, this bug has turned into something huge. Let's say, for example, you're, like, leaking PII or something. And you're like, shoot, I need to get this out quick, right? In that sense, are we okay with bypassing unit testing and throwing out a potential fix to fix it? Is that good practice? Or should we still be concerned about writing passing specs? \n\nRAMSES: How would you know it's working if you don't have tests?\n\nMATT: I would say without your tests, you open up a really big door to introduce more bugs and different bugs.\n\nMIKE: There's a phrase that people use, and it's derogatory, cowboy coding, to try to describe that kind of thing. Oh, I'm just going to throw something out there and see what happens. It's a figure of speech, and there's a metaphor there. I don't know if this idea of the cowboy in the way that it's described ever truly existed in history [laughs]. But it's this image from movies about somebody who does things their own way. They don't really care about the consequences. They shoot with their guns, and they don't really care what happens. \n\nWell, if they're going out and shooting with their guns, some people are going to get killed [laughs]. There's a lot of chaos and sometimes tragedy that happens for others and for your environment. And the best usage of that phrase it speaks against that kind of action, that if you have this lone [inaudible 39:56] that thinks they can control everything, that they can get away with anything. \n\nAnd maybe in some scenarios, you're just building out something that doesn't have any real-world consequences. You haven't deployed yet. Then, that kind of development might be okay. But when there's consequences, people are going to get hurt. In your scenario, it's already been out for two weeks. Waiting an extra 30 minutes, waiting an extra hour to verify your solution, you know, you think about the cost-benefit analysis, it's probably going to save you some in the long run.\n\nDAVID: If you're hemorrhaging money and the [inaudible 40:26] actively damage by leaving the server, you know, running in that mode, another good option is to take the server down, right? You're just, like, stop production. We're going to stop the company from making money, but that's okay because we're also stopping the company from hemorrhaging money, you know, that kind of thing. \n\nI think pushing an emergency hotfix into production without a second pair of eyes on it I think that's a very, very bad option. I can imagine a world in which, at one shining, dark moment in time, that was your best option. Sometimes, you know, the, like, cowboy coders that mentality, of, you know, running around firing your guns everywhere, it's like, sometimes, the environments need clearing out. But that's you're in a bad situation, to begin with, when that's your best option. \n\nBut to answer the question behind your question, possibly, Eddy, like, what do we do in this situation? I would not sit down and spend 10 hours writing a test suite to verify all the new edge cases that we think, you know, it's like, oh, you know what? This is a problem. This needs to go out. We're not hemorrhaging money, but we're not making money. We're losing, you know, conversion. We're losing sales. Let's get this turned out.\n\nAnd there are things that you can do very quickly and low cost that give you a huge mitigation on the pushing a new bug, like, grabbing a co-worker and saying, \"Look at this,\" right? Like, a unit testing is just automating pair review; that's all it is. So, having another human, especially, like, a senior developer who has a very complex mental model of how the system works. You say, \"Does this make sense?\" And they'll take one look at it and go, \"Oh no, don't do that,\" right? \n\nMIKE: [laughs]\n\nDAVID: You say, \"Okay, good. I'm glad I didn't push this fix,\" right? Now, we're solving your solution down the road. Or they look at it and go, \"Yeah,\" right? And the next thing you can do to mitigate this risk is, after you push it out, stick around and watch the server, right? Try it out, you know, confirm. Eventually, like, by this time next Thursday, there should be tests for exactly the problem that you have found and that prove that we have solved it, and whether or not we need to get, you know, cash flow protected in the moment. That's a valid question. But it's definitely a different operating mode than a stable, steady, patient maximum risk mitigation development. \n\nThis has been a fantastic call. I could go for another hour. This was awesome. Any other thoughts on debugging and, like, how and why? Just don't write bugs?\n\nTAD: I thought Mike said something interesting about go for a walk. It's an interesting debugging aspect. \n\nDAVID: Reset the scope in your brain. \n\nMATT: Yeah, get away from your tunnel vision because -- \n\nEDDY: Getting a good night's sleep [laughs] [crosstalk 42:53]\n\nMIKE: That's so true.\n\nDAVID: There's a paper trail in an email somewhere that I sent years...I don't have it anymore. But literally, I have written the sentence, \"The most effective thing I can do to solve this problem is to unplug and get my head down for six hours.\" And that's what I did. And I got up in the morning, and I had the solution and was able to get it, but I never would have come up with it. \n\nSpecifically, going for a walk, Brain Rules by John Medina is a fantastic book. And he talks about if you get your quads moving, the biggest muscle in the body gets oxygen moving; this gives, like, a 30% boost to the Broca's area of the brain, the part where you executive function, which is your ability to reason through difficult problems and make decisions. So, going for a walk actually makes you smarter. So, if you need to be smarter for a problem, there's the door.\n\nMATT: Yeah, many of you have probably heard me say, \"I have not gotten much sleep. I am not going to try and solve this right now,\" because that's how mistakes are made, and we introduce more problems. So, it really is; rest is important. \n\nDAVID: We could do a whole separate show about recognizing the mental unit tests that we run on ourselves, right? Because a microscope can't look at itself. And the first judgment that gets impaired when your judgment gets impaired is your ability to determine if your judgment is impaired. So, finding those things like knowing I'm running on no sleep. I made this call last night, and I knew, and now I have to recognize that I feel fine. I feel tired, but I feel like I'm here. But you know from experience if I keep typing, pain and suffering will come of this. That's a really dark place to end. Somebody say something brighter. \n\nMIKE: I can go darker if you want. \n\nDAVID: Okay, fine. That works. As long as I'm not the one ending us on a dark call, somebody else could do it.\n\nMATT: Light outs for a nap.\n\nDAVID: That's right.\n\nMIKE: My father-in-law had diabetes. And he was in a serious accident because he was not thinking clearly, and they sent him home from work. And so, he rode home on his motorcycle. Our ability to understand the consequences of our choices is impaired when we're impaired in some way when our thinking is impaired. And having some sort of checklist almost to say, well, should I be doing this that is external to yourself, I think, is really valuable. \n\nDAVID: That is fantastic. We get into a go mindset, right? We gotta go, gotta go, gotta go. We stop checking to see, wait, is it safe? Is the smartest thing to stop? The best way to go might be to stop.\n\nMATT: Avoiding burnout is important and possibly a topic for another Acima podcast.\n\nDAVID: That is a fantastic idea, yes. \n\nMIKE: It's a fantastic idea.\n\nDAVID: 100%. All righty, folks, this has been a fun, fun chat. Thank you all for coming. And thanks for the contributions. I really appreciate it.","content_html":"The panelists discuss the nature of debugging in software development. What even is a bug? Various perspectives are shared, highlighting that bugs often result from unexpected behavior in software despite the software doing exactly what it was programmed to do. Sometimes bugs, sometimes seen as errors, can become features or lead to new insights.
\n\nThe discussion shifts to more philosophical and methodological aspects of debugging. It's pointed out that encountering bugs in software implies a need for more understanding of the program or the problem it solves. This realization opens avenues for deeper exploration and learning rather than fixing a fault. The role of testing in avoiding bugs is emphasized, particularly the importance of understanding and aligning with user expectations. The group also touches on the evolution of debugging techniques over time, moving from simple console printouts to more sophisticated methods but still acknowledging the effectiveness of basic approaches in specific scenarios.
\n\nAdditionally, they talk about the complexities of debugging in a modern, service-based architecture, where bugs might involve multiple services and systems. Strategies like dividing the problem space, creating narratives or models to understand the issue, and ensuring environmental consistency are discussed, and the conversation ends with a focus on the human aspect of debugging, including the necessity of taking breaks, the value of teamwork and peer review, and recognizing one's own cognitive limitations during the debugging process.
\n\nTranscript:
\n\nDAVID: Hello, and welcome to the Acima developer podcast. I'm David Brady, and we are going to talk about debugging today. And we put out the call that we're going to talk about debugging, and we got quite a quorum. So, it's exciting. We've got just a whole pile of people on. When you jump in the call, just tell us who you are, and we'll just go from there. Debugging, why?
\n\nTAD: Well, should we even get more simple than that?
\n\nDAVID: Sure.
\n\nTAD: What exactly is a bug? What would you call --
\n\nDAVID: Okay, yeah.
\n\nTAD: Is it bad values? Is it bad process? Is it bad behavior? Like --
\n\nEDDY: I would like to premise that bugs, historically, have led to some really good features.
\n\nDAVID: Minor trivia bit: the very first bug was an actual bug. Google that if you want. Grace Hopper fished an actual moth out of one of the relays, one of the very first computers. And there's a picture of it online. She taped it in her journal and saved it for posterity.
\n\nMIKE: Well, that says something about what a bug is, though. She went and pulled that out of the relay because there was unexpected behavior.
\n\nDAVID: Yes.
\n\nMIKE: [laughs] And the software does exactly what we tell it to do. The problem is sometimes that doesn't match our expectations. And that can be a minor inconvenience, or a neutral, even a positive thing, or it can be catastrophic [laughs]. I worked at a plant nursery many years ago. And my boss asked me, "What's a weed?" And I tried to give some explanation. And he says, "A weed is any plant that's growing where you don't want it." Bugs is kind of the same thing. I think it's unexpected behavior.
\n\nDAVID: One of the best things that somebody told me really early on in my career is kind of an intellectual ego check. He said, "Whenever you have a defect in your software or a bug in your software, it means you don't understand your program." And I'm like, "But yes, I do," oh, no, I don't. Provably, I do not because I think it will do this, and the computer is doing something else.
\n\nAnd that kind of opens you up to the wonder and puts you in a positive frame of mind of like, well, I need to figure out why this is doing this, rather than, like, I'm dumb, or the computer is dumb. Just like, okay, I wanted this, but I got that. Let's figure out why.
\n\nMATT: And that could also mean that you don't understand the problem that you're trying to solve.
\n\nDAVID: Or the solution, right? You don't understand the solution you're trying to do.
\n\nTAD: I thought it was really interesting...last week, David and I wrote some code together, and we put it in production. And they had us pull it back out. And some of the people in management are like, "Well, you should have tested it better." And the thing is, we had written a bunch of tests for it, and the behavior was exactly what we thought the behavior should be.
\n\nBut when we put that in production, the people who were using it were like, "Wait, this isn't what I wanted. This wasn't what I expected." This wasn't [laughs]...like, the tests proved that the behavior was exactly what we thought it should be. But it was unintended, unexpected behavior by the end user. And so, technically, is that a bug? I guess if it's unintended behavior, and it's from somebody's perspective that's using it.
\n\nMATT: And maybe we can talk about how do we prevent these bugs, right? I think it starts with a clear understanding of requirements, a clear definition of requirements, and testing, too, those requirements. Because a lot of times in software, the business side will have a lot different expectation than we do on the engineering side of what should happen, right? And I think if you can clearly define those things, then we run into fewer, what we call, bugs.
\n\nDAVID: That's an interesting definition. One of the early things that we talked about when unit testing was getting popular in the early days of XP, so, like, we're talking, like, Y2K, like, 20 years ago, they mentioned that one of the great things about a unit test is that it restates the problem or, you know, it kind of describes the behavior at a higher level.
\n\nAnd it gives you this ability to go to, like, the end user and say, "Is this not what you wanted it to do? Because if this is what you wanted it to do, I've got green dots. I can prove that it does this. But this is that, right?" It's like, "No, that's not what I wanted it to do. I wanted this other thing."
\n\nMATT: Yeah. You know, many, many, many moons ago, before all of these testing frameworks existed, we were writing code based on our expectations, right? The early days, old PHP days, Perl days, those are the languages I was in primarily, you know, 20-plus years ago. We were creating our expected behavior, and it was really hard to meet the needs of the requester because there was no clear test case to prove that you're meeting those needs. So, you run into a lot of unintended consequences and a lot of downstream problems.
\n\nJUSTIN: One of the things I've seen as well in my career was, initially, I was programming to meet the requirements. And then, I was programming to meet the requirements, assuming that the customer is an idiot. And now I'm programming to assume that the customer is malevolent. So, it goes along to, you know, really define what your requirements are and what your limits are.
\n\nDAVID: You've moved from programming Murphy's computer to programming Satan's computer, right?
\n\nJUSTIN: [laughs]
\n\nDAVID: The actual quote from a security talk I went to a while ago which is that Murphy's computer, anything that can go wrong, will go wrong. Satan's computer, everything that can go wrong will go wrong, at the same time, at the worst possible moment because that's what an attacker will engineer, right?
\n\nMATT: That being said, what happens when we introduce a bug? How do we track them down? What tools are we using to find them? And what is everyone doing? Because I imagine everyone in this room and on this call uses some different techniques.
\n\nMIKE: Can I say something here on this one? In some groups, I'm an outlier; in some groups, I'm not. Early in my software development career, I learned to be kind of shy of debuggers because they sometimes got in my way [laughs]. You know, they're great when they work, and other times, they're slow, and they break. And then, you could spend a lot of time wrestling with the tool rather than solving the problem.
\n\nSo, almost all of my career, I may print out a line to the console debugger more than anything else. I'll go in my code, have it print something out. It works in every language. You can have a consistent process that you just know what to expect. You can get good at it. You can get it to print something out. You run the code. You exercise it. You know that you're exercising that code because you get something printed out. You get good at filtering through logs. It's a really straightforward process that anybody can do.
\n\nI don't want to say that debuggers can't be useful, and sometimes they can be really useful. I might have used, like, a C debugger to debug Ruby to try to get down to some really gnarly stuff before, but I do that very, very rarely. And I find that just printing out stuff to the console is extremely effective. Because, for me, the most important thing I'm wanting to do when I'm debugging is figure out what's going on somewhere. If the bug is something that's unexpected, then there's something in there that I don't understand.
\n\nAnd so, I want to document, you know, to have some documentation thrown out from the code saying, "This is what's going on here," so I can figure out where my expectations are not being met. And I think that we'll probably talk about more sophisticated tools than that. But I think that kind of helps set the stage for further conversation is that what we're really trying to do is figure out what's going on. And simple tools, honestly, I've been doing this for a long time, and they've served me very well.
\n\nMATT: Seeing your output, right? Because, generally, that's the bug is you're getting output that is unexpected. And just seeing the output as you step through your methods or your classes it's powerful. And that's generally how I track them down as well.
\n\nTAD: Some of the hardest bugs I've ever had have been bugs with, like, timing issues, where the IO of a put statement or a print statement throws off the timing. And so, putting print statements in fixes the problem, and taking the print statements out reintroduces the problem.
\n\nMATT: Nice.
\n\nDAVID: Nice, a wicked Heisenberg.
\n\nEDDY: What's a Heisenberg?
\n\nDAVID: Oh, sorry --
\n\nMIKE: Ooh, you're learning a beautiful, new word [laughs].
\n\nDAVID: Yes. So, it's a corruption of the Heisenberg Principle, which is that at the quantum level, you cannot observe a thing without changing it because the act of bouncing a photon off of an electron moves the electron, right? You can't observe something, so... And so, yeah, Heisenberg is a bug that when you look at it, it changes, or it goes away.
\n\nMy favorite demonstration of this is some code, and you're teaching somebody to step through it in the debugger. So, you write a loop. It's like ten times do, and then you seed the random number generator with time dot now. And then you say, print, you know, puts, you know, rand, and it puts rand 10, right? And so, you run it, and you step through it in the debugger, step, step, step, three, step, step, step, five, step, step, step nine, right?
\n\nAnd then you take out the debugger, and you run it, and you get 7777777. It's all sevens. And you're like, what? Time dot now returns time down to the second. If your entire program runs inside one second, you're seeding the random number [inaudible 09:24]. But if you're standing there going, 'next instruction' in the debugger, you're burning down the clock. And that changes the state of the time input.
\n\nEDDY: So, it's actually really interesting. Mike, you mentioned...you said that you, early in your career, you printed stuff out, right? Do you actively use that as part of your go-to resource in order to debug something, or has that –-
\n\nMIKE: It's almost my exclusive resource still, after decades. [crosstalk 09:50]
\n\nJUSTIN: So, when you print stuff out, at what logging level are you printing it out?
\n\nMIKE: Oh, good question. So, guys, nothing against using log levels, right? Using a logger saying...my default, it depends [laughs]. It depends. If I'm in a local environment, I'll probably use debug. That way, it's harmless if it actually went into production [laughs] because production doesn't have debug turned on. It's a nice little safety thing.
\n\nJUSTIN: I'd like to push back on that just a little bit because I have seen releases to production with the debug turned on because it didn't understand which environment it was in. And that resulted in passwords being [laughs] put out in the logs.
\n\nMIKE: Oooh.
\n\nDAVID: Oooh.
\n\nJUSTIN: So, that was a fun time. But I think that even if you are debugging or you're doing a debug log level, you shouldn't ever debug with PII data. And so, either mask that or log something else that will help you debug. That's my only advice there, so...
\n\nMATT: And for context, to our listeners who are not going to visually see this, that was Justin who was just speaking. And he is on the Acima security team. [laughter]
\n\nJUSTIN: Yes.
\n\nDAVID: You guys are actually implicitly talking about something that I think is really, really interesting. I will debug with puts statement. I won't even use logger.debug. I'll use puts.
\n\nMIKE: I do, too.
\n\nDAVID: It's sloppy. It works great from localhost. And we have a code quality checker that will say, "Don't use puts; use logger." I'm like, no. What I want is to delete this, right?
\n\nMIKE: Exactly.
\n\nDAVID: But I don't --
\n\nMIKE: That's actually what I usually do as well, too [laughs].
\n\nMATT: I do the same. I use Awesome Print because it formats for me and makes things look a little nicer.
\n\nDAVID: Oooh. Awesome Print is a tool I haven't looked at. That, I'll have to check that one out.
\n\nEDDY: Can you explain what Awesome Print is? When you're done, Dave.
\n\nDAVID: Yes. I was just going to say the converse is that if I'm running something on preflight, I don't have access to the IO console, or if I'm...well, in production. This week, I got access to preflight, so I can see things that go to the console there. But, like, in production, I don't have that. So, going to a logger is really good.
\n\nBut you know what also falls down in production? Is running the debugger because I can't stop the server, you know, remotely. I mean, I can. Right now, I can. Justin would stop me if I did, at least in production. But, like, that's a bad idea, right? Bringing down the entire website just so you can debug something in one thread, probably a bad idea. So, there's trade-offs here. It's fantastic. Eddy, you were asking about Awesome Print. Matt, tell us about Awesome Print.
\n\nMATT: It's a Ruby thing. It's a gem. It will just output to your console, but it formats for you. It'll color-code hashes, you know, just make things really readable and legible. I use it every single day, and that's my go-to usually. Second would probably be Pry. But I also still do some really old-school techniques, and that is just tail dash f my development log, and that way, I can see live output.
\n\nDAVID: There's a lovely thing...we got to see if we can track down Charity Majors see if she would come on. She loves talking on and on and on about observability. And she works at a company that does logging and metrics, and so she's all about that. But when you talk to somebody about this, you start realizing that's all debugging really is, right? Is we've got all these questions, like, what's going on, and how can I look into this? Where can I get some observability into my data, or pretty-printing, console debugging, and logging, right?
\n\nI will say, as a person who came from, like, the C world and debugging, I spent a ton of time down in, like, Ruby debug land. I love using, like, Byebug because I can watch a variable. I can do a thing where it's like, I don't know who's changing this, but I can stop the program when they do. And I can, you know, put a breakpoint on this. And then I can walk away and go do another thing. And then boom, it hits. It triggers. That's a little harder to deal with.
\n\nBut, I guess, with the puts, you could go in and say, you know, "Print when this happens." But if it's like a variable, like a change on a variable, you can track that. And that's very, very exciting to watch something, you know, live, but have the thing actually fire a trigger and say, "No, no, no, no, hang on. We want to talk about this." And that's, like, a great observability tool.
\n\nMATT: Yeah, and for things like Ruby, you can step through with debuggers, and a lot of the IDEs just provide them. And that's nice. I rarely use them because, generally, the things that I am looking for I know where to look. But that's really powerful if things are happening deeper in your stack, and you don't know what you're looking for.
\n\nDAVID: Yeah. The downside compared to Pry of, like, Byebug or Ruby debug is that your REPL, your little read-eval-print loop thing, is just kind of, like, a one-line thing. You can evaluate a statement in Byebug, and it will return you the value, but, like, modifying code on the fly is a little bit trickier.
\n\nI know that the folks that use Pry love this because it basically gives you an IRB prompt. You can rewrite a function and then rerun it. I am not super fluent in that. Is somebody here...does anybody on the call like to do it that way? If not, we can tell people to go Google it. But does anybody here debug that way, that's good at that way, that can talk to that?
\n\nMATT: I've done it a little bit. If I have an idea of a change, if I'm in the right console, occasionally, I'll make that change, and then see if the output is what I expect, and then go make the change in the code. I wouldn't say I do it often, but I certainly have done it.
\n\nEDDY: I think I use it religiously, honestly.
\n\nDAVID: You do?
\n\nEDDY: Yeah. Like, I'll inspect something, and I'm like, cool, is this outputting whatever I expect it to output? Or, you know, if I have a check in place, you know, like, if current user dot permission granted, or whatever, and like, I'm trying to make sure that it does have the right rules or whatever. Or if I'm checking for a bool output, I want to make sure that that [inaudible 15:43] class is doing what I expect it to do. It could be a typo, you know; it could be checking something that I wasn't expecting. So, being able to manipulate the data inside that session is pretty nice.
\n\nDAVID: Fantastic. Does anybody here use, like, the code rewriting ability by Pry? Because that gives an IRB prompt. You can literally just, like, open a class and jam in a method. There's a related technique that I also don't do, which is writing code at an IRB prompt or at a Rails console. Does anybody use that technique?
\n\nMATT: That's what I was referring to. Like, if I have a class method that is doing something unexpected and I have an idea for a change, I'll just put the entire method in and rewrite it inside of the console.
\n\nDAVID: Okay, yeah.
\n\nMIKE: I do a REPL all the time, you know, that's why I use simple, you know, print statement out to the, you know, standard out. And then when I want to test something, I'll pull up, you know, the interactive console and play with it. Software isn't quite tangible. That's about as close as you get to tangible [laughs].
\n\nDAVID: Oh yeah. It's [crosstalk 16:42]. Yeah, you can actually manipulate it.
\n\nMIKE: I'll often write methods where I put...and you almost never use semicolons in Ruby. You're like, you can't use semicolons in Ruby? Well, you can, but nobody does. But when I'm doing interactive coding with a console, I do that all the time. I'll have my method written with semicolons between it, so I just tap my up arrow, go back and modify it, run it, tap my up arrow, go back and modify it. It's just really easy.
\n\nMATT: We use the semicolons a lot in the production environment. So, we don't get output when we're loading models.
\n\nDAVID: Oh yeah. It's like load user semicolon nil.
\n\nMATT: Yep. And I'm finding a little bit of a pattern here. I'm noticing that those of us who have, and, you know, I don't want to state age, but those of us who are a little bit older and been around for a long time use a lot of very similar tactics. And we have what one may refer to as old-school methods.
\n\nDAVID: Yeah. I'm actually coming from a different side of the old school, right? Where for me, I almost never code at the console or an IRB. For me, it's the code, compile, test mentality. So, like, if I want to play with something, I'll open it in the editor. I'll tweak it, and then I'll rerun it, and then, you know, tweak it and rerun it. And then I'll, like, edit the test and then rerun the spec. And that's an instinct to me.
\n\nModifying something in IRB is great. Like, if I'm trying to explore, like, I don't know how this thing works, I love going into IRB and doing this. But, like, if I'm actually trying to write the function, I want to be in my editor so that when it does work, I'm done, rather than having to pull it out and drop the code into an editor. Like, I want to be done. I don't want to have an extra step.
\n\nMIKE: For me, I care about how long is it? If it fits in one line, I'll do it in IRB.
\n\nDAVID: In IRB, sure.
\n\nMIKE: I'll do it in IRB. If it doesn't comfortably fit there, then I will pull up a file and do it that way because I don't want to have to restructure everything and fight with that. So, for me, it largely [chuckles] comes down to just I want to do less typing, you know, lazy developer.
\n\nTAD: So, Dave, is that debugging? Or is that just writing code, or is that both?
\n\nDAVID: For me, both. With debugging, it will be a lot...I guess what I'd say is if debugging, I probably won't edit code. It's, like, I don't program at an IRB kind of thing. But I'll crack up an IRB to explore or a Rails console to explore and find out, like, where is this coming from? And who is doing this to me? That sort of thing.
\n\nIt's very, very rare that I will grab object dot method, colon, method name dot source location. I'll do that at a console all day long. It's like, you know what? Ask Ruby to tell me where this source code is so that I can track it down. I think I've done that once or twice from inside code, but very, very rare.
\n\nJUSTIN: One question I have for the group is, like, what is your strategy if you get handed a bug from production?
\n\nMATT: That was a little bit of where I was about to go.
\n\nJUSTIN: Oh, perfect.
\n\nMATT: What I was going to say is we've talked a lot about a bug inside of our codebase. However, we operate in a large ecosystem of services. What happens when you get a report of a bug from your production environment that is hitting five or six different services? And then, how do we debug that, and what kind of things can we do and put in place to make that easier on us?
\n\nDAVID: I have a first technique that I will go to, which is Newton's approximation, which is to split a thing in half and then subdivide it. And, man, I learned this soldering radios back in high school working, like, ham radio stuff. If you get a circuit, a long-convoluted circuit, and it doesn't work, and there's 1,000 components on it, you pick a point roughly in the middle, and you inspect. Like, you get in, and you basically say, "The data at this point, is it messed up already, or is it still good?" If it's still good, the 500 things upstream are probably okay. The bug is probably downstream at that point. I've just eliminated 500 candidates from the list.
\n\nAnd if it's bad already, then I know it's upstream, right? Then you split again 250. You split again 125. You keep splitting, splitting. And if you've got 1,000 components in 10 splits, you can come down to the line of code or to the specific component that is causing that thing. And I learned that with a soldering iron, you know, trying to isolate, you know, is this is a bad capacitor or a bad transistor? And it translated so easily onto, like, systems programming. And I was like, well, yeah, it makes sense.
\n\nJUSTIN: Did you understand the entire thing? Because sometimes, with a big, complicated system, it's hard to understand, like, all the parts to it, right?
\n\nDAVID: Mm-hmm. Mm-hmm.
\n\nMIKE: For me, I think a lot of the place I start is...and I don't know if I took this quite explicitly. I'm thinking about the conversation I [inaudible 21:18] earlier. What's the story here? You're probably not going to do very well; just kind of random cherry-picking. Well, might it be over here? Might it be over here? Instead, you say, "Well, what was the process that led to this? Who was the user that caused this? What steps did they go through to get it?" You know, and part of why steps to replicate are so critical to being able to diagnose problems. How did they replicate it, and what was the exact outcome?
\n\nAnd you can start thinking through what's possible and filtering down with that story. Narrative structures really work well with our brains, I think. And having that structure gives you a place to start. So, if you don't have the story, you've got almost nothing, you know, you've got a whole bunch of letters and numbers, and that doesn't do you very much. But if you have a story, well, I can do something with that.
\n\nDAVID: If you don't have a story, your brain has a working memory of about seven items. So, you know, a system with seven components, you can debug. You need a story if you want to go bigger than that.
\n\nEDDY: I think the most challenging part [crosstalk 22:15] of debugging stuff is when you can't replicate stuff in lower environments, and you're just playing with, like, I'll just shoot up in the air, and hopefully this fixes it, right? Like, how do you go about debugging something like that that isn't reproducible in a controlled environment?
\n\nTAD: Can you debug something that you can't reproduce, that you can't tell the story about?
\n\nMIKE: Those are the hardest ones [laughs]. But I think the answer is still the same. It's about becoming a really good storyteller [chuckles], honestly. You think, well, I don't know what's going on here, and I can't reproduce it somewhere else. But I can think about what's going on in this environment. And then you start asking questions, well, how does that environment differ from my local environment?
\n\nMATT: Yeah, there's a Latin term called ceteris paribus used all the time in economic principles, and what that means is all things being equal. So, one of the first things—and we have learned our lesson a few times with this—is we need to check our environments. Are they equal? Are they set up the same? Do we have the proper feature flags in place in one versus another environment? You know, we've been caught a few times with that. That's a really important thing to take into consideration.
\n\nAnd a lot of times, we overthink a problem when we're trying to solve it instead of thinking in the simplest terms. And if you can think of the simplest things first, a high percentage of the time, that's the cause.
\n\nTAD: Is this just science where I observe, I form a theory, I test my theory, I observe, I form a theory, I test my theory?
\n\nDAVID: Yeah, the method of hypothesis makes sense.
\n\nMIKE: I think it is. I was going to say something slightly different that there's been a number of times and probably a lot of times when I've had a bug that I couldn't understand, and I said, "Well, this is impossible." And I think every time I've ever thought that I was right [chuckles]. Going back to what Matt said, I was absolutely right because my mental model of the situation had a critical flaw [chuckles]. And if it had happened the way I was thinking it was happening, it wasn't possible.
\n\nSo, going to what Matt was saying [chuckles], stepping back to think, well, all this is equal; apparently, something is wrong. Something is different here that I am not thinking about. And I have to think about, well, if this is impossible, that means I'm the one who's wrong. I'm thinking about this problem wrong. And I have to start exploring options as to what might be possible, which means that my focus is too narrow. And it's usually kind of a meta thing. Like, maybe the environment is different [chuckles]. Well, what is different about my environment?
\n\nTAD: I actually had a manager, and he'd say something like, "Well, did you drop the apple?" right? But that meant, did you test the gravity is working right now? Something that you assume is always true. Like, I'm going to drop this apple. It's always going to fall. Gravity is always working. And it's always attractive, da, da, da, right? Like, a fundamental assumption that I totally believe.
\n\nAnd it's like, okay, I've established that assumption. Okay, maybe I need to back up and drop some apples and test all these assumptions that I'm making and see, oh, this assumption that I believed was always correct is 90% correct, right? Or there is something that I assumed to be absolutely the thing isn't actually the thing.
\n\nDAVID: There's a thing that I'll do in RSpec called writing a cockroach test, and it's the opposite of a canary in the coal mine. A canary is any little breeze kills your spec, right? It's literally a flaky spec. A cockroach spec is if you've ever worked on any of the projects I've worked on, you will find me doing expect 42 to equal 42. I have seen that test fail, and when that test fails, it means gravity isn't working.
\n\nOkay, to be fair, it wasn't that 42 wasn't equal to 42. It was that RSpec was broken. And we all thought it was working the way we thought it was, and it wasn't all. Like, the whole framework was broken. So yeah, dropping the apple, I'm going to steal that. I like that.
\n\nMATT: There are also some things we can do to make our lives easier, especially in service-based architecture. One of the things we do here at Acima is we create a request ID for any request that gets passed along to all of our services. So, if we go look in our logs, we can search by that request ID and track it through each of our systems, you know. And I think being proactive is also something that we need to be really conscious of as well.
\n\nJUSTIN: I like how you said proactive, and I'm a big believer in logging and logging all the paths you're on, and especially logging that enables monitoring. So, logging enables monitoring so you know when things go wrong. And, you know, logging your request IDs is good, but also, looking at the path that the user went through at each level is really helpful for understanding the history of that user or that request and seeing if it took the anticipated path. Of course, any errors are really useful with that as well. So, I think the request ID is attached to that error case, isn't it? When an error gets logged.
\n\nMATT: It depends on where we're logging and what we're looking at. For instance, in, like, our Grafana logs, that request ID is attached to everything.
\n\nJUSTIN: Perfect.
\n\nMATT: Rollbar may or may not be. It depends on how the engineer logged it when they were catching errors.
\n\nMIKE: And Rollbar catches exceptions [chuckles], so things that are unexpected. You may not have access to everything you wish you had.
\n\nDAVID: Matt, when you say proactive, what do you mean?
\n\nMATT: Exactly what it sounds like. Put things in place so if you do run into bugs, it makes them easier to track down.
\n\nDAVID: Okay, okay.
\n\nJUSTIN: Catching and logging those exceptions.
\n\nMATT: Yeah, but --
\n\nDAVID: Knowing we're definitely going to need this. Let's go ahead and do it now.
\n\nMATT: Right. Right. The more preventative you can be, the fewer bugs you're going to run into. And let's be real with each other; bugs are inevitable at some point. I have never seen a piece of software that is bug-free, again, because we are humans, and we build software. But the easier we can make those bugs to crack down, the easier it is to fix and the fewer we're going to have.
\n\nDAVID: There's an interesting epiphany you guys have given me as we talk through this, which is a thing that I got told years and years ago is that debugging doesn't stop when you run out of answers. Debugging stops when you run out of questions. And the epiphany that I'm getting from talking here in the call is that the best debugging skills is knowing which questions are going to eliminate the most false candidates from a thing. And I'm liking this.
\n\nYeah, it's like, if I need to trace this down and I don't have the request ID, and if I have to go at every step and go, okay, when you pass this to this system, you got back that ID, okay, now we have to switch to that ID to trace through. Make it easier to track down the data you need. That totally makes sense.
\n\nMATT: And a lot of it just comes with experience, you know, it's trial and error. You find what works for you. Everybody's workflow is going to be a little bit different. And we find what works for us, and then we just go with it. And we improve on it. And listen to your peers; other engineers are an amazing resource for this stuff.
\n\nEDDY: I was actually going to say that one of my tools that's always my go-to is seeking help with people who are more experienced than me because they have a leg up. They've been through that before, you know, and they've had that ingrained in their head on, like, what their go-to is to debug something. So, not only is rubber debugging, for me, supercritical for debugging something, but, like, interacting with someone else in my team who is also involved and can help me get unstuck.
\n\nMATT: And then after that, you're more experienced, right?
\n\nMIKE: Experience helps. I liked the framing that Tad gave. It's just a science [laughs]. It is. In modern science, they don't use the word...they do talk about theories and that that is real, but a lot of times, they talk more about modeling. What we're doing is modeling the problem. You observe. You try to create a model that describes the behavior, and then you start testing your model. Does it actually work? I'm not saying that theory isn't a thing, but model is kind of a broader idea. It captures not just your idea of what's going on or your hypothesis, but it's provable. It's something that is...not provable but disprovable [laughs]. Disprovability is the key aspect.
\n\nDoes this work in this scenario? Does this work in this scenario? And you start looking for holes in your model, right? And, hopefully, you find some because that means that there's new things to learn. And, likewise, when you've got a bug [laughs], you're like, well, what's the problem here? And then you already have some mental model, right? But maybe it is weak. And so, you try to come up with a better model, and then you test that model. Does this actually explain the behavior? And you try to disprove it, right? [laughs] And if you can't disprove it, then it's pretty reliably going to be your answer.
\n\nAnd thinking about that methodically, in that way, about problem-solving, I think, is extremely valuable, and it can be a shortcut. Because otherwise, again, you just got a sea of text and a problem, and there's no relationship between the two. And modeling is that process of giving it structure in your mind and maybe even having something written down. You know, what's the structure here? So that you can understand it and start trying to test your model for reproducibility.
\n\nEDDY: And staying calm.
\n\nMIKE: The hardest problem I ever had to debug was working with a library that...it was a messaging library that was intended to run in a kind of a sidecar thread. So, you had your request come through, and it would fire off a new thread as soon as the request came through. And it actually tried to be persistent. It lived permanently between requests. So, this thread lived in the background, and it would spawn multiple other threads. So, it had multiple threads running concurrently to do messaging. And so, it ran in the background. And the publishing was asynchronous...it was concurrent like that.
\n\nAnd it was also grabbing messages by pulling from the remote server with this concurrent set of threads. But it was also distributed because you're communicating between your system and another system. So, you had multiple systems, you know, there were multiple separate systems, generally, two, which is nice. It didn't have, like, eight, but you had two separate. So, you had a distributed system that was also concurrent at both ends.
\n\nAnd I was asked to fix a problem with the messaging. There was something that wasn't working: figure out what's going on. And it turns out that the library I was using had multiple critical bugs in it. And the messaging was unreliable. We were dealing with messaging that was a little bit flaky. So, the messaging was unreliable. I had to deal with concurrency, something distributed.
\n\nAnd [laughs] the code that I was expected to depend on that was supposed to be doing the work didn't always work. And I did get through it. But it took me about a month to do something that I thought would take me a day or two. And every day, I was just so defeated [laughs]. Like, at first, I'd, like, you know, after a couple of days, I saw, like, okay, this is a hard problem, but I can get through this.
\n\nBut to your point, Eddy, about staying calm, I've believed this for a long time: that software development is about frustration management as much as anything else [laughs]. Just keeping on looking for flaws in my modeling of this problem. Just saying, you know what? I'm just going to keep on working on it and not get broken by it. It eventually got through, you know, that was a trial. You know, that's kind of an extreme example. It will probably lead to other discussions, too, where people say, "Oh, this is the other one I fixed." But it illustrates some of those things.
\n\nSometimes, you're working with some hard things that don't line up, so your log messages could come in random order. You can't trust the code that you're calling. You have to jump from system to system. The transfer layer is unreliable. And there are so many things that can go wrong, and that that randomness in the system is one of the hardest things. Anything that has randomness in it is really hard to debug, but continuing to just work at it and not give up [laughs].
\n\nAnd you think, well, I wouldn't actually give up. My job is to keep working on it. But it is; it's easy to, at least some part of you, to just kind of tune out. You're like, well, there's nothing I can do. And just taking a moment to calm down [laughs], take a step back, maybe go for a walk, and think, well, how do I tackle this problem next? Matters a huge deal.
\n\nJUSTIN: So, I'm curious, Mike. What was your solution there? Is this something that you could summarize very quickly?
\n\nMIKE: Yeah. So, that's a great question. So, what I ended up doing was focusing on smaller parts of the problem. I knew that there were problems in messaging between two systems. And that's just so ambiguous, you know, sometimes the messages weren't getting through. And the systems were running slowly, too. And the unit tests I was using weren't really unit tests. They were all integration tests, too. They were actually calling the live message [inaudible 34:50] [laughs]. So, I was handed that kind of testing.
\n\nSo, there's a couple of things I did that were really critical. One of the things I did was essentially throw out the unit tests that I had been trying to get working because integration tests run incredibly slowly, and that was costing me a ton of time and not giving me what I wanted. I needed to get information and instead, they weren't really giving information.
\n\nSo, I started with a smaller...I mocked out the actual messaging so I could focus on just what I was looking at. And by mocking that out, I restricted the scope of the problem I was looking at. That helped a lot. And then, I could look at just one particular request. What's going wrong with this particular request? And then look even smaller, like, well, sometimes this works, sometimes it doesn't. Why would that be? Which eventually led me to look into the library and think, well, again, this is impossible if the library is working.
\n\nSo [laughs], I go into the library and put in some logging there and find the line like, oh, wait, this is spawning up a new thread. I don't remember the exact details of it. But, I found the problem in the library was using an array rather than a set. So, things weren't actually unique when we thought they were, something like that. And I find the library, and that freed me up a little bit, right? [laughs] And then I looked for...well, is it working now? No, it's not. There are still some other aspects of the problem.
\n\nSo, then I focus down on the smallest component I possibly can. The bigger the problem you're trying to solve, the bigger the scope, the more you have to deal with. And getting out as much stuff as you possibly can so you can narrow down a tiny, little slice of the problem helps a great deal. And then find something wrong in the app in the way it's calling the library. I remember fixing some of that.
\n\nIt actually ended up firing off more than one thread when it should only have been firing off one. Fixing that solved a problem because then things started running faster because you only had one thread running multiple. And it still wasn't working, again, just working on piece by piece. Focusing down on the smallest possible piece you can work on was incredibly helpful.
\n\nDAVID: You said focusing down, and you mentioned at the start that you had, like, a many to many, like, many distributed in, many distributing out on it. And coming from the debugger side where I want to jump onto a console and I want to interrupt the code flow, you can't do that if there's 20 nodes. And you don't know which node is going to... logging would be a good solution, right? We just put logging on all of the nodes. Is that --
\n\nMIKE: It is. Logging actually works.
\n\nDAVID: Yes.
\n\nMIKE: So, this is something a debugger doesn't [laughs], and logging does.
\n\nDAVID: Yes.
\n\nMIKE: And you think, well, I need a more sophisticated tool, and the answer is no. The last thing you need is a more sophisticated tool. You need the simplest tool possible. It was really counterintuitive. You think, for a tricky problem, you need a more sophisticated tool. And, no, for this problem, I needed the most basic kind of tool possible because it would work [chuckles] in this kind of environment. That's a really good observation.
\n\nJUSTIN: And the log entry would contain all the information you need, like the thread ID.
\n\nMIKE: Right.
\n\nJUSTIN: The time entry and things like that.
\n\nMIKE: Yeah. And knowing which thread it is in matters a great deal, right? [laughs] And being able to say that and then logging the threads, like, ooh, I see. This actually happened in this thread. I thought it was going to happen in this one, or these are out of order. That means that some of my locking and the semaphore stuff was going wrong. And bringing those kinds of things out, yeah, is a huge deal.
\n\nEDDY: You know, I kind of want to propose a scenario if we're okay. Let's suppose that you do merge something in production, and it's a bug that wasn't caught. Our natural instinct would be, oh, shoot, roll back [laughs]. Let's roll back. Let's go. Let's get rid of the bug. Let's make sure that we step back and, you know, we can work on this.
\n\nBut what if it's already further along? You know, you've gone a couple of weeks, and it wasn't caught. And suddenly, rolling back after it's been so long, you know, just isn't really feasible, right? But suddenly, this bug has turned into something huge. Let's say, for example, you're, like, leaking PII or something. And you're like, shoot, I need to get this out quick, right? In that sense, are we okay with bypassing unit testing and throwing out a potential fix to fix it? Is that good practice? Or should we still be concerned about writing passing specs?
\n\nRAMSES: How would you know it's working if you don't have tests?
\n\nMATT: I would say without your tests, you open up a really big door to introduce more bugs and different bugs.
\n\nMIKE: There's a phrase that people use, and it's derogatory, cowboy coding, to try to describe that kind of thing. Oh, I'm just going to throw something out there and see what happens. It's a figure of speech, and there's a metaphor there. I don't know if this idea of the cowboy in the way that it's described ever truly existed in history [laughs]. But it's this image from movies about somebody who does things their own way. They don't really care about the consequences. They shoot with their guns, and they don't really care what happens.
\n\nWell, if they're going out and shooting with their guns, some people are going to get killed [laughs]. There's a lot of chaos and sometimes tragedy that happens for others and for your environment. And the best usage of that phrase it speaks against that kind of action, that if you have this lone [inaudible 39:56] that thinks they can control everything, that they can get away with anything.
\n\nAnd maybe in some scenarios, you're just building out something that doesn't have any real-world consequences. You haven't deployed yet. Then, that kind of development might be okay. But when there's consequences, people are going to get hurt. In your scenario, it's already been out for two weeks. Waiting an extra 30 minutes, waiting an extra hour to verify your solution, you know, you think about the cost-benefit analysis, it's probably going to save you some in the long run.
\n\nDAVID: If you're hemorrhaging money and the [inaudible 40:26] actively damage by leaving the server, you know, running in that mode, another good option is to take the server down, right? You're just, like, stop production. We're going to stop the company from making money, but that's okay because we're also stopping the company from hemorrhaging money, you know, that kind of thing.
\n\nI think pushing an emergency hotfix into production without a second pair of eyes on it I think that's a very, very bad option. I can imagine a world in which, at one shining, dark moment in time, that was your best option. Sometimes, you know, the, like, cowboy coders that mentality, of, you know, running around firing your guns everywhere, it's like, sometimes, the environments need clearing out. But that's you're in a bad situation, to begin with, when that's your best option.
\n\nBut to answer the question behind your question, possibly, Eddy, like, what do we do in this situation? I would not sit down and spend 10 hours writing a test suite to verify all the new edge cases that we think, you know, it's like, oh, you know what? This is a problem. This needs to go out. We're not hemorrhaging money, but we're not making money. We're losing, you know, conversion. We're losing sales. Let's get this turned out.
\n\nAnd there are things that you can do very quickly and low cost that give you a huge mitigation on the pushing a new bug, like, grabbing a co-worker and saying, "Look at this," right? Like, a unit testing is just automating pair review; that's all it is. So, having another human, especially, like, a senior developer who has a very complex mental model of how the system works. You say, "Does this make sense?" And they'll take one look at it and go, "Oh no, don't do that," right?
\n\nMIKE: [laughs]
\n\nDAVID: You say, "Okay, good. I'm glad I didn't push this fix," right? Now, we're solving your solution down the road. Or they look at it and go, "Yeah," right? And the next thing you can do to mitigate this risk is, after you push it out, stick around and watch the server, right? Try it out, you know, confirm. Eventually, like, by this time next Thursday, there should be tests for exactly the problem that you have found and that prove that we have solved it, and whether or not we need to get, you know, cash flow protected in the moment. That's a valid question. But it's definitely a different operating mode than a stable, steady, patient maximum risk mitigation development.
\n\nThis has been a fantastic call. I could go for another hour. This was awesome. Any other thoughts on debugging and, like, how and why? Just don't write bugs?
\n\nTAD: I thought Mike said something interesting about go for a walk. It's an interesting debugging aspect.
\n\nDAVID: Reset the scope in your brain.
\n\nMATT: Yeah, get away from your tunnel vision because --
\n\nEDDY: Getting a good night's sleep [laughs] [crosstalk 42:53]
\n\nMIKE: That's so true.
\n\nDAVID: There's a paper trail in an email somewhere that I sent years...I don't have it anymore. But literally, I have written the sentence, "The most effective thing I can do to solve this problem is to unplug and get my head down for six hours." And that's what I did. And I got up in the morning, and I had the solution and was able to get it, but I never would have come up with it.
\n\nSpecifically, going for a walk, Brain Rules by John Medina is a fantastic book. And he talks about if you get your quads moving, the biggest muscle in the body gets oxygen moving; this gives, like, a 30% boost to the Broca's area of the brain, the part where you executive function, which is your ability to reason through difficult problems and make decisions. So, going for a walk actually makes you smarter. So, if you need to be smarter for a problem, there's the door.
\n\nMATT: Yeah, many of you have probably heard me say, "I have not gotten much sleep. I am not going to try and solve this right now," because that's how mistakes are made, and we introduce more problems. So, it really is; rest is important.
\n\nDAVID: We could do a whole separate show about recognizing the mental unit tests that we run on ourselves, right? Because a microscope can't look at itself. And the first judgment that gets impaired when your judgment gets impaired is your ability to determine if your judgment is impaired. So, finding those things like knowing I'm running on no sleep. I made this call last night, and I knew, and now I have to recognize that I feel fine. I feel tired, but I feel like I'm here. But you know from experience if I keep typing, pain and suffering will come of this. That's a really dark place to end. Somebody say something brighter.
\n\nMIKE: I can go darker if you want.
\n\nDAVID: Okay, fine. That works. As long as I'm not the one ending us on a dark call, somebody else could do it.
\n\nMATT: Light outs for a nap.
\n\nDAVID: That's right.
\n\nMIKE: My father-in-law had diabetes. And he was in a serious accident because he was not thinking clearly, and they sent him home from work. And so, he rode home on his motorcycle. Our ability to understand the consequences of our choices is impaired when we're impaired in some way when our thinking is impaired. And having some sort of checklist almost to say, well, should I be doing this that is external to yourself, I think, is really valuable.
\n\nDAVID: That is fantastic. We get into a go mindset, right? We gotta go, gotta go, gotta go. We stop checking to see, wait, is it safe? Is the smartest thing to stop? The best way to go might be to stop.
\n\nMATT: Avoiding burnout is important and possibly a topic for another Acima podcast.
\n\nDAVID: That is a fantastic idea, yes.
\n\nMIKE: It's a fantastic idea.
\n\nDAVID: 100%. All righty, folks, this has been a fun, fun chat. Thank you all for coming. And thanks for the contributions. I really appreciate it.
","summary":"","date_published":"2024-01-03T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/950baf66-c07d-4a81-90aa-e6e069a7df13.mp3","mime_type":"audio/mpeg","size_in_bytes":49370408,"duration_in_seconds":2742}]},{"id":"f2d2b8c4-78cc-4df1-95c6-9af58f2c5bc6","title":"Episode 35: Which IDE is Best For Developers?","url":"https://acima-development.fireside.fm/35","content_text":"This week, the panelists discuss the best Integrated Development Environment (IDE) for beginners. Eddy emphasized the importance of an IDE being ready to use post-installation, reducing the need for additional configurations or extensions. Steve advocated for a minimalist UI to help beginners, suggesting simpler interfaces are more approachable. The conversation covers various IDEs, with Visual Studio Code holding a significant market share. Notepad++ was humorously mentioned as a practical option for beginners. They also touch on the suitability of IDEs for different types of development, such as mobile or game development, highlighting the specialized needs like managing assets in game development.\n\nThey also delve into the trends in technology adoption, using TypeScript as an example. Tad mentioned the typical hype cycle where new technologies are quickly adopted and gradually lose appeal. This leads to a broader discussion about the evolution of programming languages and frameworks, like Ruby, influenced by user preferences and industry trends. They also discuss the importance of features like Live Share in Visual Studio Code, especially for collaborative programming and mentoring newer developers. \n\nTowards the end, the conversation shifts to personal experiences with different editors. Panelists share their first and second editors, reflecting on their transitions and experiences. This part of the discussion underscores the diversity of preferences in development tools shaped by individual comfort, project nature, and programming language. They conclude with a light-hearted debate on the merits and challenges of using various editors, encapsulating developers' varied perspectives and experiences in choosing their ideal programming tools.\n\nTranscript:\n\nTAD: Hello. Welcome to the Acima Dev podcast. I'm your host today, Tad. Joining me is Eddy. Will you introduce yourself?\n\nEDDY: Hi, guys. Been in here a couple of times. I'm a developer for Acima.\n\nTAD: And Ramses.\n\nRAMSES: Hi, everyone.\n\nTAD: And Steve.\n\nSTEVE: Yeah, I'm a developer here at Acima. Steve.\n\nTAD: And Kyle.\n\nKYLE: Yeah, DevOps engineer here at Acima.\n\nTAD: I like that we get a little bit of a mix because sometimes DevOps is a little bit different than regular development. So, they sometimes get some different tools that work well for them. Welcome, everybody. \n\nToday, the question is, which IDE is best for someone starting out with development? Maybe to start off with, let's establish some criteria. What do you think you would be looking for in an IDE or just, like, a code editor if you're starting out? What do you think are some good features?\n\nEDDY: I want to just premise by saying I think the closest the IDE can be ready to go by just natively being installed in your computer, the better. Because, like, you necessarily don't know what extensions or stuff you're going to need in order to progress and, you know, make your productivity better. So, like, the closest out-of-the-box configurations that you can get, you know, when you're installing, I think, is a huge win.\n\nTAD: Okay, so Notepad?\n\nEDDY: Yeah, definitely. I think Notepad's the best one. It's always installed.\n\nTAD: Yeah, I think that's a good point, though. If you don't have to go through a lot of setup and configuration, that definitely gives you a head start, right? \n\nSTEVE: For somebody who's brand new, a minimalist UI kind of helps with the learning curve. When you have something that's very feature-rich, and you're just dipping your toes in the water, sometimes something simpler is more approachable. So, I guess it depends on where they're at. Like, are we talking about somebody who's never seen code before, and this is the first thing they're doing? Or is it somebody who's dabbled but they're not a professional, they want to land a programming job, and they're just kind of doing their thing on their own? I just think it depends on where you're at.\n\nTAD: What if we assume that it's someone pretty new to programming overall? \n\nSTEVE: Yeah, in that situation, I would lean towards something like Sublime. I haven't used Notepad, so I don't know what that's like. But something really minimal but still feature-rich. That's my --\n\nEDDY: You know, we joke around about Notepad. And I actually used Note++ as my primary IDE for a while.\n\nTAD: Right. You know, I'm joking, too. But the first web page, like, HTML file I ever wrote, I think it was in Notepad. I mean, like, putting an HTML tag at the beginning, an HTML tag at the end, head tag, head tag, body tag, body tag. I think I wrote that in Notepad. \n\nSTEVE: I didn't even realize you guys were joking because Notepad++ is, like--\n\nEDDY: [laughs]\n\nSTEVE: It's not like TextEdit. Like, if you had said TextEdit, then I'd have been like, yeah, obviously a joke. But Notepad actually has formatting, or at least Notepad ++.\n\nEDDY: Well, I used --\n\nRAMSES: [inaudible 03:14] have syntax highlighting too? \n\nEDDY: It does. Yeah. \n\nRAMSES: Yeah, that's [inaudible 03:19]\n\nSTEVE: I think it's actually usable on, like, something like text editor.\n\nEDDY: Again, like, a few days ago, I was curious sort of because I knew this topic was coming, and I just looked worldwide top IDEs. And I don't think it's surprising to anyone when I say that 27%, almost 28% of the market share for IDEs is taken out by Visual Studio Code.\n\nSTEVE: What are the other market shares, and where are you getting that number?\n\nEDDY: So, this number is coming from Github.io.\n\nSTEVE: Microsoft.\n\nEDDY: Yeah. [laughs] Github.io, yeah, so it's Microsoft. So, there is some sort of bias there, right? But 27%, assuming that that's correct, is one-fourth of the market share, which is tremendous, right? To give you other context, right? Others coming close at 11% is Eclipse, and PyCharm, Android Studio, IntelliJ, NetBeans, Xcode, and Sublime, and Atom. So, those are the top 10. \n\nRAMSES: Atom is still in the top 10? \n\nEDDY: I was surprised.\n\nTAD: That's surprising to me, yeah.\n\nRAMSES: Yeah, that's interesting --\n\nTAD: And that GitHub kind of discontinued it and said, \"Feel free to continue to use it. But we're not going to be adding new features or fixing things.\"\n\nEDDY: I would advocate for Visual Studio Code in the sense that, like, I use it on a day-to-day basis, and I know my way around it pretty well. I know which extensions I like to use, cater it to my productivity, et cetera.\n\nTAD: You've had some experience now, right? And you didn't start with VS Code as your first editor, I imagine. So --\n\nEDDY: No. I used Notepad for a bit and then transitioned to Atom because it was, like, the hot thing. And then Visual Studio kind of just came in guns blazing [laughs].\n\nTAD: Yeah. I think it's kind of funny that we keep mentioning Notepad because, really, you've said minimalist UI. It's certainly got that. We talked about easy-to-use, easy-to-understand, something that comes native with your laptop. I might throw out there you don't have to learn magic key chords or special modes or anything. It's just, you know, CTRL + X CTRL + V to cut and paste. \n\nDo you think it's valuable if you have something that feels kind of like, I mean, Word or one of these other, like, document editors? Because you might have some of those keyboard shortcuts memorized, and you might have some familiarity with something like that. And if those transfer over to your first IDE, that might be useful.\n\nSTEVE: Yeah, I think it definitely makes a difference. One point I was going to bring up about Sublime, which is the one that I've used for most of my development career, which isn't terribly long, but I've used that and VS Code. And the thing that I loved about Sublime was the file explorer looks just like the native one on Mac, or it feels similar to it. And it's very easy to use. \n\nWhereas VS Code, it's really not usable, practically. I mean, you can't really see the indentations, and they throw these gigantic icons in front of all of the files as if they're catering to, like, a toddler. Like, this is a Ruby file, or this is a file or a directory. Here's a huge folder icon, you know. \n\nSo, I think stuff that looks like your native system, stuff that you're familiar with, just means less learning, which means that you can focus your attention on things that are kind of new concepts that are more important to you in the beginning. So, minimalism and familiarity are things that I would look for, you know, if learning something, but that's my [crosstalk 06:59]\n\nEDDY: So, let me ask you this: so, is Sublime scalable in a sense where, like, you can continue to use it as your knowledge increases and your tech stack goes up?\n\nSTEVE: Yeah, definitely you can. The thing is, you have to add extensions, of course, just like you do with any editor. And I'm not really sure why I switched. I didn't have any problem with Sublime. There was nothing that was really slowing me down. I think it was just, out of curiosity, I wanted to try something else. And then once you make the switch, then you're kind of like, all right, I'll just stay here.\n\nEDDY: [laughs]\n\nSTEVE: Like, it's not bad, you know. And in the case of VS Code, VS Code isn't bad. Actually, it's very good. I would rate them probably the same. But since I've switched to VS Code, I just stick with it for now. \n\nTAD: So, Eddy, are you suggesting that another criteria would be something that you can start with but also continue with, right? \n\nEDDY: Yeah, well, like --\n\nTAD: You know, integrating it with GitHub. \n\nEDDY: Yes. \n\nTAD: Or adding themes and extensions and things like that, that you want something that you can start with, but you can also continue to use even as you gain more advanced skills and get more experience.\n\nEDDY: Yeah, exactly. Well, I don't want to go on record to, like, sound like, I'm bashing Sublime in any way. I did try it for a few days. My biggest problem I had with it installing packages or extensions were a lot more difficult than they had to be. And, like, VS Code just gave you [laughs], like, a really nice intuitive UI that you can search and install, right? Like, that, for me, was a game changer. \n\nSTEVE: Yeah, I agree. I think that's a strong point for VS Code.\n\nTAD: Discoverability might be an important characteristic, right? Because Sublime code was great. I used it for probably a couple of years. But yeah, it's, like, installing things is just, do you know the right key combination to bring up the magic menu that lets you install something, right?\n\nKYLE: So, as you guys have been conversing about this, I was thinking about the question and how broad it is. And I'm having an issue kind of answering it myself just because there's a lot of unknowns in it, right? Like, okay, where do you start? Are you starting alone? Are you starting with a team? Because if you're starting with a team, they're going to have recommendations, and that's going to affect it. What kind of development are you doing? You know, what language? Where are you starting? \n\nAnd then, like, are you starting in development, or are you starting in systems? Like, where are you starting? Because that can change whether or not you're going to be using Sublime, Visual Studio, PyCharm, even Vim, or Emacs, you know. Like, maybe somebody's really familiar with the terminal, and it's just a lot easier for them to use Vim.\n\nTAD: Yeah, I mean, absolutely. Like, if you're doing Swift, you probably want to be using Xcode, right? I mean, certain languages have very opinionated tooling, I think. I think that's a great point, Kyle.\n\nKYLE: I mean, the other one is, are you on Windows, or are you on Mac? Because that's going to sway you one way or the other as well.\n\nEDDY: Are you actively...in DevOps, are you guys coding?\n\nKYLE: So, we have scripting languages that we utilize. So, that's going to be HCL for, like, Terraform and Bash, and we do Python, or we do Ruby. So, for us, in this question for us, we need more of a generalized IDE, something more like Sublime, Visual Studio, right? Something that's not specialized.\n\nTAD: Do you guys have some Go code? I think I saw some Go the other day. \n\nKYLE: Yeah, we do Go, too. Yep. \n\nTAD: Yeah. So --\n\nEDDY: And so, why do you guys use them, if you use any? \n\nKYLE: So, we have a couple of members on the team that really prefer to use Vim, and then the rest of us will use Visual Studio Code.\n\nTAD: This question is actually timely for me. There's another developer that invited me to volunteer with a local group called Tech-Moms. And they're women who are learning to code for the first time. They're just starting out, and, you know, they're moms. I don't know that's a requirement or anything, but they're pretty new to it. \n\nAnd I volunteered for a couple of hours this last Saturday. And most of my time was spent trying to get them to understand how to clone their GitHub stuff, how to find that cloned repo with Visual Studio Code, and then make the changes, and then push those changes up. And I was talking with some of the people afterwards, and one of the things they really struggled with is it's bring your own machine, right? So, some people bring a Chromebook; some people bring Windows, some people bring Macs.\n\nAnd I was actually wondering, since VS Code is basically built in a browser with all the Electron stuff, you can actually go to vscode.dev and run it in a webpage. And I was looking at that this past weekend. And I think that might be what I recommend to people right now because you don't need to find it on your machine. You know, something like that works even on a Chromebook, something like that. \n\nAnd you can get that developer experience just by going to a web page, which is pretty easy to do for most people. Most people know how to type in a URL and go to a page, and then hooking it up with a GitHub repo is also pretty easy. And you can just edit your code from there and just push it from that page. And you don't have to find anything. You don't have to install anything. You just go to a page and install maybe a theme or some extensions, and you're good to go. And I thought that was pretty compelling.\n\nKYLE: I'd second that. Just because about a year and a half ago now, I was actually helping somebody, you know, because I should be paying attention at church. But I was helping somebody with their code on their phone at church using the online Visual Studio editor. It makes it really easy.\n\nEDDY: Doesn't github.dev technically use Visual Studio on the surface?\n\nKYLE: Yeah, it does now, I think. \n\nEDDY: So, that's just another prime example of, like, the market share for Visual Studio [laughs].\n\nSTEVE: Yeah, I mean, honestly, Eddy, I don't doubt that it's 27%. That wouldn't surprise me at all. I mean, you just look around; everybody's using it at the office. Again, it depends on the language and what you're doing. But I wouldn't question that statistic. Sounds like all of us on this call, except Ramses, is currently using it, so...But being mostly Ruby developers, Ramses, you use RubyMine, right? \n\nRAMSES: Yeah, currently. I've used VS Code for a while. Most of my time I've spent using Vim, and I still use Vim. But I think it's the best tool for Ruby on Rails development. Also, it's just great. It's made for the language. I don't know, like, [crosstalk 14:03]\n\nTAD: Well, it's a true IDE. Like, it's a true integrated development environment, right? Whereas if I'm doing Ruby development, I might have to open the terminal, and that's kind of part of it, and drop in some terminal tools to, like, investigate some stuff. But I have to install a bunch of extensions, maybe have some command line tools and things like that before I get to the same level that RubyMine gives you out of the box. \n\nEDDY: You know, I'm trying to recall, way back when I did pairing sessions with my older brother, he had me use NetBeans for a bit. And that was super intuitive and really friendly with JavaScript at the time. I don't know if it's still the case, but I almost never hear anyone talking about NetBeans. And from what I recall, it was just a great experience.\n\nTAD: I think people still use NetBeans.\n\nSTEVE: I've never heard of that. Okay.\n\nKYLE: I haven't used that in a long time. \n\nEDDY: Yeah, it was great. Especially, like, I want to preface by saying, like, being a web developer, especially with Ruby, you're going to be writing a bunch of templating stuff, so, like, some sort of HTML template, you know, in Ruby, in even JavaScript. And I feel like of all the other IDEs that I've used; JavaScript just works really nicely with VS Code. Am I wrong in that statement? Like, do you guys disagree?\n\nTAD: I'd have to look at the stats. But I've done a few of these, like, JavaScript state of the language surveys and things like that. And I want to say it's maybe... I hope I'm not exaggerating, but I think it's, like, 90% of JavaScript developers use VS Code. And when I say JavaScript, I'm also going to lump TypeScript in with that, just because they've really done a great job of tooling it for JavaScript and TypeScript. \n\nKYLE: The only thing that I've even used that compares is WebStorm. \n\nTAD: Wow, I haven't used WebStorm in a while.\n\nEDDY: You know, and this is kind of a side topic, but you mentioned TypeScript, and you lumped it in. But all I'm hearing now is, like, big projects are ditching TypeScript, right? [laughs] There was, like, a big boom and suddenly...\n\nTAD: I think there's a hype cycle, right? Where it's the cool thing, it's the new thing, and a lot of people adopt it. And then some people realize, oh, I didn't really adopt it for the right reasons, or this promised me things, but in my particular case, the promises are unmet, right? Like, it's like, you're going to write better code and safer code, and it's going to be so much better. But sometimes people don't see that, right? \n\nAnd so, a lot of times with these technologies, I think you'll see a big early adopter rush. It cycles through the hype cycle, and then it kind of loses its shine. And so, people are, like, eh, I don't...whatever, and they kind of go find the next big thing. But still, a lot of people who are just happy with it and want to continue using it they're probably not going to write a blog post that says, \"Yeah, I'm still happy with this technology [laughs]. And I'm going to use it again tomorrow.\" \n\nI've seen a lot of that in the Rails community when the hype was really high, and now it's just a well-known framework. And it's not going to get your picture on the front cover of any magazines or anything. I think DHH was featured on a bunch back in the day, right? But people still use it. And it's just kind of typical boring technology now. And I'm not going to write a blog post that, yeah, I still like Ruby, right? It's usually the things that, like, we tried TypeScript, and we didn't like it after all, and we're switching. That's a more interesting blog post. \n\nEDDY: So, I have a genuine question, and I haven't actually looked much into it. But I feel like if you're going to be a web developer, the default is always Visual Studio Code. But what happens if you want to be a mobile developer or, like, some sort of scripting language? Is that still, like, work neatly with VS Code? Or does that sort of mentality shift a little bit depending on, like, the stack? Or even, like, [crosstalk 18:13] game development, right? So, like, Triple-A games that are being developed actively, like what IDEs do they use? Like, is it still VS Code, or is that just a given with web development?\n\nSERGIO: I just developed two video games in the past; one was released in Steam. And I used to work with C++ and also with C# on game development stuff. But when working on Unity, Unity has their own IDE, which is cool. It's good enough. But also, I've been working lastly with Visual Code. I think Visual Code is still missing some stuff like all IDEs has. \n\nBut lastly, I've been testing compiler with Visual Code, and it looks really nice. It's very useful when I work in unit tests in many stuff with JavaScript, with HTML, with Ruby, and even, I guess, with C#. So, I can say that's my answer. It's kind of it's really cool right now. But other IDEs like Unity built-in IDE is nice enough as well.\n\nEDDY: I didn't know Unity had its own built-in UI or, like, IDE. That's [laughs] really cool. \n\nTAD: I mean, I think it depends on the game framework because you might have something that helps you...and I haven't done a lot of game development myself, but from what I've seen, you have to manage a lot of assets and things like that. And if you've got Visual Studio, then you're just kind of left to whatever tools you want to, like, manage your assets, or edit your sprites, or do those sorts of things. But there are integrated development environments for game development that have all the tools that you need to build the game in one place. And you don't have to add additional outside tools to get that same experience.\n\nSERGIO: Yeah, yeah, that's the way it works right now. So, it's kind of integrated all the things you need. And essentially, when you're working with 3D and 2D assets, it's really complex. You know, you have a scenario where you have to import assets and also, you have to modify code at the same time, so you need something really custom. So, it's cool. \n\nI'm working a lot of time with C#, and I'm working with Visual Studio. At this point in time, I do prefer Visual Studio Code instead of Visual Studio. It's lightweight. And also, you can extend, you know, many things. Like I mentioned before, [inaudible 20:59]. I have plenty couple of things that worth testing. And also, one extension that I like so much is when we do pair programming. Do you remember that one, Eddy? I just learn many things from many people from -- \n\nEDDY: Live Share.\n\nSERGIO: Yeah, Live Share. Yeah, that one. Awesome. Yeah, you can do that with...I guess Visual Studio doesn't have that functionality, but instead, Visual Studio Code it does. I am not sure about this, but I'm almost sure that you have to pay the MSDS subscription. So, you have built-in functionalities that the normal Visual Studio doesn't have on this. You pay for it. So, that's cool.\n\nTAD: Yeah, I think, for me, Live Share is a killer feature, especially for pairing and especially when I'm pairing with somebody who's new to coding, where I can get them to send me their session string, and I can join their session. And I can explain to them what I'm doing as I'm doing it, as it appears on their screen. I can kind of stub out or kind of trace out some things and then have them fill it in. \n\nLike, yesterday, Damon and I were pairing, and we couldn't get the Live Share working. But something that I desperately wanted to do was I had kind of outlined all our tests, right? Like, the context, and the blocks, and things like that. And then to be able to hand it over to him and say, \"Okay, I've outlined this; now fill it in for me,\" I find that really compelling, especially the fact that it has built-in chat. I don't know that we use that much. We chat through other things. \n\nBut it tells you who's editing which file, and you can either follow them and see what they're doing, or you can go off and do your own thing. I mean, those kinds of features I often call it multiplayer programming. I think that's probably one of my favorite features of VS Code, especially when it comes to helping newer developers.\n\nEDDY: Yeah, that's awesome. That's super cool to know that you, like, outlined it for them in the live session [laughs]. That's so cool. It's also cool...when was it? Like, Sergio, myself, and Jonathan would pair in a ticket, and, like, one of us would, like, be writing the specs at the same time the other person's writing the code. It's also another way to be super productive because you get things done much quicker, which is another compelling thing with it.\n\nTAD: Yeah, I don't know if you guys were familiar with the old XP things. But there used to be, like, these hardware setups where you'd have, like, two separate keyboards that both fed into the same thing. And you could type, and you could do these things. And Live Share is basically living the dream where I don't have to hand off my laptop to someone else. \n\nI don't have to have some crazy setup where we have two keyboards plugged into the same computer that we're looking at. I mean, basically, when I do it, the thing I'm looking at is what they're looking at, and what I'm talking about is what they're looking at. And that's, like, the dream of the guys that really kind of pioneered the XP movement back in the, gosh, '90s.\n\nSERGIO: Hey, Tad, you did XP before. It's kind of the old-school way. Yeah --\n\nTAD: Yeah, kind of. To be honest, we did it in college. And I don't remember what distinguishes XP from some of the other things. But we did have times where it was basically two people sit down at the same computer and team up and pair and work on stuff.\n\nSERGIO: Yeah, I tried that in the university when we have this project. And we have a big monitor and everything else. People working is kind of [inaudible 25:04], I guess, and only one main programmer. It's kind of the other people is only seeing you. But that's weird, you know, it's kind of odd. \n\nI like to do stuff. So, this extension, Live Share, is kind of cool because everyone can write code at the same time. It's kind of you are not alone just seeing the code. You can interact directly with the code and write your own things. So yeah, many times, we broke things because watch people is doing one thing, and the other is trying other stuff [laughs]. But it's part of the coolness, you know [laughs].\n\nTAD: Right. Are there any other needs that maybe a newer developer would need that we haven't talked about yet?\n\nEDDY: I guess also, like, what operating system? Should they use Mac, Windows, or [laughs] Linux distro?\n\nTAD: Linux? Well, that's why I'm thinking about pushing the browser because then it doesn't matter. You know, start out with the editor in the browser and learn how you like things, and then graduate to something else.\n\nEDDY: Yeah. But will the browser sort of compile the code for you if you needed to? \n\nTAD: I don't think so. But I don't work with a lot of compiled languages nowadays, so I don't know. I tried going to vscode.dev, and I noticed that some of the extensions I like don't work in the browser, which makes sense, you know, so that's the thing. Like, it's probably a good place to start. But, ultimately, most people shouldn't stay there. So, for my own maybe curiosity, but of the people here in this call, what was the first editor that you used? And what was the second editor that you used for actual developing and writing code? \n\nSTEVE: My first one was Sublime, and I stuck with it for a long time, I think four years. And then VS Code. I think I've tried something else along the way. I don't remember what it was, but I wasn't impressed, obviously, if I don't even remember which one it was.\n\nKYLE: I started out with Visual Studio as my first one, and my second was actually Vi. \n\nEDDY: What's Vi?\n\nKYLE: Precursor to Vim.\n\nTAD: [inaudible 27:21] Vim. \n\nRAMSES: Just the original.\n\nEDDY: Okay [laughs]. I know now. I use it from time to time when I shell into an environment.\n\nTAD: Was Vi just because that's easier to use remotely on, like, servers and stuff?\n\nKYLE: Yeah, it was part of a networking class. And we had to do all of our development on a remote server in the professor's office, basically.\n\nEDDY: It's actually really funny how Sergio joined halfway through the call, and he mentioned Notepad, even though we were kidding initially. It just goes to show, you know, like, how embedded Notepad really is. \n\nTAD: Well, there's Notepad, and then there's, like, Notepad++, which is different, but it's still a very simple but very intuitive editor.\n\nSTEVE: I didn't even know you guys were joking [laughs]. I was under the impression Notepad++ was just, like, a normal editor. \n\nTAD: It is. Eddy, what did you start off with, and what did you...\n\nEDDY: I started off with [laughs] Notepad and then...but it wasn't Notepad++. It was the Microsoft Notepad, you know, all the do-do that is given to you pre-installed to write notes. Like, that's how I initially started writing, like, HTML. And then, like, I opened the file in my browser, you know, and the file--\n\nTAD: [inaudible 28:45]\n\nEDDY: Yeah, it was great. It was super cool. \n\nAnd then the next one, I believe, if I'm not mistaken, was Atom. Because, like, I joined forum groups and Reddit threads and, like, people talking about this whole new thing called Atom. So, I installed it, and it was, like, a full 180 for me because it was like, oh crap, going from black and white to, like, suddenly, like, my code is linted [laughs], you know. And so -- \n\nTAD: Syntax highlighting: so good.\n\nEDDY: Yeah [laughs]. You're like, oh, your brackets know, like, if you have, like, nested statements, or whatever, you know, like, suddenly, your open and close brackets are aligned by color and stuff like that, which made it much easier and more intuitive. And using Atom for me has a warm place in my heart. \n\nTAD: Ramses, what did you start with, and what did you pick after that? Or did you start with Vim and stayed forever with Vim?\n\nRAMSES: No, I started with Atom and then went to VS Code, actually, for a little while. All of my professional development experience has been in Vim until now, that I'm in RubyMine. Outside of that, yeah, Vim all the way.\n\nEDDY: Dude, you started out using Atom? That's awesome.\n\nRAMSES: Yeah, that was probably, like, three years ago when I started using it. It worked out pretty nicely. I actually don't know why I stopped using it, just did. I've always been curious about different editors, so I've tried a whole handful.\n\nTAD: Sergio, what did you start with, and what was your second editor? \n\nSERGIO: Notepad ++ recently. Probably Notepad, the normal one, like Eddy. I used to learn in Notepad ++. Later, I tried many, I guess, most of the [laughs] IDEs out there. But I used to work with Java, and Java has their own IDEs like Eclipse and NetBeans. And also, that one included in Android, which is JetBrains with supercharged Java stuff built-in, I don't know, some mixing of things. \n\nAnd lastly, I ended up with Visual Studio Code. It's kind of my favorite out there because lightweight. And I used to remember when I tried to open Eclipse on my computer, it was kind of, oh my God, it's draining all the resources in my [laughs] machine. So, oh gosh, that time was hard. And right now, I have a computer that is, yeah, better, and it's not draining all the resources. And that's cool. So, the only one that is draining resources is Unity because the nature of being greedy 2D and whatever else is kind of resource demanding. But everything else works fine in almost any computer out of there. But Eclipse is a nightmare [laughs] [inaudible 31:45].\n\nTAD: Yeah, with great power comes great resource usage, great hardware abuse [laughs]. Yeah, it's funny that for some people, VS Code feels light. For other people, VS Code feels very heavy because it's basically a mini browser just to edit text, right? And so, if you're probably somewhere at the Emacs or Vim end of the spectrum, VS Code feels like a ton of resources and very heavy. But if you've worked with some of these bigger IDEs, VS Code is probably refreshing. \n\nSERGIO: Yeah, yeah, I agree. I do have a question, maybe. Why I will use Vim? It is kind of new for me. I never worked in that before. It's kind of complex because you have to learn about when you have to use SS, or you have to edit, or something like that. I didn't know why I will use Vim. Can you answer that? Can you tell me someone that is actually using Vim why I will use this? Well, I understand it if you work on serverless stuff, you have to use it, and that's fine. But someone who is not using that for serverless, why I will use Vim? \n\nKYLE: Their approach to modal editing is just fantastic. I find myself to be a lot more productive. Once you learn the Vim motions of editing text, it just becomes much more fluid. But the problem with it is it requires a steep learning curve, so, you know, not great. But once you get a hang of it, you just want Vim everywhere. \n\nTAD: Yeah, I don't use Vim, but I know people who do and, basically, once they get really good, you're editing code at the speed of thought a lot of times, where your fingers are just moving automatically, and you're moving lines around. You're editing things across multiple lines. And, you know, the joke is you never have to pick your fingers up from the keyboard. You never have to touch that mouse. \n\nBut yeah, like, I tried Vim for about a month because I figured that I needed to give it at least that long. And I just don't think in that way. So, it didn't work for me, but people who think in a very Vim way they can be really productive, and it feels really elegant to them.\n\nSTEVE: I think you also mentioned one of the key things with Vim. And I'm not speaking from experience, but people that I've spoke to about it tend to not like using a mouse, so there's that. I think Vim is kind of is the go-to if that's you.\n\nSERGIO: Cool. Okay. \n\nEDDY: Yeah, some people are religious to not using a mouse, and I'm not calling anyone out, but I am looking at that person. Some people just refuse to use a mouse. And they really do try their best to never lift their hands off of the keyboard if they don't have to. And Vim does facilitate that [crosstalk 34:45].\n\nTAD: Well, it's unnecessary motion, right? If you can keep your hands practically on the home row and move everything around, suddenly, excess motion feels inelegant, right? It feels like unnecessary wasted behavior.\n\nEDDY: I feel like we can't end this topic without mentioning Emacs because Emacs is also a really strong competitor against Vim. And it's really solid out the gate. \n\nTAD: Yeah, it's interesting because we all have mentioned that we develop Ruby, and Ruby was actually shaped by Emacs, meaning Matz, who's the original creator of the Ruby programming language, uses Emacs in his day-to-day editing of everything. And the elegance of Lisp, and how Lisp kind of did things, and the interpretation of it, and things like that, really influenced what he wanted in the language and really added to Ruby's development. \n\nSo, one maybe final question for you guys: is there an editor that you've tried that you absolutely hated? Like, you're just like, \"Oh my gosh.\" You know, you tried it for, like, 10 minutes or something, and you just realized this absolutely is not the editor for me. And if you've had that experience, I'm curious: what was it about that particular editor that really you found so off-putting? \n\nSTEVE: Vi [laughs]. Because why would I use that? There's no reason for it. But every time I'm stuck having to use it just by chance, like, I don't enjoy it at all.\n\nTAD: Is it the modal nature of it? Is it the fact that there's nothing discoverable about it? Like, what's the --\n\nSTEVE: Well, it's just I don't know how to use it, so I have to look it up every single time. Depending on how my environment is set up, I might find myself in a Vi session and, I don't know, maybe during a rebase or something if I haven't set my editor yet. And that always annoys me [laughs].\n\nEDDY: I think there's benefit learning Vi, especially where we work, right? Because, you know, you shell into a certain cluster and then, suddenly, like, you need to modify some code. But you're like, ah, I don't want to, like, wait for my build to be ready again in order for me to make sure that this would have worked. And so, using Vi to go in there in your session and being able to change that on-demand is super cool. \n\nKYLE: I think I run into the same things as Steve, just with Nano. \n\nSERGIO: I have to say Eclipse a long time ago. But something I tried recently is Vim, and I didn't like it at all. But maybe I need to give it another chance to try to really understand why it was built that way, so maybe.\n\nTAD: Yeah. The angriest I think I've ever gotten is using VS Code. This is way back in the day. And I was taking a class on UI development, and the first half was Java. We created, like, these Java apps with Swing. And the second half was with Microsoft, and we had to use these things called Microsoft Foundation Classes. And they were so complicated that the editor tried to fix things for you behind the scenes. \n\nBut sometimes you really wanted to have a certain thing in a certain place. And I would say, I need to make this button blue, right? So, I'd go into the code, and I'd change the attribute to make my button blue. And Visual Studio didn't think that was the right place. And it would take it out and try to do other things for me behind the scenes. I would stare at things, and I'm like, oh my gosh, I don't know why this isn't working. I don't know what's going on. \n\nAnd it turned out that the editor was actually moving my code around without me knowing it. And I spent, like, hours sometimes trying to figure out what the heck was going on. If VS Code was a person, I'd punch it in the face [laughs], oh my God. It made me so angry to have an editor changing my code on me behind the scenes without my knowledge or permission. \n\nWell, it looks like [laughs], I guess, maybe we're ending on that note. Anything else we should mention before we wrap this up? \n\nRAMSES: What I gathered from it was that we should all use Vim.\n\nTAD: [laughs] That's an excellent takeaway.\n\nSTEVE: Yeah, that's it.\n\nTAD: If you have someone that comes to you and says, \"I want to get into programming. Where do I start?\" You point them at Vim [laughter] or --\n\nEDDY: And if they still stick around, they definitely want to be a developer, is what you're saying.\n\nTAD: Yeah. Or maybe you just point them at Notepad or vscode.dev or something like that and then see what they lean to. And then find a better tool for them later when they settle into something.\n\nSTEVE: Just ask them the question, \"Are you a masochist or not?\" \n\nTAD: [laughs]\n\nSTEVE: And then adjust accordingly.\n\nTAD: How's your self-esteem? Do you like yourself? [laughter] Cool, awesome. Well, thank you, everybody.","content_html":"This week, the panelists discuss the best Integrated Development Environment (IDE) for beginners. Eddy emphasized the importance of an IDE being ready to use post-installation, reducing the need for additional configurations or extensions. Steve advocated for a minimalist UI to help beginners, suggesting simpler interfaces are more approachable. The conversation covers various IDEs, with Visual Studio Code holding a significant market share. Notepad++ was humorously mentioned as a practical option for beginners. They also touch on the suitability of IDEs for different types of development, such as mobile or game development, highlighting the specialized needs like managing assets in game development.
\n\nThey also delve into the trends in technology adoption, using TypeScript as an example. Tad mentioned the typical hype cycle where new technologies are quickly adopted and gradually lose appeal. This leads to a broader discussion about the evolution of programming languages and frameworks, like Ruby, influenced by user preferences and industry trends. They also discuss the importance of features like Live Share in Visual Studio Code, especially for collaborative programming and mentoring newer developers.
\n\nTowards the end, the conversation shifts to personal experiences with different editors. Panelists share their first and second editors, reflecting on their transitions and experiences. This part of the discussion underscores the diversity of preferences in development tools shaped by individual comfort, project nature, and programming language. They conclude with a light-hearted debate on the merits and challenges of using various editors, encapsulating developers' varied perspectives and experiences in choosing their ideal programming tools.
\n\nTranscript:
\n\nTAD: Hello. Welcome to the Acima Dev podcast. I'm your host today, Tad. Joining me is Eddy. Will you introduce yourself?
\n\nEDDY: Hi, guys. Been in here a couple of times. I'm a developer for Acima.
\n\nTAD: And Ramses.
\n\nRAMSES: Hi, everyone.
\n\nTAD: And Steve.
\n\nSTEVE: Yeah, I'm a developer here at Acima. Steve.
\n\nTAD: And Kyle.
\n\nKYLE: Yeah, DevOps engineer here at Acima.
\n\nTAD: I like that we get a little bit of a mix because sometimes DevOps is a little bit different than regular development. So, they sometimes get some different tools that work well for them. Welcome, everybody.
\n\nToday, the question is, which IDE is best for someone starting out with development? Maybe to start off with, let's establish some criteria. What do you think you would be looking for in an IDE or just, like, a code editor if you're starting out? What do you think are some good features?
\n\nEDDY: I want to just premise by saying I think the closest the IDE can be ready to go by just natively being installed in your computer, the better. Because, like, you necessarily don't know what extensions or stuff you're going to need in order to progress and, you know, make your productivity better. So, like, the closest out-of-the-box configurations that you can get, you know, when you're installing, I think, is a huge win.
\n\nTAD: Okay, so Notepad?
\n\nEDDY: Yeah, definitely. I think Notepad's the best one. It's always installed.
\n\nTAD: Yeah, I think that's a good point, though. If you don't have to go through a lot of setup and configuration, that definitely gives you a head start, right?
\n\nSTEVE: For somebody who's brand new, a minimalist UI kind of helps with the learning curve. When you have something that's very feature-rich, and you're just dipping your toes in the water, sometimes something simpler is more approachable. So, I guess it depends on where they're at. Like, are we talking about somebody who's never seen code before, and this is the first thing they're doing? Or is it somebody who's dabbled but they're not a professional, they want to land a programming job, and they're just kind of doing their thing on their own? I just think it depends on where you're at.
\n\nTAD: What if we assume that it's someone pretty new to programming overall?
\n\nSTEVE: Yeah, in that situation, I would lean towards something like Sublime. I haven't used Notepad, so I don't know what that's like. But something really minimal but still feature-rich. That's my --
\n\nEDDY: You know, we joke around about Notepad. And I actually used Note++ as my primary IDE for a while.
\n\nTAD: Right. You know, I'm joking, too. But the first web page, like, HTML file I ever wrote, I think it was in Notepad. I mean, like, putting an HTML tag at the beginning, an HTML tag at the end, head tag, head tag, body tag, body tag. I think I wrote that in Notepad.
\n\nSTEVE: I didn't even realize you guys were joking because Notepad++ is, like--
\n\nEDDY: [laughs]
\n\nSTEVE: It's not like TextEdit. Like, if you had said TextEdit, then I'd have been like, yeah, obviously a joke. But Notepad actually has formatting, or at least Notepad ++.
\n\nEDDY: Well, I used --
\n\nRAMSES: [inaudible 03:14] have syntax highlighting too?
\n\nEDDY: It does. Yeah.
\n\nRAMSES: Yeah, that's [inaudible 03:19]
\n\nSTEVE: I think it's actually usable on, like, something like text editor.
\n\nEDDY: Again, like, a few days ago, I was curious sort of because I knew this topic was coming, and I just looked worldwide top IDEs. And I don't think it's surprising to anyone when I say that 27%, almost 28% of the market share for IDEs is taken out by Visual Studio Code.
\n\nSTEVE: What are the other market shares, and where are you getting that number?
\n\nEDDY: So, this number is coming from Github.io.
\n\nSTEVE: Microsoft.
\n\nEDDY: Yeah. [laughs] Github.io, yeah, so it's Microsoft. So, there is some sort of bias there, right? But 27%, assuming that that's correct, is one-fourth of the market share, which is tremendous, right? To give you other context, right? Others coming close at 11% is Eclipse, and PyCharm, Android Studio, IntelliJ, NetBeans, Xcode, and Sublime, and Atom. So, those are the top 10.
\n\nRAMSES: Atom is still in the top 10?
\n\nEDDY: I was surprised.
\n\nTAD: That's surprising to me, yeah.
\n\nRAMSES: Yeah, that's interesting --
\n\nTAD: And that GitHub kind of discontinued it and said, "Feel free to continue to use it. But we're not going to be adding new features or fixing things."
\n\nEDDY: I would advocate for Visual Studio Code in the sense that, like, I use it on a day-to-day basis, and I know my way around it pretty well. I know which extensions I like to use, cater it to my productivity, et cetera.
\n\nTAD: You've had some experience now, right? And you didn't start with VS Code as your first editor, I imagine. So --
\n\nEDDY: No. I used Notepad for a bit and then transitioned to Atom because it was, like, the hot thing. And then Visual Studio kind of just came in guns blazing [laughs].
\n\nTAD: Yeah. I think it's kind of funny that we keep mentioning Notepad because, really, you've said minimalist UI. It's certainly got that. We talked about easy-to-use, easy-to-understand, something that comes native with your laptop. I might throw out there you don't have to learn magic key chords or special modes or anything. It's just, you know, CTRL + X CTRL + V to cut and paste.
\n\nDo you think it's valuable if you have something that feels kind of like, I mean, Word or one of these other, like, document editors? Because you might have some of those keyboard shortcuts memorized, and you might have some familiarity with something like that. And if those transfer over to your first IDE, that might be useful.
\n\nSTEVE: Yeah, I think it definitely makes a difference. One point I was going to bring up about Sublime, which is the one that I've used for most of my development career, which isn't terribly long, but I've used that and VS Code. And the thing that I loved about Sublime was the file explorer looks just like the native one on Mac, or it feels similar to it. And it's very easy to use.
\n\nWhereas VS Code, it's really not usable, practically. I mean, you can't really see the indentations, and they throw these gigantic icons in front of all of the files as if they're catering to, like, a toddler. Like, this is a Ruby file, or this is a file or a directory. Here's a huge folder icon, you know.
\n\nSo, I think stuff that looks like your native system, stuff that you're familiar with, just means less learning, which means that you can focus your attention on things that are kind of new concepts that are more important to you in the beginning. So, minimalism and familiarity are things that I would look for, you know, if learning something, but that's my [crosstalk 06:59]
\n\nEDDY: So, let me ask you this: so, is Sublime scalable in a sense where, like, you can continue to use it as your knowledge increases and your tech stack goes up?
\n\nSTEVE: Yeah, definitely you can. The thing is, you have to add extensions, of course, just like you do with any editor. And I'm not really sure why I switched. I didn't have any problem with Sublime. There was nothing that was really slowing me down. I think it was just, out of curiosity, I wanted to try something else. And then once you make the switch, then you're kind of like, all right, I'll just stay here.
\n\nEDDY: [laughs]
\n\nSTEVE: Like, it's not bad, you know. And in the case of VS Code, VS Code isn't bad. Actually, it's very good. I would rate them probably the same. But since I've switched to VS Code, I just stick with it for now.
\n\nTAD: So, Eddy, are you suggesting that another criteria would be something that you can start with but also continue with, right?
\n\nEDDY: Yeah, well, like --
\n\nTAD: You know, integrating it with GitHub.
\n\nEDDY: Yes.
\n\nTAD: Or adding themes and extensions and things like that, that you want something that you can start with, but you can also continue to use even as you gain more advanced skills and get more experience.
\n\nEDDY: Yeah, exactly. Well, I don't want to go on record to, like, sound like, I'm bashing Sublime in any way. I did try it for a few days. My biggest problem I had with it installing packages or extensions were a lot more difficult than they had to be. And, like, VS Code just gave you [laughs], like, a really nice intuitive UI that you can search and install, right? Like, that, for me, was a game changer.
\n\nSTEVE: Yeah, I agree. I think that's a strong point for VS Code.
\n\nTAD: Discoverability might be an important characteristic, right? Because Sublime code was great. I used it for probably a couple of years. But yeah, it's, like, installing things is just, do you know the right key combination to bring up the magic menu that lets you install something, right?
\n\nKYLE: So, as you guys have been conversing about this, I was thinking about the question and how broad it is. And I'm having an issue kind of answering it myself just because there's a lot of unknowns in it, right? Like, okay, where do you start? Are you starting alone? Are you starting with a team? Because if you're starting with a team, they're going to have recommendations, and that's going to affect it. What kind of development are you doing? You know, what language? Where are you starting?
\n\nAnd then, like, are you starting in development, or are you starting in systems? Like, where are you starting? Because that can change whether or not you're going to be using Sublime, Visual Studio, PyCharm, even Vim, or Emacs, you know. Like, maybe somebody's really familiar with the terminal, and it's just a lot easier for them to use Vim.
\n\nTAD: Yeah, I mean, absolutely. Like, if you're doing Swift, you probably want to be using Xcode, right? I mean, certain languages have very opinionated tooling, I think. I think that's a great point, Kyle.
\n\nKYLE: I mean, the other one is, are you on Windows, or are you on Mac? Because that's going to sway you one way or the other as well.
\n\nEDDY: Are you actively...in DevOps, are you guys coding?
\n\nKYLE: So, we have scripting languages that we utilize. So, that's going to be HCL for, like, Terraform and Bash, and we do Python, or we do Ruby. So, for us, in this question for us, we need more of a generalized IDE, something more like Sublime, Visual Studio, right? Something that's not specialized.
\n\nTAD: Do you guys have some Go code? I think I saw some Go the other day.
\n\nKYLE: Yeah, we do Go, too. Yep.
\n\nTAD: Yeah. So --
\n\nEDDY: And so, why do you guys use them, if you use any?
\n\nKYLE: So, we have a couple of members on the team that really prefer to use Vim, and then the rest of us will use Visual Studio Code.
\n\nTAD: This question is actually timely for me. There's another developer that invited me to volunteer with a local group called Tech-Moms. And they're women who are learning to code for the first time. They're just starting out, and, you know, they're moms. I don't know that's a requirement or anything, but they're pretty new to it.
\n\nAnd I volunteered for a couple of hours this last Saturday. And most of my time was spent trying to get them to understand how to clone their GitHub stuff, how to find that cloned repo with Visual Studio Code, and then make the changes, and then push those changes up. And I was talking with some of the people afterwards, and one of the things they really struggled with is it's bring your own machine, right? So, some people bring a Chromebook; some people bring Windows, some people bring Macs.
\n\nAnd I was actually wondering, since VS Code is basically built in a browser with all the Electron stuff, you can actually go to vscode.dev and run it in a webpage. And I was looking at that this past weekend. And I think that might be what I recommend to people right now because you don't need to find it on your machine. You know, something like that works even on a Chromebook, something like that.
\n\nAnd you can get that developer experience just by going to a web page, which is pretty easy to do for most people. Most people know how to type in a URL and go to a page, and then hooking it up with a GitHub repo is also pretty easy. And you can just edit your code from there and just push it from that page. And you don't have to find anything. You don't have to install anything. You just go to a page and install maybe a theme or some extensions, and you're good to go. And I thought that was pretty compelling.
\n\nKYLE: I'd second that. Just because about a year and a half ago now, I was actually helping somebody, you know, because I should be paying attention at church. But I was helping somebody with their code on their phone at church using the online Visual Studio editor. It makes it really easy.
\n\nEDDY: Doesn't github.dev technically use Visual Studio on the surface?
\n\nKYLE: Yeah, it does now, I think.
\n\nEDDY: So, that's just another prime example of, like, the market share for Visual Studio [laughs].
\n\nSTEVE: Yeah, I mean, honestly, Eddy, I don't doubt that it's 27%. That wouldn't surprise me at all. I mean, you just look around; everybody's using it at the office. Again, it depends on the language and what you're doing. But I wouldn't question that statistic. Sounds like all of us on this call, except Ramses, is currently using it, so...But being mostly Ruby developers, Ramses, you use RubyMine, right?
\n\nRAMSES: Yeah, currently. I've used VS Code for a while. Most of my time I've spent using Vim, and I still use Vim. But I think it's the best tool for Ruby on Rails development. Also, it's just great. It's made for the language. I don't know, like, [crosstalk 14:03]
\n\nTAD: Well, it's a true IDE. Like, it's a true integrated development environment, right? Whereas if I'm doing Ruby development, I might have to open the terminal, and that's kind of part of it, and drop in some terminal tools to, like, investigate some stuff. But I have to install a bunch of extensions, maybe have some command line tools and things like that before I get to the same level that RubyMine gives you out of the box.
\n\nEDDY: You know, I'm trying to recall, way back when I did pairing sessions with my older brother, he had me use NetBeans for a bit. And that was super intuitive and really friendly with JavaScript at the time. I don't know if it's still the case, but I almost never hear anyone talking about NetBeans. And from what I recall, it was just a great experience.
\n\nTAD: I think people still use NetBeans.
\n\nSTEVE: I've never heard of that. Okay.
\n\nKYLE: I haven't used that in a long time.
\n\nEDDY: Yeah, it was great. Especially, like, I want to preface by saying, like, being a web developer, especially with Ruby, you're going to be writing a bunch of templating stuff, so, like, some sort of HTML template, you know, in Ruby, in even JavaScript. And I feel like of all the other IDEs that I've used; JavaScript just works really nicely with VS Code. Am I wrong in that statement? Like, do you guys disagree?
\n\nTAD: I'd have to look at the stats. But I've done a few of these, like, JavaScript state of the language surveys and things like that. And I want to say it's maybe... I hope I'm not exaggerating, but I think it's, like, 90% of JavaScript developers use VS Code. And when I say JavaScript, I'm also going to lump TypeScript in with that, just because they've really done a great job of tooling it for JavaScript and TypeScript.
\n\nKYLE: The only thing that I've even used that compares is WebStorm.
\n\nTAD: Wow, I haven't used WebStorm in a while.
\n\nEDDY: You know, and this is kind of a side topic, but you mentioned TypeScript, and you lumped it in. But all I'm hearing now is, like, big projects are ditching TypeScript, right? [laughs] There was, like, a big boom and suddenly...
\n\nTAD: I think there's a hype cycle, right? Where it's the cool thing, it's the new thing, and a lot of people adopt it. And then some people realize, oh, I didn't really adopt it for the right reasons, or this promised me things, but in my particular case, the promises are unmet, right? Like, it's like, you're going to write better code and safer code, and it's going to be so much better. But sometimes people don't see that, right?
\n\nAnd so, a lot of times with these technologies, I think you'll see a big early adopter rush. It cycles through the hype cycle, and then it kind of loses its shine. And so, people are, like, eh, I don't...whatever, and they kind of go find the next big thing. But still, a lot of people who are just happy with it and want to continue using it they're probably not going to write a blog post that says, "Yeah, I'm still happy with this technology [laughs]. And I'm going to use it again tomorrow."
\n\nI've seen a lot of that in the Rails community when the hype was really high, and now it's just a well-known framework. And it's not going to get your picture on the front cover of any magazines or anything. I think DHH was featured on a bunch back in the day, right? But people still use it. And it's just kind of typical boring technology now. And I'm not going to write a blog post that, yeah, I still like Ruby, right? It's usually the things that, like, we tried TypeScript, and we didn't like it after all, and we're switching. That's a more interesting blog post.
\n\nEDDY: So, I have a genuine question, and I haven't actually looked much into it. But I feel like if you're going to be a web developer, the default is always Visual Studio Code. But what happens if you want to be a mobile developer or, like, some sort of scripting language? Is that still, like, work neatly with VS Code? Or does that sort of mentality shift a little bit depending on, like, the stack? Or even, like, [crosstalk 18:13] game development, right? So, like, Triple-A games that are being developed actively, like what IDEs do they use? Like, is it still VS Code, or is that just a given with web development?
\n\nSERGIO: I just developed two video games in the past; one was released in Steam. And I used to work with C++ and also with C# on game development stuff. But when working on Unity, Unity has their own IDE, which is cool. It's good enough. But also, I've been working lastly with Visual Code. I think Visual Code is still missing some stuff like all IDEs has.
\n\nBut lastly, I've been testing compiler with Visual Code, and it looks really nice. It's very useful when I work in unit tests in many stuff with JavaScript, with HTML, with Ruby, and even, I guess, with C#. So, I can say that's my answer. It's kind of it's really cool right now. But other IDEs like Unity built-in IDE is nice enough as well.
\n\nEDDY: I didn't know Unity had its own built-in UI or, like, IDE. That's [laughs] really cool.
\n\nTAD: I mean, I think it depends on the game framework because you might have something that helps you...and I haven't done a lot of game development myself, but from what I've seen, you have to manage a lot of assets and things like that. And if you've got Visual Studio, then you're just kind of left to whatever tools you want to, like, manage your assets, or edit your sprites, or do those sorts of things. But there are integrated development environments for game development that have all the tools that you need to build the game in one place. And you don't have to add additional outside tools to get that same experience.
\n\nSERGIO: Yeah, yeah, that's the way it works right now. So, it's kind of integrated all the things you need. And essentially, when you're working with 3D and 2D assets, it's really complex. You know, you have a scenario where you have to import assets and also, you have to modify code at the same time, so you need something really custom. So, it's cool.
\n\nI'm working a lot of time with C#, and I'm working with Visual Studio. At this point in time, I do prefer Visual Studio Code instead of Visual Studio. It's lightweight. And also, you can extend, you know, many things. Like I mentioned before, [inaudible 20:59]. I have plenty couple of things that worth testing. And also, one extension that I like so much is when we do pair programming. Do you remember that one, Eddy? I just learn many things from many people from --
\n\nEDDY: Live Share.
\n\nSERGIO: Yeah, Live Share. Yeah, that one. Awesome. Yeah, you can do that with...I guess Visual Studio doesn't have that functionality, but instead, Visual Studio Code it does. I am not sure about this, but I'm almost sure that you have to pay the MSDS subscription. So, you have built-in functionalities that the normal Visual Studio doesn't have on this. You pay for it. So, that's cool.
\n\nTAD: Yeah, I think, for me, Live Share is a killer feature, especially for pairing and especially when I'm pairing with somebody who's new to coding, where I can get them to send me their session string, and I can join their session. And I can explain to them what I'm doing as I'm doing it, as it appears on their screen. I can kind of stub out or kind of trace out some things and then have them fill it in.
\n\nLike, yesterday, Damon and I were pairing, and we couldn't get the Live Share working. But something that I desperately wanted to do was I had kind of outlined all our tests, right? Like, the context, and the blocks, and things like that. And then to be able to hand it over to him and say, "Okay, I've outlined this; now fill it in for me," I find that really compelling, especially the fact that it has built-in chat. I don't know that we use that much. We chat through other things.
\n\nBut it tells you who's editing which file, and you can either follow them and see what they're doing, or you can go off and do your own thing. I mean, those kinds of features I often call it multiplayer programming. I think that's probably one of my favorite features of VS Code, especially when it comes to helping newer developers.
\n\nEDDY: Yeah, that's awesome. That's super cool to know that you, like, outlined it for them in the live session [laughs]. That's so cool. It's also cool...when was it? Like, Sergio, myself, and Jonathan would pair in a ticket, and, like, one of us would, like, be writing the specs at the same time the other person's writing the code. It's also another way to be super productive because you get things done much quicker, which is another compelling thing with it.
\n\nTAD: Yeah, I don't know if you guys were familiar with the old XP things. But there used to be, like, these hardware setups where you'd have, like, two separate keyboards that both fed into the same thing. And you could type, and you could do these things. And Live Share is basically living the dream where I don't have to hand off my laptop to someone else.
\n\nI don't have to have some crazy setup where we have two keyboards plugged into the same computer that we're looking at. I mean, basically, when I do it, the thing I'm looking at is what they're looking at, and what I'm talking about is what they're looking at. And that's, like, the dream of the guys that really kind of pioneered the XP movement back in the, gosh, '90s.
\n\nSERGIO: Hey, Tad, you did XP before. It's kind of the old-school way. Yeah --
\n\nTAD: Yeah, kind of. To be honest, we did it in college. And I don't remember what distinguishes XP from some of the other things. But we did have times where it was basically two people sit down at the same computer and team up and pair and work on stuff.
\n\nSERGIO: Yeah, I tried that in the university when we have this project. And we have a big monitor and everything else. People working is kind of [inaudible 25:04], I guess, and only one main programmer. It's kind of the other people is only seeing you. But that's weird, you know, it's kind of odd.
\n\nI like to do stuff. So, this extension, Live Share, is kind of cool because everyone can write code at the same time. It's kind of you are not alone just seeing the code. You can interact directly with the code and write your own things. So yeah, many times, we broke things because watch people is doing one thing, and the other is trying other stuff [laughs]. But it's part of the coolness, you know [laughs].
\n\nTAD: Right. Are there any other needs that maybe a newer developer would need that we haven't talked about yet?
\n\nEDDY: I guess also, like, what operating system? Should they use Mac, Windows, or [laughs] Linux distro?
\n\nTAD: Linux? Well, that's why I'm thinking about pushing the browser because then it doesn't matter. You know, start out with the editor in the browser and learn how you like things, and then graduate to something else.
\n\nEDDY: Yeah. But will the browser sort of compile the code for you if you needed to?
\n\nTAD: I don't think so. But I don't work with a lot of compiled languages nowadays, so I don't know. I tried going to vscode.dev, and I noticed that some of the extensions I like don't work in the browser, which makes sense, you know, so that's the thing. Like, it's probably a good place to start. But, ultimately, most people shouldn't stay there. So, for my own maybe curiosity, but of the people here in this call, what was the first editor that you used? And what was the second editor that you used for actual developing and writing code?
\n\nSTEVE: My first one was Sublime, and I stuck with it for a long time, I think four years. And then VS Code. I think I've tried something else along the way. I don't remember what it was, but I wasn't impressed, obviously, if I don't even remember which one it was.
\n\nKYLE: I started out with Visual Studio as my first one, and my second was actually Vi.
\n\nEDDY: What's Vi?
\n\nKYLE: Precursor to Vim.
\n\nTAD: [inaudible 27:21] Vim.
\n\nRAMSES: Just the original.
\n\nEDDY: Okay [laughs]. I know now. I use it from time to time when I shell into an environment.
\n\nTAD: Was Vi just because that's easier to use remotely on, like, servers and stuff?
\n\nKYLE: Yeah, it was part of a networking class. And we had to do all of our development on a remote server in the professor's office, basically.
\n\nEDDY: It's actually really funny how Sergio joined halfway through the call, and he mentioned Notepad, even though we were kidding initially. It just goes to show, you know, like, how embedded Notepad really is.
\n\nTAD: Well, there's Notepad, and then there's, like, Notepad++, which is different, but it's still a very simple but very intuitive editor.
\n\nSTEVE: I didn't even know you guys were joking [laughs]. I was under the impression Notepad++ was just, like, a normal editor.
\n\nTAD: It is. Eddy, what did you start off with, and what did you...
\n\nEDDY: I started off with [laughs] Notepad and then...but it wasn't Notepad++. It was the Microsoft Notepad, you know, all the do-do that is given to you pre-installed to write notes. Like, that's how I initially started writing, like, HTML. And then, like, I opened the file in my browser, you know, and the file--
\n\nTAD: [inaudible 28:45]
\n\nEDDY: Yeah, it was great. It was super cool.
\n\nAnd then the next one, I believe, if I'm not mistaken, was Atom. Because, like, I joined forum groups and Reddit threads and, like, people talking about this whole new thing called Atom. So, I installed it, and it was, like, a full 180 for me because it was like, oh crap, going from black and white to, like, suddenly, like, my code is linted [laughs], you know. And so --
\n\nTAD: Syntax highlighting: so good.
\n\nEDDY: Yeah [laughs]. You're like, oh, your brackets know, like, if you have, like, nested statements, or whatever, you know, like, suddenly, your open and close brackets are aligned by color and stuff like that, which made it much easier and more intuitive. And using Atom for me has a warm place in my heart.
\n\nTAD: Ramses, what did you start with, and what did you pick after that? Or did you start with Vim and stayed forever with Vim?
\n\nRAMSES: No, I started with Atom and then went to VS Code, actually, for a little while. All of my professional development experience has been in Vim until now, that I'm in RubyMine. Outside of that, yeah, Vim all the way.
\n\nEDDY: Dude, you started out using Atom? That's awesome.
\n\nRAMSES: Yeah, that was probably, like, three years ago when I started using it. It worked out pretty nicely. I actually don't know why I stopped using it, just did. I've always been curious about different editors, so I've tried a whole handful.
\n\nTAD: Sergio, what did you start with, and what was your second editor?
\n\nSERGIO: Notepad ++ recently. Probably Notepad, the normal one, like Eddy. I used to learn in Notepad ++. Later, I tried many, I guess, most of the [laughs] IDEs out there. But I used to work with Java, and Java has their own IDEs like Eclipse and NetBeans. And also, that one included in Android, which is JetBrains with supercharged Java stuff built-in, I don't know, some mixing of things.
\n\nAnd lastly, I ended up with Visual Studio Code. It's kind of my favorite out there because lightweight. And I used to remember when I tried to open Eclipse on my computer, it was kind of, oh my God, it's draining all the resources in my [laughs] machine. So, oh gosh, that time was hard. And right now, I have a computer that is, yeah, better, and it's not draining all the resources. And that's cool. So, the only one that is draining resources is Unity because the nature of being greedy 2D and whatever else is kind of resource demanding. But everything else works fine in almost any computer out of there. But Eclipse is a nightmare [laughs] [inaudible 31:45].
\n\nTAD: Yeah, with great power comes great resource usage, great hardware abuse [laughs]. Yeah, it's funny that for some people, VS Code feels light. For other people, VS Code feels very heavy because it's basically a mini browser just to edit text, right? And so, if you're probably somewhere at the Emacs or Vim end of the spectrum, VS Code feels like a ton of resources and very heavy. But if you've worked with some of these bigger IDEs, VS Code is probably refreshing.
\n\nSERGIO: Yeah, yeah, I agree. I do have a question, maybe. Why I will use Vim? It is kind of new for me. I never worked in that before. It's kind of complex because you have to learn about when you have to use SS, or you have to edit, or something like that. I didn't know why I will use Vim. Can you answer that? Can you tell me someone that is actually using Vim why I will use this? Well, I understand it if you work on serverless stuff, you have to use it, and that's fine. But someone who is not using that for serverless, why I will use Vim?
\n\nKYLE: Their approach to modal editing is just fantastic. I find myself to be a lot more productive. Once you learn the Vim motions of editing text, it just becomes much more fluid. But the problem with it is it requires a steep learning curve, so, you know, not great. But once you get a hang of it, you just want Vim everywhere.
\n\nTAD: Yeah, I don't use Vim, but I know people who do and, basically, once they get really good, you're editing code at the speed of thought a lot of times, where your fingers are just moving automatically, and you're moving lines around. You're editing things across multiple lines. And, you know, the joke is you never have to pick your fingers up from the keyboard. You never have to touch that mouse.
\n\nBut yeah, like, I tried Vim for about a month because I figured that I needed to give it at least that long. And I just don't think in that way. So, it didn't work for me, but people who think in a very Vim way they can be really productive, and it feels really elegant to them.
\n\nSTEVE: I think you also mentioned one of the key things with Vim. And I'm not speaking from experience, but people that I've spoke to about it tend to not like using a mouse, so there's that. I think Vim is kind of is the go-to if that's you.
\n\nSERGIO: Cool. Okay.
\n\nEDDY: Yeah, some people are religious to not using a mouse, and I'm not calling anyone out, but I am looking at that person. Some people just refuse to use a mouse. And they really do try their best to never lift their hands off of the keyboard if they don't have to. And Vim does facilitate that [crosstalk 34:45].
\n\nTAD: Well, it's unnecessary motion, right? If you can keep your hands practically on the home row and move everything around, suddenly, excess motion feels inelegant, right? It feels like unnecessary wasted behavior.
\n\nEDDY: I feel like we can't end this topic without mentioning Emacs because Emacs is also a really strong competitor against Vim. And it's really solid out the gate.
\n\nTAD: Yeah, it's interesting because we all have mentioned that we develop Ruby, and Ruby was actually shaped by Emacs, meaning Matz, who's the original creator of the Ruby programming language, uses Emacs in his day-to-day editing of everything. And the elegance of Lisp, and how Lisp kind of did things, and the interpretation of it, and things like that, really influenced what he wanted in the language and really added to Ruby's development.
\n\nSo, one maybe final question for you guys: is there an editor that you've tried that you absolutely hated? Like, you're just like, "Oh my gosh." You know, you tried it for, like, 10 minutes or something, and you just realized this absolutely is not the editor for me. And if you've had that experience, I'm curious: what was it about that particular editor that really you found so off-putting?
\n\nSTEVE: Vi [laughs]. Because why would I use that? There's no reason for it. But every time I'm stuck having to use it just by chance, like, I don't enjoy it at all.
\n\nTAD: Is it the modal nature of it? Is it the fact that there's nothing discoverable about it? Like, what's the --
\n\nSTEVE: Well, it's just I don't know how to use it, so I have to look it up every single time. Depending on how my environment is set up, I might find myself in a Vi session and, I don't know, maybe during a rebase or something if I haven't set my editor yet. And that always annoys me [laughs].
\n\nEDDY: I think there's benefit learning Vi, especially where we work, right? Because, you know, you shell into a certain cluster and then, suddenly, like, you need to modify some code. But you're like, ah, I don't want to, like, wait for my build to be ready again in order for me to make sure that this would have worked. And so, using Vi to go in there in your session and being able to change that on-demand is super cool.
\n\nKYLE: I think I run into the same things as Steve, just with Nano.
\n\nSERGIO: I have to say Eclipse a long time ago. But something I tried recently is Vim, and I didn't like it at all. But maybe I need to give it another chance to try to really understand why it was built that way, so maybe.
\n\nTAD: Yeah. The angriest I think I've ever gotten is using VS Code. This is way back in the day. And I was taking a class on UI development, and the first half was Java. We created, like, these Java apps with Swing. And the second half was with Microsoft, and we had to use these things called Microsoft Foundation Classes. And they were so complicated that the editor tried to fix things for you behind the scenes.
\n\nBut sometimes you really wanted to have a certain thing in a certain place. And I would say, I need to make this button blue, right? So, I'd go into the code, and I'd change the attribute to make my button blue. And Visual Studio didn't think that was the right place. And it would take it out and try to do other things for me behind the scenes. I would stare at things, and I'm like, oh my gosh, I don't know why this isn't working. I don't know what's going on.
\n\nAnd it turned out that the editor was actually moving my code around without me knowing it. And I spent, like, hours sometimes trying to figure out what the heck was going on. If VS Code was a person, I'd punch it in the face [laughs], oh my God. It made me so angry to have an editor changing my code on me behind the scenes without my knowledge or permission.
\n\nWell, it looks like [laughs], I guess, maybe we're ending on that note. Anything else we should mention before we wrap this up?
\n\nRAMSES: What I gathered from it was that we should all use Vim.
\n\nTAD: [laughs] That's an excellent takeaway.
\n\nSTEVE: Yeah, that's it.
\n\nTAD: If you have someone that comes to you and says, "I want to get into programming. Where do I start?" You point them at Vim [laughter] or --
\n\nEDDY: And if they still stick around, they definitely want to be a developer, is what you're saying.
\n\nTAD: Yeah. Or maybe you just point them at Notepad or vscode.dev or something like that and then see what they lean to. And then find a better tool for them later when they settle into something.
\n\nSTEVE: Just ask them the question, "Are you a masochist or not?"
\n\nTAD: [laughs]
\n\nSTEVE: And then adjust accordingly.
\n\nTAD: How's your self-esteem? Do you like yourself? [laughter] Cool, awesome. Well, thank you, everybody.
","summary":"","date_published":"2023-12-20T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/f2d2b8c4-78cc-4df1-95c6-9af58f2c5bc6.mp3","mime_type":"audio/mpeg","size_in_bytes":41820647,"duration_in_seconds":2422}]},{"id":"3ade316e-c9e1-4ac5-b412-6460896f1d82","title":"Episode 34: Learning New Programming Languages","url":"https://acima-development.fireside.fm/34","content_text":"The panelists explore the value of learning new programming languages. The conversation begins with personal stories about their first programming experiences, discussing languages like Logo and BASIC and, later, more complex ones such as Java, Pascal, C, C++, Perl, PHP, Haskell, and Python. They emphasize how each language forces a developer to think differently about problems, highlighting the significant role of learning various languages in a developer's growth. They also touch on the practicalities and peculiarities of different languages, like the ease of PHP compared to C for web development and the sophistication of memory management in languages like Java and Rust.\n\nThe discussion then pivots to the core question of the podcast: the value of methodically learning new programming languages. Mike shares his perspective, noting that while he hasn't learned a new language every year, the variety he has learned has been crucial for his career development. Tad recounts an insightful conversation with Matz, the creator of Ruby, about the joy and utility of learning diverse languages, even those with limited professional application. This leads to a broader discussion about how each language, with its unique approach to solving problems, can add valuable tools to a developer's toolbox.\n\nIn the final part of their conversation, they delve into the future of programming languages and discuss the potential of domain-specific languages tailored to particular industries or needs and the role of emerging technologies in shaping how we interact with technology. Mike speculates about conversational interfaces and their implications for future software development, emphasizing the importance of adapting to new ways of thinking and interacting with machines. They end with an affirmation of the continuous need for learning in the ever-evolving field of software development, underscoring that learning new languages enhances problem-solving skills and prepares developers for future technological advances. \n\nTranscript:\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm going to be hosting today. And together with me, we have Ramses and Tad. Today, we're going to be talking about learning new programming languages, specifically what value you get from learning them. And beyond that [chuckles], not just learning them because you're forced to, but deliberately going out and learning languages regularly, you know, once a year or some cadence like that. And why would you do that sort of thing? That's the premise we're going to start with. \n\nAnd before we really dive into the conversation, Tad, before we jumped into the recording, said, you know, a good place to start here is talking about the first language you learned. Like, yeah, you know, actually, that's a great idea. And thinking back to childhood, the first programming language I learned was Logo. They called it the turtle, but I think it's really just a triangle. And you [chuckles] make it go around the screen, and it leaves a trail behind it. And you could use it to draw pictures. \n\nI didn't have a computer at home at the time, and I'd used it at school. And I thought it was just the coolest thing ever. I believe that it usually ran in a real-time mode, where it was interpreting what you put in. It was actually pretty sophisticated for back in that time. The read–eval–print loop is, you know, very common now in interpreted languages, but back then, that was pretty sophisticated. \n\nMy understanding is that Logo is a variant of Lisp. I didn't know I was learning Lisp. I was just learning how to move the turtle around. I thought it was the coolest. And I do remember that I could go back into a screen where you could actually write some code, rather than running in that real-time evaluation loop, and then have it draw cool patterns on the screen, and I thought that was just the best [laughs]. \n\nI remember thinking it was so cool, but then you had to have shared computer time with everybody else in the grade. It might have even been shared with everybody else in the school. So [chuckles], I didn't get a whole lot of time on the computer. And I didn't really pursue programming that much other than thinking that it was cool. Sometime after that, I couldn't say exactly when, but I think I had friends that introduced me to the BASIC programming language. \n\nBASIC has a very different take on things. The lines are numbered. You always had to put numbers, and you developed a habit of incrementing by at least 10. You'd do line 10, line 20, and line 30. So, in case you ever needed to insert anything in between, you didn't have to renumber every line. I've had to do that [laughs] in BASIC, to go back and renumber everything. When my family first got a computer, it came with a BASIC interpreter. And we had a book, and I went through, and I did a lot of BASIC programming. And I did. I'd fill up all my spaces; then I'd have to go renumber everything.\n\nThe thing, though, about switching out of the languages, I learned about BASIC-supported subroutines, they called them. They had GOTO, so you just bounced around just at random [laughs]. If you wanted to be able to have any ordered thing at all, you would develop...it wasn't a function like you'd think about in more modern programming languages but the same idea what they called a subroutine where you could go to this region of code that would execute independently.\n\nTAD: GOSUB [crosstalk 03:09] GOTO.\n\nMIKE: Exactly. GOSUB [laughs]. I think you could even treat them as function calls and pass variables to them. Do you remember Tad? \n\nTAD: You couldn't with the BASIC I learned. There might have been BASIC variants that could do that.\n\nMIKE: Yeah. It seemed like they could maybe have return values. There was something that distinguished them from a GOTO. And then I did a lot of that when I was in my early teens. And the next programming language I learned was probably Pascal in school, and asked to learn Java, and C, and C++. And professionally, your first job, you usually end up picking up a language because you end up having to do stuff you haven't done before. I learned Perl and then did a lot of Java, PHP, web languages back in the day. But I ended up touching a lot of things. There was ColdFusion [laughs]. \n\nTAD: Oh gosh.\n\nMIKE: Yeah. And then later, as I moved along in my career, there were actually some languages I learned just to learn, and I think I'm going to come back to that. But Haskell, specifically, is one that I deliberately chose to learn, and I'm glad that I did. I've learned Python somewhat in recent years, which has been a useful tool. \n\nThe interesting thing about this, I'd mentioned the subroutines [laughs], is that every one of these languages forced me to think about problems differently because these languages represent a way of thinking. They approach a problem in a slightly different way. There's a lot of overlap between them. Once you've learned one, it's a lot easier to pick up another. But making that switch between languages really forces you to recognize that maybe there's more than one way to think about a problem. And then you're forced to evaluate, well, which way do I want to think about the problem? And that switch between frames of thinking, I think, has been very useful. \n\nI would strongly recommend that people take the time to learn other languages, especially languages that are very different than what you're used to. I think it's useful to learn Assembly language, for example, maybe not in-depth, but at least to understand how it works so you can think about how a processor works. I recommend learning a functional language. I've mentioned Haskell. It's a pure functional language that really forces you to think in a certain, very mathematical way, and it helps you approach certain problems differently. \n\nAnd you should probably learn an interpreted language if you've been a compiled language person all the time and so on, approaching problems differently. So, there's my limited introduction. I'm saying this history of languages I've learned has helped me a lot, and I'd recommend others to do the same. Now, Tad, you've been talking a little bit. What's been your history with programming languages?\n\nTAD: My first programming language was BASIC, which is probably really common for anybody who grew up in the '80s like I did. My parents bought the family an old computer. Texas Instruments used to have a computer that they sold that you could plug into your TV. It was called the TI-99. And if you put a cartridge in, then you could play that cartridge. But when it booted up, there was always a menu. \n\nNumber one was it dropped you into a BASIC shell thing, or number two was play the game. And so, after you've been using this computer for a while, you're like, huh, I wonder what that, like, number one option is, right? And it just basically just dropped you into BASIC. And, like you were saying, it came with a manual that gave you the basics of BASIC. It was, like, line numbers, and you'd always do 10. You're like, ten prints, you're awesome, 20 GOTO 10. And you're like, ah, like, you show your sister like, \"Oh, look, our computer thinks I'm awesome,\" or whatever. \n\nBut yeah, like, that was just being able to have something to show up on the screen. It gave you BASIC syntax, you know, control structures like ifs and thens and all that stuff. If this, go to there; if else, go to this, that kind of thing. That was what I thought programming was all about was just big, long, BASIC programs. \n\nAnd I remember later in the '80s, Macintosh Classics became pretty ubiquitous at, like, high schools or just different schools and stuff. They all came with HyperCard, which had a programming language behind it called HyperTalk. And I remember trying to look through the mail trying to figure it out because I looked at the examples, and they didn't have any line numbers. And I couldn't conceive of programming without line numbers. I was like, how do you go to something if you don't go to a line number? Like, how do you use your GOTOs if you don't have line numbers, right? And so, that was kind of an eye-opening idea that, wait a second, I don't need GOTOs at all? How does that even work, right? \n\nMIKE: [laughs]\n\nTAD: And HyperTalk was really interesting because it was very English-like. And the idea was you basically have a stack of cards. Each of those cards, you could put different buttons and different like UI elements on that card. And then, you could have those UI elements; each of them have some code behind them. And then you could swap between the cards and things like that. \n\nAnd so, the very first thing that you could do was make a stack of cards and do a different picture on each card, and then your program would just be, show all cards. And that would just flip through all the cards and create a little animation for you, right? And just the fact that it was English and you could say, \"Show all cards,\" and that was just intuitive, right? And was just kind of mind-blowing. You could set the speed that it shows all the cards. And so, something like that where it was very English-like, very intuitive.\n\nBut it was also evented. So, you could write little handlers. Like, you could say, \"On mouse up,\" and then you would write the body of the things you want to do when the mouse is clicked, or whatever, or on button clicks and things like that. And so, it kind of put me into a mode of looking at things from, like, a UI perspective and event perspective, you know, messaging back and forth between the different elements and stuff. And so, that was a huge departure for me from BASIC. \n\nAnd then probably the third language I learned was C, which, again, is very different because it's the first time I ever had a compiled language. It's the first time I really thought hard about functional programming, probably the first time I ever encountered libraries and shared libraries. Because I'd have to yell pound, include standard io at the beginning, right? You don't just get that for free. You have to, like, ask for io stuff. You have to set up a main function. You have to do those sorts of things. So yeah, that was also a very different language from the first two I learned as well. So, anyway, yeah, like, it's all very interesting to learn. \n\nMIKE: You talked about HyperTalk changing your perspective because you thought, oh, things don't have to be this procedure where you control the flow yourself. The language can do some of that for you. \n\nTAD: Right. Yeah. \n\nMIKE: And teaching you about libraries. I mean, those are major concepts, right? \n\nTAD: Yeah. I mean, my simple BASIC interpreter didn't have libraries. HyperCard just had everything built in. You didn't, like, grab things from external sources. I think you could, but I had no idea of what that was or what it meant.\n\nMIKE: So, you know, there was that step, the step between this in a progression. Sounds somewhat similar to the things I did, I have learned over time. So, Ramses, I'll ask you, I don't know how many languages that you have worked with.\n\nRAMSES: Certainly not as many as you or Tad, I'm sure [laughs]. Probably started with Lua, I want to say. Like –-\n\nTAD: Oh, nice, yeah. \n\nMIKE: Embedded development. \n\nRAMSES: Yeah, it was great. \n\nTAD: A lot of kids are, like, Roblox and stuff when they start learning Lua. \n\nRAMSES: Yeah, it's a pretty good platform for that. It teaches a lot of the basics and gets you familiar with a lot of the core concepts of programming and, you know, communicating between client and server and back. And my primary, of course, is Ruby, mainly Ruby on Rails. I do have experience with JavaScript. I'm currently learning Java, and I have tinkered a little bit with Elixir, not enough to be proficient.\n\nMIKE: Well, let me ask you a follow-up question. Maybe I should ask about Elixir because it stands out among those as being distinctly different. But there's, I mean, there are differences between those languages. What's something that surprised you or helped you progress from one of these languages, Ramses? \n\nRAMSES: Mostly curiosity, I would say. That's the biggest driver for why even try to approach something different.\n\nMIKE: Absolutely. Curiosity kind of drives the learning. What is something you've discovered in a language that made you think, oh, well, that's different?\n\nRAMSES: Well, I don't know if this is the biggest one, but I thought the pipeline operator in Elixir was very interesting.\n\nMIKE: I was talking with some people about that this morning [laughs], just this morning, comparing that with an attempt to do that in a language that didn't support it. That didn't work out so well. That pipeline idea of having a series of steps that you can break out on it's a great idea, right?\n\nRAMSES: Yeah.\n\nMIKE: Once you see it, you know, like, you can't unsee it [chuckles]. Like, wow, that's a good way to approach a problem. And, Tad, you've mentioned a couple of things that were enlightening to you [laughs], the epiphany. Are there any others that have really stood out to you?\n\nTAD: I did a bit of Closure for a while. Ruby is Lispy, but it's not Lisp, right? Ruby has certainly stolen a ton of Lisp ideas, but it's not, like, that pure. I see a bunch of parenths on my screen. Everything is nested parenths Lisp. And they also have, like, a kind of a threading operator—I think that's what they call it—that kind of pipes things through. And I mean, with C, you get pretty functional. But Lisp is probably the grandpa. I'd say it's probably the purest, most influential functional language there is. \n\nSo, once you get into that mindset of, oh, everything is data, everything is streaming data and transforming data, it's interesting how you start to see every problem of, oh, how could I just make this as a series of pieces in my pipeline and my data is just going to flow through them all, right? And you realize, oh, this is very predictable. This is very easy to test. And it's really interesting to get put into that kind of functional programming mindset.\n\nMIKE: I can say you're noticing a similar idea of these pipelines. \n\nTAD: Yeah. \n\nMIKE: There was a moment for me...I could talk about a different language, but, actually, it was, I think, a comment I read in a book I was reading that said, \"Well, if you think about SQL and how it does things, that's basically the way that functional languages do things.\" Like, wait, what? I've thought deeply about that since. SQL or SQL, some people call it, sometimes it stands for some things, sometimes it doesn't [chuckles]. The language used for creating databases. \n\nIt's this widely used language that is completely declarative. There are, like, variants on it that allow you to do some procedural stuff where you can have loops and so on. But out of the box, you can declare the kind of transformations you can run on the data you start with to get a set of data out. And you might think, well, what good is that? What good does that do? All you can do is transform data. I mean, does it do things? And yet, it manages to be kind of the foundation of a lot of what the web is built on, right? \n\nWe have databases. We have data storage. And somehow, you need to present that to your users, and in between, you need to transform it. And I don't know if I want to say we overthink our value, but I don't think that's quite true. I think I would rephrase it differently that sometimes we don't recognize how valuable it is to be able to take some source data, run some transformations on it, and display it to somebody. \n\nYou think of even a social network, pick your social network. Somebody who's listening to this 20 years from now they'll go, \"Huh, they were using those?\" [laughs] But what's the biggest one today? It's probably Facebook. You know, they collect vast amounts of data on people, maybe scary amounts of data [chuckles] on people. And then, they compile that together and present it to you. And it's really data transformation. And they start with some source data, they mix it with some rules, and they show it to you. And they've managed to build this massive company. It's one of the top five most valuable companies on Earth. It's what they do.\n\nOr you look at, say, Google, that has powered the, you know, web for four decades now. They store a bunch of information about their web crawls, and they show you that data [chuckles] after they've, you know, stored it and indexed it. The ability to efficiently store information and efficiently take that information and somehow transform it into a useful format to read because, you know, the whole web out there is not very useful to me because it's too much. I can't find anything in it. \n\nBut if you can save that in a way that's well indexed and can be returned to me in a sorted form with the most relevant things up front, well, that's exceptionally valuable to me, you know. It has made them vast sums of money because it was incredibly valuable. Advertisers have spent a huge amount of money on these platforms because people use it because it improves our lives. \n\nSo, this transformation of data, this idea that you start with some data, you run some transformations on it, and you get data out on the other side that's in a more useful form, I think is fundamental to most of what we do in software development. And once you think about that that way...and both Ramses and Tad talked about this kind of pipeline idea, that you start and you go through these series of transformations, and you get something out the other side. It's been transformative to me. \n\nI think I mentioned I studied Haskell a few years ago, a functional language. Everything's built around that idea. And internalizing that idea, of course, not just from Haskell but from other resources, I think has been very influential on me as a developer, and some of the best code I write is rooted in those ideas.\n\nTAD: What's a language that's on your radar right now?\n\nRAMSES: I know Python is kind of the new hot [inaudible 17:49]. It's been the hottest for a while. \n\nMIKE: Yeah, the old hotness [laughs].\n\nRAMSES: The old stuff. I mean, there's --\n\nTAD: Since the '90s. \n\nRAMSES: Yeah, it's kind of a big one currently; probably would like to learn it more at some point. But, my current focus is Java.\n\nMIKE: If you know Ruby, switching over to Python is almost trivial, not completely. They're slightly different, but they have very similar paradigms. My language, I would say, Julia.\n\nTAD: Oooh. For data stuff, huh? \n\nMIKE: Yeah, I've been interested in data for quite a while. And I am really interested in machine learning. And a lot of machine learning world is using Python. That's mostly what I've done with Python. But Python is not known for being efficient [laughs]. There's people working on that. There's people working on that, I'll say. I'll give them credit for that. \n\nBut there are, you know, lots of different tactics people have taken to try to deal with them; one of those is to create a new language, and Julia is one of those. And that's one that I've been interested in trying out. You know, I don't know that I'd use it on a day-to-day basis, but I'd like to see that approach to the world. What about you, Tad?\n\nTAD: I remember when Swift came out, they gave you a free book like, Apple says, \"Here's a book on Swift,\" when it first came out. And I've always thought that Swift looks really interesting. It's obviously a language that has drawn on a bunch of other languages and looked pretty clean. \n\nAnd some of the interesting things that I liked about it that I'd like to see in other languages are optional typing because I don't love forced typing. But I think typing can be useful sometimes, right? And so, I'd like to steal the idea of optional typing from a language like Swift and then give it to maybe a language like Ruby, right? Because Ruby is all dynamically typed. But I'm like, uh, sometimes I'd like to have types. \n\nI've had some Elixir books for a while. They do some really interesting things, especially with their matching, where it's basically make this side match that side. The destructuring that you see kind of popping up in other languages has largely been inspired by Elixir and its ability to just really nicely destructure things, right?\n\nMIKE: Yep. That pattern matching has been a thing in functional languages for a while, and it's cool. \n\nTAD: Yeah. I think Elixir really took it to the next level. I don't know of other languages that did it. Well, I'm sure Erlang does just because what's under the hood of Elixir [inaudible 20:27]. Elixir put a nice, approachable veneer over that whole beam, the whole ecosystem there. \n\nWhat other languages are interesting? I like Lua. I learned a little bit of Lua with my kids. I think it's like a better JavaScript. I wish that they would have discovered Lua, and we would have had that instead. Rust has been on my radar for a while, but I just don't have any use for it in anything I do day to day. \n\nYou know, just speaking about how languages change your thinking, I did a ton of C in college. And then, when I got to some of the upper-level classes, we started doing Java and stuff like that. And I was like, oh wait, what? You don't have to do memory management? There's a garbage collector? Wait, what's going on? Like, the fact that I could basically run my Java programs cross-platform-ish, you know, on the JVM for whatever operating system I was on. \n\nAnd Java, you can kind of fake it where you could put pointers to different references...I forgot. I haven't done Java in a while. But you could mix and match an array, and you could stick different objects in an array if you just made your array object references. I was like, wait, I'm getting tricky, right? But yeah, the fact that Java had different memory handling was really interesting to me. And Rust, I think even more so, the fact that you can get the performance of, like, a compiled language with memory safety, and you don't have to hand that off to a garbage collector, is really interesting, I think. \n\nI've seen the argument or the joke: you're just moving all that stuff from the compiler into your head, where you just have to think real hard to do your memory management instead of letting your compiler or your language do it. But yeah, so there are still languages coming out that have interesting ideas that I'd like to explore.\n\nMIKE: I think that provides a good pivot to what kind of our central theme was that we wanted to talk about in this podcast. We've talked about some value we've gotten from languages. What's the value in methodically going out and learning them? Is this something people should do, and if so, how often and why? And maybe a split question: what happens if you don't? [laughs]\n\nI will say I have not specifically made a point of learning a new language every year. But if you add up all of the languages that I've learned, I'm probably not too far away from it because there are a lot of languages out there, especially if you count non-procedural languages, you'll get HTML, CSS, SQL, even, like, Regular Expressions. There's a lot of languages that we learn as developers, and if you start adding all the languages up, it can add up to quite a few. And I think I'm not too far from one a year.\n\nI would say that if I hadn't done that, I would not be in a good spot. If I'd stuck with Perl, I'd be an aging guy still doing Perl [laughs]. And Perl's not a bad language, don't get me wrong. But professional opportunities are rather limited nowadays in that language [laughs]. And it has a lot of interesting ideas. Perl is actually a fascinating language where they've experimented with some things, kind of tried to push the boundaries. It's Larry Wall, right?\n\nTAD: Yeah.\n\nMIKE: That built the language. He studies languages professionally. He really thinks about interesting things you can do with language. So, great language. I'm not saying something bad about Perl. But if I was just doing Perl, or if I was just doing Logo that I learned in elementary school, again, it's a Lisp variant. Lisp is great. We've talked about that already and how it helps us think, but there are some constraints there. \n\nIf I had not moved into modern variants of Lisp, if I had just stuck with what I had, then it would have constrained the boundaries of my world. And I'd rather break down some of those walls and go explore places that I hadn't been, and maybe find places that I'd rather be. What do you all think? \n\nTAD: It's interesting because I actually was at lunch one time during a conference, and, Matz, the creator of the Ruby language, was at lunch with us. And we were talking with him, and he learns all sorts of languages all the time. I guess that makes sense. If you're the creator and a maintainer of a programming language, you want to scan what's out there and see if anything's interesting to incorporate into your language. \n\nBut for him, he learned languages that he wouldn't even consider including in Ruby, right? Like, he told us, \"I love every language. I just love learning languages. And I love every single programming language.\" And we kind of poked him on that a little bit. We're like, \"Well, do you love PHP?\" And he's like, \"Yeah, I love PHP,\" or like, uhhh, or a groan, or whatever. And we threw a bunch of languages at him, and he's like, \"Yeah, like, I just love to see what language designers are trying to do. I love to see what languages are about.\" And his take was every programming language offers something interesting for him. And so, that was a really interesting conversation. \n\nI don't love every language. But he's probably right. If you stop and think, what does the designer try to do? What is a problem set that this language is trying to accomplish, right? Then maybe that gives you another tool for your toolbox. I don't know Fortran, but I imagine if you're a scientist, Fortran is, like, an amazing language, right? You're like, oh man, this maps really well to my whole world, you know, like everything I need to do. I think I probably should be learning more languages because there's still a lot of new ideas coming out, right? And every language that you've learned shapes your thinking a little bit. \n\nYou look at Ruby, and then you can see, like, oh, Matz uses Emacs. So, he did a bunch of Elisp, and Ruby is heavily influenced by Lisp. And he did Perl programming, so Ruby is influenced by Perl. He loves object-oriented stuff, so Ruby is very Smalltalk-influenced and stuff like that. And you can see how, for him, he wanted something that made him happy. And he's like, these are some parts of other languages that make me happy. I'm going to instill them all into a single language, and that will be my ideal language. \n\nBut other people have other ideal languages. I think every language designer the language that they design is probably their preferred or, I mean, Rich Hickey loves Closure, right? Like, he thinks it's the ultimate best language. He is just sitting in his hammock thinking about Closure [laughs]. Like, he has a lot of stories of him just working out new ideas about his language, just sitting in the backyard. \n\nMIKE: You brought up a couple of interesting things. You said Matz loves PHP. The first time I used PHP, I loved it. Now, let me put some qualifications on this. I have actively avoided doing PHP professionally for a long time. But when I first used it, the very first time I used it, it fulfilled the need I had at that moment. \n\nIt provided me a template with some simple access to code so that I could put some control structures into the template; you know, I could loop a section, for example. And if you think about what it was good at and its purpose, you know, the reason it came into being, for people who are met with that need, that's an extremely useful language and has been widely used, you know, around the world for a long time.\n\nTAD: Did you ever generate HTML pages with C?\n\nMIKE: Oh.\n\nTAD: Or did you do any of the cgi-bin kind of stuff? \n\nMIKE: I have done it a little bit with C, and, boy, that's --\n\nTAD: Yeah, I did it, and it was absolutely awful [laughs]. It was the worst. And PHP was a breath of fresh air. \n\nMIKE: Exactly. \n\nTAD: Like, it was, you know, ten times faster to make a webpage with PHP than with C.\n\nMIKE: Absolutely. At least ten times, right? \n\nTAD: Oh, absolutely, yeah. \n\nMIKE: Maybe 100 or [laughs] more, depending on the specification of your page.\n\nTAD: You're like, oh, the string manipulation, ugh [laughs].\n\nMIKE: Yeah, and PHP maybe has a bad, you know, I said I've avoided it. Maybe it has a bad reputation for some of the security issues that it's had in the past. But, you know, I think they've mostly gotten around those. And they've got good modern frameworks, and you can get good work done in PHP. And understanding where it came from, you know, it's served that purpose well. And to your idea about building your own, a year or two ago, we built, as a group, during our Skills Clinic time when we were building our skills, we built some programming languages. And that was fun. \n\nTAD: Yeah, one of the crazy things is we decided...one of our languages we created was basically a text adventure as a language [laughs]. And it's not super useful, right? But it's, like, can I build a language around the idea of text adventures? And the answer is yes.\n\nMIKE: Yes, you can. \n\nTAD: It's weird. It's probably not the most efficient way to code something, you know, grabbing equipment and putting it in your backpack and moving things around into different rooms. And [laughs] I forgot Dave and I had a bunch of plans for it. But it's that kind of thing. There's still novelty out there. There's still new ideas that you can incorporate.\n\nMIKE: And we laugh about that language. You know, in early computing, you spoke computer language. You spoke, you know, machine language. You used to punch a card, and here's the zeros and ones. You know, you'd look things up in the processor and map. And you'd call those instructions directly, you know, you kind of mapped your mental model to those series of instructions. And that only scaled so far.\n\nIt wasn't very long before they came up with tools they wrote using machine language to be able to interpret something at a higher level, to take characters that looked more like English and map those to machine instructions. And they built Assembly language [laughs]. And in that many years writing in a language like that, they think, well, what if we could take that to its next level? What if we could take higher-level ideas and map them down to machine instructions? And so, you started getting compiled languages. \n\nAnd in the last, you know, really for a long time, it didn't take very long to get from compiled languages to interpreted languages. We've talked a lot about Lisp. And there's a lot of interpreted languages, like, we talked about JavaScript, and PHP, and Ruby, and Python that power a lot of the modern world. And it's a higher level of abstraction. But if you think about what happens next, what if you have tools like the large language models that are coming out? ChatGPT being a prominent example.\n\nWhat if we get to a situation where we're interacting with our computers in a little different way? And you can generate effectively, generate compiled, or interpreted programming languages. Well, what does the interface look like then? It's a lot different, right? \n\nTAD: Yeah. Is it a conversation interface? [laughs]\n\nMIKE: Exactly. But it's still an interface. And the ability to think methodically is going to be a valuable skill that I don't see going away, ever [chuckles], because being able to clearly communicate what you want to happen is valuable, whether you're using your punch cards or whether you're speaking to a conversational interface to build software that layers and layers and layers down. Those layers are just going to keep happening. Those layers are going to keep growing. And being able to think at a higher level, well, maybe I want to think in terms of [laughs] exploration of a text game. That might be really useful. \n\nI remember interacting with those [chuckles] years ago and wishing that their interface was a little more useful. Having a more useful interface that made a lot of sense could be a lot of fun. And maybe it could be a great thing, even embedded in another game. And I think we should be thinking about those and shouldn't be too surprised when we have conversational languages that come up in the near future.\n\nTAD: Well, another thing is, a lot of these languages answer, like, what-if questions, right? You're saying, what if my programming was backed by a large language model? But most of these languages are like, Lua is like, well, what if everything was tables [laughs], right? And Forth is like, what if everything was stacks? Or you got, like, you know, and Haskell is like, what if everything were functional? I'm curious: what are the what-ifs that you think are going to be questions for programming languages in the future?\n\nMIKE: You're thinking about the large language models. There's a grounding problem that's long existed in machine learning, which is you can train something in a simulation, but your simulation doesn't really match reality. And it's really hard to take software that you've trained in a very sterile, controlled environment and make it work properly in the real world, which is messy. I think that a really interesting question is, what if the real world existed? How do you deal with that? And how can we build interfaces that interact with the real world in effective ways without destroying our hardware? \n\nYou know, you got a robot or robot defined broadly, you know, I've got a self-driving car, for example. And the self-driving cars today they are these bespoke software. Some of the most effective companies...well, I think all of the companies effectively doing self-driving cars software, there's certainly machine learning that goes in there because they learn to see and interpret their environment. But there's also a lot of heuristics that they have to use [laughs]. You know, where are you on the map? And so, you end up with this really kind of messy model. \n\nAnd I don't know exactly what this programming language would look like. But thinking about the kinds of problems that we're getting to with some of these large language models, with a higher level interface, we might start thinking about and, you know, other things that have happened in computing that allow us to understand the world in better ways. I think that we're going to maybe think at a higher level of abstraction to say, well, I want to build web pages. What if I could tell a computer to do anything? What would I tell it to do? And what kind of constraints would I run into? \n\nSo, you're thinking about stacks. Well, you know, with some of the advances in computing, I might be able to say, \"Hey, build me an app that will do such and such,\" and it can give it to you quickly. So, you have to think at a higher level, well, what kinds of apps do I want to build, right? [laughs] You get into that higher level of thinking, well, what is a business need that I need to solve? \n\nOr, if you think about robotics, what is a real-world situation that I might need to deal with? You know, do I need to deal with a hazardous environment so I can do clean up? Or do I need to deal with sweeping minefields and removing mines after a war? You know, what are some of those constraints? And then we start thinking about, well, what are the real-world problems that I'd run into? \n\nI'm kind of jumping out ahead. But thinking about this idea of having an interface that's more conversational, I think you start thinking about your problem domain more. You know, what if the world is made out of programs that are written for you? I think that you still have problem domains you have to deal with. That was my take.\n\nTAD: One thing that I am curious about is we see so many languages out there with so many different attributes. I wonder if you could create domain-specific languages. You can just say like, \"Okay, here is my industry; here's my domain; here's my needs. Generate a language with all the features that would work well in this domain.\" I mean, I alluded to it a little bit. Like, Fortran is, obviously, very specific to, like, you know, science and mathematics. And COBOL was specific to, like, business needs and things like that. \n\nWhat if the language itself became a little more abstract? Where you're just saying, like, you generate a language. You give me a language that would be ideal for driving a car, right? And then, give me a standard library for that language for driving a car. And then, I will use that standard library as I develop the software. I mean -- \n\nMIKE: That's a fascinating idea. \n\nTAD: Is there a reason why we couldn't get there soon? I don't know if that would be beneficial, but... \n\nMIKE: Well, why not? Every profession has its lingo, right? \n\nTAD: Oh yeah. \n\nMIKE: It's things that they do. You know, why not? If we already have systems that can build software, and a programming language is just a kind of software, I mean, that's something that could be perfected, maybe not perfected, but, you know, but greatly improved. Build me a language that has these attributes for this business domain or even outside of business for this fun domain, right? [chuckles] \n\nTAD: Yeah. \n\nMIKE: I can describe the instructions, you know, build a language that will let my kids interact with their game of choice and do cool things in it. That sounds like a really valuable idea. \n\nTAD: Yeah, I've got several Amazon Echos in my house, right? My daughter is like, \"Hey, read me a book. And hey, do these things for me already.\" I don't even think to do this, but for her, it's part of her world. When she wakes up in the morning, she says, \"What time is it? What's the weather today?\" Like, those are the first two things she asks, my little eight-year-old kid. She's like, \"Oh, cool.\" And then she picks her clothes based on what the weather is going to be like and whatever. \n\nBut what if it was like, hey, help me build controls for the TV or something like that? And give me a language that an eight-year-old could understand that could control some of the appliances in my house. And then, it would just say, like, \"Okay, here. [laughs] Here you go.\" I don't know; that seems possible in the near future.\n\nMIKE: Yeah. Ramses, where do you think the programming languages are going following our thoughts? Do you have anything you'd like to add to that? \n\nRAMSES: Yeah, I think it is interesting, and it seems like there certainly is a kind of a culture shift with how we interface with just technology in general. I'm really interested to see how that sort of [inaudible 38:31] in the next few years\n\nMIKE: Well, and to kind of tie this all together, it will be fascinating to see how it shakes out. But in all of this, we're going to have to interact still, right? We're going to have to interact with these machines if we want to use them. And to do that, you have to learn how to talk to them [chuckles]. It's a learned skill. Regardless of all of the layers that are underneath, there's still a learned skill in getting better at communicating with the machines, which means you have to keep learning. You have to actively seek out and be learning new ways of thinking about the problem and learning those languages.\n\nIn my mind, it is pretty definitive. It was maybe going into the conversation, but it's only reinforced my belief that learning languages improves your ability to think about the world and improves your ability to get things done, and that's not going to change. Even as we develop more powerful interfaces, that's still not going to change. \n\nRAMSES: One thing I'm curious about is the cadence in which we might learn a new language. You know, you'd probably learn it just maybe once a year or once every couple of years, depending on how maybe complex a language is or your rate of absorption in the language. But sometimes, it seems like it might be out of necessity. You might work at a place that adopts a new tool, so you have to learn it if you don't already know it.\n\nMIKE: It's interesting because early in my career, career and studies, there was probably a five-year period where I learned between 10 and 20 languages, to some degree, not perfectly all of them. But I remember doing an accounting, and I think it was somewhere between 10 and 20 over five years, which is generously more than one language a year. And I think it was closer to the 20 category. Again, not every language learned well because there was a lot of stuff being thrown at me at the time. I was working on a lot of different things, so I had to learn a lot of different languages. And I think that was really useful. It helped me see a lot of things in a different way. \n\nBut then I became more of a specialist, and I think that's a natural progression in a career is you specialize. Even in medicine, for example, you know, there's a lot of generalist learning you do. And then, in the end, you specialize and focus on a particular area. And I think that's a natural progression in software is that you kind of need to specialize if you want to get good at one thing. Because if you're a generalist in everything, you're not going to be as good in all of them. \n\nSo, learning a lot when you're starting and then focusing, I think, makes a lot of sense. But then, the cadence afterward, I would still argue that you should probably be...I'm thinking at a cadence of maybe once every few years, you know, between one and five, you should be learning something new because, eventually, that specialization might peter out. There's value in having a specialization, but some of those specializations lose their utility over time.\n\nTAD: I've learned a ton of languages, but I don't know that all of them were useful.\n\nMIKE: Would you say at this stage of your career...you've been doing this for decades.\n\nTAD: Wow. I've probably been a developer for 20 years or so. \n\nMIKE: Yeah. What cadence do you think makes sense for you to be learning now? I mean, would you just learn a new language if you had to switch jobs? Would you argue for continually learning new languages so that you're ready for the next thing? \n\nTAD: Yeah, I think there's probably two different arguments there. Because you probably want to learn things that are relevant for the job market, right? Like, you don't want to be the guy that's still coding COBOL, or maybe you do. I mean, there's still a ton of old systems that still need COBOL programmers and stuff like that. So, there's, like, the financial, like, job thing. \n\nBut then there's just, like, the personal betterment, like, personal enrichment aspect to it, and, for me, it's a matter of time and a matter of novelty. Like, if I have the time and if I encounter a language that's different than anything I've seen before, I'd look into it. I'd probably learn it. But I see some new languages, but it pretty much covers all the same things I've seen in languages that I already know. I'm just kind of like, eh. \n\nThat's probably the biggest reason why I haven't learned Python is because Ruby kind of scratches that itch for me or fills that niche. It's an object-oriented, interpreted language that's multi-paradigm and has some cool features, right? And so, I'm like, uh, maybe I'd learn Python if I needed to do some data stuff or if I had some need. But I probably won't learn Python just because I wouldn't learn anything radically new from it.\n\nMIKE: Sounds like a good checklist [laughs]. Does it help me learn something new? Does it provide utility?\n\nTAD: Yeah. And so, that's why you probably learn a lot more when you're new and younger than when you're old like us when you're like, I got, like, 20 languages under my belt. 21? Eh, right? Maybe you're a little more discerning.\n\nMIKE: Like we've been talking about, there may be some new things coming in computing that would mean that number 21 is going to be really valuable [laughs]. Well, I'm looking forward to seeing what that language 21 is. I'd like to see a language called 21 [laughs] that meets those needs. There's probably one out there [laughs] I haven't found. \n\nBut, you know, this has been a great discussion. I really like some of the thought-provoking questions that we haven't had answers to, recognizing there's a lot out there yet to learn, and that will still be happening in computing. I'm excited. With that, we'll catch you next time on the Acima Development Podcast.","content_html":"The panelists explore the value of learning new programming languages. The conversation begins with personal stories about their first programming experiences, discussing languages like Logo and BASIC and, later, more complex ones such as Java, Pascal, C, C++, Perl, PHP, Haskell, and Python. They emphasize how each language forces a developer to think differently about problems, highlighting the significant role of learning various languages in a developer's growth. They also touch on the practicalities and peculiarities of different languages, like the ease of PHP compared to C for web development and the sophistication of memory management in languages like Java and Rust.
\n\nThe discussion then pivots to the core question of the podcast: the value of methodically learning new programming languages. Mike shares his perspective, noting that while he hasn't learned a new language every year, the variety he has learned has been crucial for his career development. Tad recounts an insightful conversation with Matz, the creator of Ruby, about the joy and utility of learning diverse languages, even those with limited professional application. This leads to a broader discussion about how each language, with its unique approach to solving problems, can add valuable tools to a developer's toolbox.
\n\nIn the final part of their conversation, they delve into the future of programming languages and discuss the potential of domain-specific languages tailored to particular industries or needs and the role of emerging technologies in shaping how we interact with technology. Mike speculates about conversational interfaces and their implications for future software development, emphasizing the importance of adapting to new ways of thinking and interacting with machines. They end with an affirmation of the continuous need for learning in the ever-evolving field of software development, underscoring that learning new languages enhances problem-solving skills and prepares developers for future technological advances.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm going to be hosting today. And together with me, we have Ramses and Tad. Today, we're going to be talking about learning new programming languages, specifically what value you get from learning them. And beyond that [chuckles], not just learning them because you're forced to, but deliberately going out and learning languages regularly, you know, once a year or some cadence like that. And why would you do that sort of thing? That's the premise we're going to start with.
\n\nAnd before we really dive into the conversation, Tad, before we jumped into the recording, said, you know, a good place to start here is talking about the first language you learned. Like, yeah, you know, actually, that's a great idea. And thinking back to childhood, the first programming language I learned was Logo. They called it the turtle, but I think it's really just a triangle. And you [chuckles] make it go around the screen, and it leaves a trail behind it. And you could use it to draw pictures.
\n\nI didn't have a computer at home at the time, and I'd used it at school. And I thought it was just the coolest thing ever. I believe that it usually ran in a real-time mode, where it was interpreting what you put in. It was actually pretty sophisticated for back in that time. The read–eval–print loop is, you know, very common now in interpreted languages, but back then, that was pretty sophisticated.
\n\nMy understanding is that Logo is a variant of Lisp. I didn't know I was learning Lisp. I was just learning how to move the turtle around. I thought it was the coolest. And I do remember that I could go back into a screen where you could actually write some code, rather than running in that real-time evaluation loop, and then have it draw cool patterns on the screen, and I thought that was just the best [laughs].
\n\nI remember thinking it was so cool, but then you had to have shared computer time with everybody else in the grade. It might have even been shared with everybody else in the school. So [chuckles], I didn't get a whole lot of time on the computer. And I didn't really pursue programming that much other than thinking that it was cool. Sometime after that, I couldn't say exactly when, but I think I had friends that introduced me to the BASIC programming language.
\n\nBASIC has a very different take on things. The lines are numbered. You always had to put numbers, and you developed a habit of incrementing by at least 10. You'd do line 10, line 20, and line 30. So, in case you ever needed to insert anything in between, you didn't have to renumber every line. I've had to do that [laughs] in BASIC, to go back and renumber everything. When my family first got a computer, it came with a BASIC interpreter. And we had a book, and I went through, and I did a lot of BASIC programming. And I did. I'd fill up all my spaces; then I'd have to go renumber everything.
\n\nThe thing, though, about switching out of the languages, I learned about BASIC-supported subroutines, they called them. They had GOTO, so you just bounced around just at random [laughs]. If you wanted to be able to have any ordered thing at all, you would develop...it wasn't a function like you'd think about in more modern programming languages but the same idea what they called a subroutine where you could go to this region of code that would execute independently.
\n\nTAD: GOSUB [crosstalk 03:09] GOTO.
\n\nMIKE: Exactly. GOSUB [laughs]. I think you could even treat them as function calls and pass variables to them. Do you remember Tad?
\n\nTAD: You couldn't with the BASIC I learned. There might have been BASIC variants that could do that.
\n\nMIKE: Yeah. It seemed like they could maybe have return values. There was something that distinguished them from a GOTO. And then I did a lot of that when I was in my early teens. And the next programming language I learned was probably Pascal in school, and asked to learn Java, and C, and C++. And professionally, your first job, you usually end up picking up a language because you end up having to do stuff you haven't done before. I learned Perl and then did a lot of Java, PHP, web languages back in the day. But I ended up touching a lot of things. There was ColdFusion [laughs].
\n\nTAD: Oh gosh.
\n\nMIKE: Yeah. And then later, as I moved along in my career, there were actually some languages I learned just to learn, and I think I'm going to come back to that. But Haskell, specifically, is one that I deliberately chose to learn, and I'm glad that I did. I've learned Python somewhat in recent years, which has been a useful tool.
\n\nThe interesting thing about this, I'd mentioned the subroutines [laughs], is that every one of these languages forced me to think about problems differently because these languages represent a way of thinking. They approach a problem in a slightly different way. There's a lot of overlap between them. Once you've learned one, it's a lot easier to pick up another. But making that switch between languages really forces you to recognize that maybe there's more than one way to think about a problem. And then you're forced to evaluate, well, which way do I want to think about the problem? And that switch between frames of thinking, I think, has been very useful.
\n\nI would strongly recommend that people take the time to learn other languages, especially languages that are very different than what you're used to. I think it's useful to learn Assembly language, for example, maybe not in-depth, but at least to understand how it works so you can think about how a processor works. I recommend learning a functional language. I've mentioned Haskell. It's a pure functional language that really forces you to think in a certain, very mathematical way, and it helps you approach certain problems differently.
\n\nAnd you should probably learn an interpreted language if you've been a compiled language person all the time and so on, approaching problems differently. So, there's my limited introduction. I'm saying this history of languages I've learned has helped me a lot, and I'd recommend others to do the same. Now, Tad, you've been talking a little bit. What's been your history with programming languages?
\n\nTAD: My first programming language was BASIC, which is probably really common for anybody who grew up in the '80s like I did. My parents bought the family an old computer. Texas Instruments used to have a computer that they sold that you could plug into your TV. It was called the TI-99. And if you put a cartridge in, then you could play that cartridge. But when it booted up, there was always a menu.
\n\nNumber one was it dropped you into a BASIC shell thing, or number two was play the game. And so, after you've been using this computer for a while, you're like, huh, I wonder what that, like, number one option is, right? And it just basically just dropped you into BASIC. And, like you were saying, it came with a manual that gave you the basics of BASIC. It was, like, line numbers, and you'd always do 10. You're like, ten prints, you're awesome, 20 GOTO 10. And you're like, ah, like, you show your sister like, "Oh, look, our computer thinks I'm awesome," or whatever.
\n\nBut yeah, like, that was just being able to have something to show up on the screen. It gave you BASIC syntax, you know, control structures like ifs and thens and all that stuff. If this, go to there; if else, go to this, that kind of thing. That was what I thought programming was all about was just big, long, BASIC programs.
\n\nAnd I remember later in the '80s, Macintosh Classics became pretty ubiquitous at, like, high schools or just different schools and stuff. They all came with HyperCard, which had a programming language behind it called HyperTalk. And I remember trying to look through the mail trying to figure it out because I looked at the examples, and they didn't have any line numbers. And I couldn't conceive of programming without line numbers. I was like, how do you go to something if you don't go to a line number? Like, how do you use your GOTOs if you don't have line numbers, right? And so, that was kind of an eye-opening idea that, wait a second, I don't need GOTOs at all? How does that even work, right?
\n\nMIKE: [laughs]
\n\nTAD: And HyperTalk was really interesting because it was very English-like. And the idea was you basically have a stack of cards. Each of those cards, you could put different buttons and different like UI elements on that card. And then, you could have those UI elements; each of them have some code behind them. And then you could swap between the cards and things like that.
\n\nAnd so, the very first thing that you could do was make a stack of cards and do a different picture on each card, and then your program would just be, show all cards. And that would just flip through all the cards and create a little animation for you, right? And just the fact that it was English and you could say, "Show all cards," and that was just intuitive, right? And was just kind of mind-blowing. You could set the speed that it shows all the cards. And so, something like that where it was very English-like, very intuitive.
\n\nBut it was also evented. So, you could write little handlers. Like, you could say, "On mouse up," and then you would write the body of the things you want to do when the mouse is clicked, or whatever, or on button clicks and things like that. And so, it kind of put me into a mode of looking at things from, like, a UI perspective and event perspective, you know, messaging back and forth between the different elements and stuff. And so, that was a huge departure for me from BASIC.
\n\nAnd then probably the third language I learned was C, which, again, is very different because it's the first time I ever had a compiled language. It's the first time I really thought hard about functional programming, probably the first time I ever encountered libraries and shared libraries. Because I'd have to yell pound, include standard io at the beginning, right? You don't just get that for free. You have to, like, ask for io stuff. You have to set up a main function. You have to do those sorts of things. So yeah, that was also a very different language from the first two I learned as well. So, anyway, yeah, like, it's all very interesting to learn.
\n\nMIKE: You talked about HyperTalk changing your perspective because you thought, oh, things don't have to be this procedure where you control the flow yourself. The language can do some of that for you.
\n\nTAD: Right. Yeah.
\n\nMIKE: And teaching you about libraries. I mean, those are major concepts, right?
\n\nTAD: Yeah. I mean, my simple BASIC interpreter didn't have libraries. HyperCard just had everything built in. You didn't, like, grab things from external sources. I think you could, but I had no idea of what that was or what it meant.
\n\nMIKE: So, you know, there was that step, the step between this in a progression. Sounds somewhat similar to the things I did, I have learned over time. So, Ramses, I'll ask you, I don't know how many languages that you have worked with.
\n\nRAMSES: Certainly not as many as you or Tad, I'm sure [laughs]. Probably started with Lua, I want to say. Like –-
\n\nTAD: Oh, nice, yeah.
\n\nMIKE: Embedded development.
\n\nRAMSES: Yeah, it was great.
\n\nTAD: A lot of kids are, like, Roblox and stuff when they start learning Lua.
\n\nRAMSES: Yeah, it's a pretty good platform for that. It teaches a lot of the basics and gets you familiar with a lot of the core concepts of programming and, you know, communicating between client and server and back. And my primary, of course, is Ruby, mainly Ruby on Rails. I do have experience with JavaScript. I'm currently learning Java, and I have tinkered a little bit with Elixir, not enough to be proficient.
\n\nMIKE: Well, let me ask you a follow-up question. Maybe I should ask about Elixir because it stands out among those as being distinctly different. But there's, I mean, there are differences between those languages. What's something that surprised you or helped you progress from one of these languages, Ramses?
\n\nRAMSES: Mostly curiosity, I would say. That's the biggest driver for why even try to approach something different.
\n\nMIKE: Absolutely. Curiosity kind of drives the learning. What is something you've discovered in a language that made you think, oh, well, that's different?
\n\nRAMSES: Well, I don't know if this is the biggest one, but I thought the pipeline operator in Elixir was very interesting.
\n\nMIKE: I was talking with some people about that this morning [laughs], just this morning, comparing that with an attempt to do that in a language that didn't support it. That didn't work out so well. That pipeline idea of having a series of steps that you can break out on it's a great idea, right?
\n\nRAMSES: Yeah.
\n\nMIKE: Once you see it, you know, like, you can't unsee it [chuckles]. Like, wow, that's a good way to approach a problem. And, Tad, you've mentioned a couple of things that were enlightening to you [laughs], the epiphany. Are there any others that have really stood out to you?
\n\nTAD: I did a bit of Closure for a while. Ruby is Lispy, but it's not Lisp, right? Ruby has certainly stolen a ton of Lisp ideas, but it's not, like, that pure. I see a bunch of parenths on my screen. Everything is nested parenths Lisp. And they also have, like, a kind of a threading operator—I think that's what they call it—that kind of pipes things through. And I mean, with C, you get pretty functional. But Lisp is probably the grandpa. I'd say it's probably the purest, most influential functional language there is.
\n\nSo, once you get into that mindset of, oh, everything is data, everything is streaming data and transforming data, it's interesting how you start to see every problem of, oh, how could I just make this as a series of pieces in my pipeline and my data is just going to flow through them all, right? And you realize, oh, this is very predictable. This is very easy to test. And it's really interesting to get put into that kind of functional programming mindset.
\n\nMIKE: I can say you're noticing a similar idea of these pipelines.
\n\nTAD: Yeah.
\n\nMIKE: There was a moment for me...I could talk about a different language, but, actually, it was, I think, a comment I read in a book I was reading that said, "Well, if you think about SQL and how it does things, that's basically the way that functional languages do things." Like, wait, what? I've thought deeply about that since. SQL or SQL, some people call it, sometimes it stands for some things, sometimes it doesn't [chuckles]. The language used for creating databases.
\n\nIt's this widely used language that is completely declarative. There are, like, variants on it that allow you to do some procedural stuff where you can have loops and so on. But out of the box, you can declare the kind of transformations you can run on the data you start with to get a set of data out. And you might think, well, what good is that? What good does that do? All you can do is transform data. I mean, does it do things? And yet, it manages to be kind of the foundation of a lot of what the web is built on, right?
\n\nWe have databases. We have data storage. And somehow, you need to present that to your users, and in between, you need to transform it. And I don't know if I want to say we overthink our value, but I don't think that's quite true. I think I would rephrase it differently that sometimes we don't recognize how valuable it is to be able to take some source data, run some transformations on it, and display it to somebody.
\n\nYou think of even a social network, pick your social network. Somebody who's listening to this 20 years from now they'll go, "Huh, they were using those?" [laughs] But what's the biggest one today? It's probably Facebook. You know, they collect vast amounts of data on people, maybe scary amounts of data [chuckles] on people. And then, they compile that together and present it to you. And it's really data transformation. And they start with some source data, they mix it with some rules, and they show it to you. And they've managed to build this massive company. It's one of the top five most valuable companies on Earth. It's what they do.
\n\nOr you look at, say, Google, that has powered the, you know, web for four decades now. They store a bunch of information about their web crawls, and they show you that data [chuckles] after they've, you know, stored it and indexed it. The ability to efficiently store information and efficiently take that information and somehow transform it into a useful format to read because, you know, the whole web out there is not very useful to me because it's too much. I can't find anything in it.
\n\nBut if you can save that in a way that's well indexed and can be returned to me in a sorted form with the most relevant things up front, well, that's exceptionally valuable to me, you know. It has made them vast sums of money because it was incredibly valuable. Advertisers have spent a huge amount of money on these platforms because people use it because it improves our lives.
\n\nSo, this transformation of data, this idea that you start with some data, you run some transformations on it, and you get data out on the other side that's in a more useful form, I think is fundamental to most of what we do in software development. And once you think about that that way...and both Ramses and Tad talked about this kind of pipeline idea, that you start and you go through these series of transformations, and you get something out the other side. It's been transformative to me.
\n\nI think I mentioned I studied Haskell a few years ago, a functional language. Everything's built around that idea. And internalizing that idea, of course, not just from Haskell but from other resources, I think has been very influential on me as a developer, and some of the best code I write is rooted in those ideas.
\n\nTAD: What's a language that's on your radar right now?
\n\nRAMSES: I know Python is kind of the new hot [inaudible 17:49]. It's been the hottest for a while.
\n\nMIKE: Yeah, the old hotness [laughs].
\n\nRAMSES: The old stuff. I mean, there's --
\n\nTAD: Since the '90s.
\n\nRAMSES: Yeah, it's kind of a big one currently; probably would like to learn it more at some point. But, my current focus is Java.
\n\nMIKE: If you know Ruby, switching over to Python is almost trivial, not completely. They're slightly different, but they have very similar paradigms. My language, I would say, Julia.
\n\nTAD: Oooh. For data stuff, huh?
\n\nMIKE: Yeah, I've been interested in data for quite a while. And I am really interested in machine learning. And a lot of machine learning world is using Python. That's mostly what I've done with Python. But Python is not known for being efficient [laughs]. There's people working on that. There's people working on that, I'll say. I'll give them credit for that.
\n\nBut there are, you know, lots of different tactics people have taken to try to deal with them; one of those is to create a new language, and Julia is one of those. And that's one that I've been interested in trying out. You know, I don't know that I'd use it on a day-to-day basis, but I'd like to see that approach to the world. What about you, Tad?
\n\nTAD: I remember when Swift came out, they gave you a free book like, Apple says, "Here's a book on Swift," when it first came out. And I've always thought that Swift looks really interesting. It's obviously a language that has drawn on a bunch of other languages and looked pretty clean.
\n\nAnd some of the interesting things that I liked about it that I'd like to see in other languages are optional typing because I don't love forced typing. But I think typing can be useful sometimes, right? And so, I'd like to steal the idea of optional typing from a language like Swift and then give it to maybe a language like Ruby, right? Because Ruby is all dynamically typed. But I'm like, uh, sometimes I'd like to have types.
\n\nI've had some Elixir books for a while. They do some really interesting things, especially with their matching, where it's basically make this side match that side. The destructuring that you see kind of popping up in other languages has largely been inspired by Elixir and its ability to just really nicely destructure things, right?
\n\nMIKE: Yep. That pattern matching has been a thing in functional languages for a while, and it's cool.
\n\nTAD: Yeah. I think Elixir really took it to the next level. I don't know of other languages that did it. Well, I'm sure Erlang does just because what's under the hood of Elixir [inaudible 20:27]. Elixir put a nice, approachable veneer over that whole beam, the whole ecosystem there.
\n\nWhat other languages are interesting? I like Lua. I learned a little bit of Lua with my kids. I think it's like a better JavaScript. I wish that they would have discovered Lua, and we would have had that instead. Rust has been on my radar for a while, but I just don't have any use for it in anything I do day to day.
\n\nYou know, just speaking about how languages change your thinking, I did a ton of C in college. And then, when I got to some of the upper-level classes, we started doing Java and stuff like that. And I was like, oh wait, what? You don't have to do memory management? There's a garbage collector? Wait, what's going on? Like, the fact that I could basically run my Java programs cross-platform-ish, you know, on the JVM for whatever operating system I was on.
\n\nAnd Java, you can kind of fake it where you could put pointers to different references...I forgot. I haven't done Java in a while. But you could mix and match an array, and you could stick different objects in an array if you just made your array object references. I was like, wait, I'm getting tricky, right? But yeah, the fact that Java had different memory handling was really interesting to me. And Rust, I think even more so, the fact that you can get the performance of, like, a compiled language with memory safety, and you don't have to hand that off to a garbage collector, is really interesting, I think.
\n\nI've seen the argument or the joke: you're just moving all that stuff from the compiler into your head, where you just have to think real hard to do your memory management instead of letting your compiler or your language do it. But yeah, so there are still languages coming out that have interesting ideas that I'd like to explore.
\n\nMIKE: I think that provides a good pivot to what kind of our central theme was that we wanted to talk about in this podcast. We've talked about some value we've gotten from languages. What's the value in methodically going out and learning them? Is this something people should do, and if so, how often and why? And maybe a split question: what happens if you don't? [laughs]
\n\nI will say I have not specifically made a point of learning a new language every year. But if you add up all of the languages that I've learned, I'm probably not too far away from it because there are a lot of languages out there, especially if you count non-procedural languages, you'll get HTML, CSS, SQL, even, like, Regular Expressions. There's a lot of languages that we learn as developers, and if you start adding all the languages up, it can add up to quite a few. And I think I'm not too far from one a year.
\n\nI would say that if I hadn't done that, I would not be in a good spot. If I'd stuck with Perl, I'd be an aging guy still doing Perl [laughs]. And Perl's not a bad language, don't get me wrong. But professional opportunities are rather limited nowadays in that language [laughs]. And it has a lot of interesting ideas. Perl is actually a fascinating language where they've experimented with some things, kind of tried to push the boundaries. It's Larry Wall, right?
\n\nTAD: Yeah.
\n\nMIKE: That built the language. He studies languages professionally. He really thinks about interesting things you can do with language. So, great language. I'm not saying something bad about Perl. But if I was just doing Perl, or if I was just doing Logo that I learned in elementary school, again, it's a Lisp variant. Lisp is great. We've talked about that already and how it helps us think, but there are some constraints there.
\n\nIf I had not moved into modern variants of Lisp, if I had just stuck with what I had, then it would have constrained the boundaries of my world. And I'd rather break down some of those walls and go explore places that I hadn't been, and maybe find places that I'd rather be. What do you all think?
\n\nTAD: It's interesting because I actually was at lunch one time during a conference, and, Matz, the creator of the Ruby language, was at lunch with us. And we were talking with him, and he learns all sorts of languages all the time. I guess that makes sense. If you're the creator and a maintainer of a programming language, you want to scan what's out there and see if anything's interesting to incorporate into your language.
\n\nBut for him, he learned languages that he wouldn't even consider including in Ruby, right? Like, he told us, "I love every language. I just love learning languages. And I love every single programming language." And we kind of poked him on that a little bit. We're like, "Well, do you love PHP?" And he's like, "Yeah, I love PHP," or like, uhhh, or a groan, or whatever. And we threw a bunch of languages at him, and he's like, "Yeah, like, I just love to see what language designers are trying to do. I love to see what languages are about." And his take was every programming language offers something interesting for him. And so, that was a really interesting conversation.
\n\nI don't love every language. But he's probably right. If you stop and think, what does the designer try to do? What is a problem set that this language is trying to accomplish, right? Then maybe that gives you another tool for your toolbox. I don't know Fortran, but I imagine if you're a scientist, Fortran is, like, an amazing language, right? You're like, oh man, this maps really well to my whole world, you know, like everything I need to do. I think I probably should be learning more languages because there's still a lot of new ideas coming out, right? And every language that you've learned shapes your thinking a little bit.
\n\nYou look at Ruby, and then you can see, like, oh, Matz uses Emacs. So, he did a bunch of Elisp, and Ruby is heavily influenced by Lisp. And he did Perl programming, so Ruby is influenced by Perl. He loves object-oriented stuff, so Ruby is very Smalltalk-influenced and stuff like that. And you can see how, for him, he wanted something that made him happy. And he's like, these are some parts of other languages that make me happy. I'm going to instill them all into a single language, and that will be my ideal language.
\n\nBut other people have other ideal languages. I think every language designer the language that they design is probably their preferred or, I mean, Rich Hickey loves Closure, right? Like, he thinks it's the ultimate best language. He is just sitting in his hammock thinking about Closure [laughs]. Like, he has a lot of stories of him just working out new ideas about his language, just sitting in the backyard.
\n\nMIKE: You brought up a couple of interesting things. You said Matz loves PHP. The first time I used PHP, I loved it. Now, let me put some qualifications on this. I have actively avoided doing PHP professionally for a long time. But when I first used it, the very first time I used it, it fulfilled the need I had at that moment.
\n\nIt provided me a template with some simple access to code so that I could put some control structures into the template; you know, I could loop a section, for example. And if you think about what it was good at and its purpose, you know, the reason it came into being, for people who are met with that need, that's an extremely useful language and has been widely used, you know, around the world for a long time.
\n\nTAD: Did you ever generate HTML pages with C?
\n\nMIKE: Oh.
\n\nTAD: Or did you do any of the cgi-bin kind of stuff?
\n\nMIKE: I have done it a little bit with C, and, boy, that's --
\n\nTAD: Yeah, I did it, and it was absolutely awful [laughs]. It was the worst. And PHP was a breath of fresh air.
\n\nMIKE: Exactly.
\n\nTAD: Like, it was, you know, ten times faster to make a webpage with PHP than with C.
\n\nMIKE: Absolutely. At least ten times, right?
\n\nTAD: Oh, absolutely, yeah.
\n\nMIKE: Maybe 100 or [laughs] more, depending on the specification of your page.
\n\nTAD: You're like, oh, the string manipulation, ugh [laughs].
\n\nMIKE: Yeah, and PHP maybe has a bad, you know, I said I've avoided it. Maybe it has a bad reputation for some of the security issues that it's had in the past. But, you know, I think they've mostly gotten around those. And they've got good modern frameworks, and you can get good work done in PHP. And understanding where it came from, you know, it's served that purpose well. And to your idea about building your own, a year or two ago, we built, as a group, during our Skills Clinic time when we were building our skills, we built some programming languages. And that was fun.
\n\nTAD: Yeah, one of the crazy things is we decided...one of our languages we created was basically a text adventure as a language [laughs]. And it's not super useful, right? But it's, like, can I build a language around the idea of text adventures? And the answer is yes.
\n\nMIKE: Yes, you can.
\n\nTAD: It's weird. It's probably not the most efficient way to code something, you know, grabbing equipment and putting it in your backpack and moving things around into different rooms. And [laughs] I forgot Dave and I had a bunch of plans for it. But it's that kind of thing. There's still novelty out there. There's still new ideas that you can incorporate.
\n\nMIKE: And we laugh about that language. You know, in early computing, you spoke computer language. You spoke, you know, machine language. You used to punch a card, and here's the zeros and ones. You know, you'd look things up in the processor and map. And you'd call those instructions directly, you know, you kind of mapped your mental model to those series of instructions. And that only scaled so far.
\n\nIt wasn't very long before they came up with tools they wrote using machine language to be able to interpret something at a higher level, to take characters that looked more like English and map those to machine instructions. And they built Assembly language [laughs]. And in that many years writing in a language like that, they think, well, what if we could take that to its next level? What if we could take higher-level ideas and map them down to machine instructions? And so, you started getting compiled languages.
\n\nAnd in the last, you know, really for a long time, it didn't take very long to get from compiled languages to interpreted languages. We've talked a lot about Lisp. And there's a lot of interpreted languages, like, we talked about JavaScript, and PHP, and Ruby, and Python that power a lot of the modern world. And it's a higher level of abstraction. But if you think about what happens next, what if you have tools like the large language models that are coming out? ChatGPT being a prominent example.
\n\nWhat if we get to a situation where we're interacting with our computers in a little different way? And you can generate effectively, generate compiled, or interpreted programming languages. Well, what does the interface look like then? It's a lot different, right?
\n\nTAD: Yeah. Is it a conversation interface? [laughs]
\n\nMIKE: Exactly. But it's still an interface. And the ability to think methodically is going to be a valuable skill that I don't see going away, ever [chuckles], because being able to clearly communicate what you want to happen is valuable, whether you're using your punch cards or whether you're speaking to a conversational interface to build software that layers and layers and layers down. Those layers are just going to keep happening. Those layers are going to keep growing. And being able to think at a higher level, well, maybe I want to think in terms of [laughs] exploration of a text game. That might be really useful.
\n\nI remember interacting with those [chuckles] years ago and wishing that their interface was a little more useful. Having a more useful interface that made a lot of sense could be a lot of fun. And maybe it could be a great thing, even embedded in another game. And I think we should be thinking about those and shouldn't be too surprised when we have conversational languages that come up in the near future.
\n\nTAD: Well, another thing is, a lot of these languages answer, like, what-if questions, right? You're saying, what if my programming was backed by a large language model? But most of these languages are like, Lua is like, well, what if everything was tables [laughs], right? And Forth is like, what if everything was stacks? Or you got, like, you know, and Haskell is like, what if everything were functional? I'm curious: what are the what-ifs that you think are going to be questions for programming languages in the future?
\n\nMIKE: You're thinking about the large language models. There's a grounding problem that's long existed in machine learning, which is you can train something in a simulation, but your simulation doesn't really match reality. And it's really hard to take software that you've trained in a very sterile, controlled environment and make it work properly in the real world, which is messy. I think that a really interesting question is, what if the real world existed? How do you deal with that? And how can we build interfaces that interact with the real world in effective ways without destroying our hardware?
\n\nYou know, you got a robot or robot defined broadly, you know, I've got a self-driving car, for example. And the self-driving cars today they are these bespoke software. Some of the most effective companies...well, I think all of the companies effectively doing self-driving cars software, there's certainly machine learning that goes in there because they learn to see and interpret their environment. But there's also a lot of heuristics that they have to use [laughs]. You know, where are you on the map? And so, you end up with this really kind of messy model.
\n\nAnd I don't know exactly what this programming language would look like. But thinking about the kinds of problems that we're getting to with some of these large language models, with a higher level interface, we might start thinking about and, you know, other things that have happened in computing that allow us to understand the world in better ways. I think that we're going to maybe think at a higher level of abstraction to say, well, I want to build web pages. What if I could tell a computer to do anything? What would I tell it to do? And what kind of constraints would I run into?
\n\nSo, you're thinking about stacks. Well, you know, with some of the advances in computing, I might be able to say, "Hey, build me an app that will do such and such," and it can give it to you quickly. So, you have to think at a higher level, well, what kinds of apps do I want to build, right? [laughs] You get into that higher level of thinking, well, what is a business need that I need to solve?
\n\nOr, if you think about robotics, what is a real-world situation that I might need to deal with? You know, do I need to deal with a hazardous environment so I can do clean up? Or do I need to deal with sweeping minefields and removing mines after a war? You know, what are some of those constraints? And then we start thinking about, well, what are the real-world problems that I'd run into?
\n\nI'm kind of jumping out ahead. But thinking about this idea of having an interface that's more conversational, I think you start thinking about your problem domain more. You know, what if the world is made out of programs that are written for you? I think that you still have problem domains you have to deal with. That was my take.
\n\nTAD: One thing that I am curious about is we see so many languages out there with so many different attributes. I wonder if you could create domain-specific languages. You can just say like, "Okay, here is my industry; here's my domain; here's my needs. Generate a language with all the features that would work well in this domain." I mean, I alluded to it a little bit. Like, Fortran is, obviously, very specific to, like, you know, science and mathematics. And COBOL was specific to, like, business needs and things like that.
\n\nWhat if the language itself became a little more abstract? Where you're just saying, like, you generate a language. You give me a language that would be ideal for driving a car, right? And then, give me a standard library for that language for driving a car. And then, I will use that standard library as I develop the software. I mean --
\n\nMIKE: That's a fascinating idea.
\n\nTAD: Is there a reason why we couldn't get there soon? I don't know if that would be beneficial, but...
\n\nMIKE: Well, why not? Every profession has its lingo, right?
\n\nTAD: Oh yeah.
\n\nMIKE: It's things that they do. You know, why not? If we already have systems that can build software, and a programming language is just a kind of software, I mean, that's something that could be perfected, maybe not perfected, but, you know, but greatly improved. Build me a language that has these attributes for this business domain or even outside of business for this fun domain, right? [chuckles]
\n\nTAD: Yeah.
\n\nMIKE: I can describe the instructions, you know, build a language that will let my kids interact with their game of choice and do cool things in it. That sounds like a really valuable idea.
\n\nTAD: Yeah, I've got several Amazon Echos in my house, right? My daughter is like, "Hey, read me a book. And hey, do these things for me already." I don't even think to do this, but for her, it's part of her world. When she wakes up in the morning, she says, "What time is it? What's the weather today?" Like, those are the first two things she asks, my little eight-year-old kid. She's like, "Oh, cool." And then she picks her clothes based on what the weather is going to be like and whatever.
\n\nBut what if it was like, hey, help me build controls for the TV or something like that? And give me a language that an eight-year-old could understand that could control some of the appliances in my house. And then, it would just say, like, "Okay, here. [laughs] Here you go." I don't know; that seems possible in the near future.
\n\nMIKE: Yeah. Ramses, where do you think the programming languages are going following our thoughts? Do you have anything you'd like to add to that?
\n\nRAMSES: Yeah, I think it is interesting, and it seems like there certainly is a kind of a culture shift with how we interface with just technology in general. I'm really interested to see how that sort of [inaudible 38:31] in the next few years
\n\nMIKE: Well, and to kind of tie this all together, it will be fascinating to see how it shakes out. But in all of this, we're going to have to interact still, right? We're going to have to interact with these machines if we want to use them. And to do that, you have to learn how to talk to them [chuckles]. It's a learned skill. Regardless of all of the layers that are underneath, there's still a learned skill in getting better at communicating with the machines, which means you have to keep learning. You have to actively seek out and be learning new ways of thinking about the problem and learning those languages.
\n\nIn my mind, it is pretty definitive. It was maybe going into the conversation, but it's only reinforced my belief that learning languages improves your ability to think about the world and improves your ability to get things done, and that's not going to change. Even as we develop more powerful interfaces, that's still not going to change.
\n\nRAMSES: One thing I'm curious about is the cadence in which we might learn a new language. You know, you'd probably learn it just maybe once a year or once every couple of years, depending on how maybe complex a language is or your rate of absorption in the language. But sometimes, it seems like it might be out of necessity. You might work at a place that adopts a new tool, so you have to learn it if you don't already know it.
\n\nMIKE: It's interesting because early in my career, career and studies, there was probably a five-year period where I learned between 10 and 20 languages, to some degree, not perfectly all of them. But I remember doing an accounting, and I think it was somewhere between 10 and 20 over five years, which is generously more than one language a year. And I think it was closer to the 20 category. Again, not every language learned well because there was a lot of stuff being thrown at me at the time. I was working on a lot of different things, so I had to learn a lot of different languages. And I think that was really useful. It helped me see a lot of things in a different way.
\n\nBut then I became more of a specialist, and I think that's a natural progression in a career is you specialize. Even in medicine, for example, you know, there's a lot of generalist learning you do. And then, in the end, you specialize and focus on a particular area. And I think that's a natural progression in software is that you kind of need to specialize if you want to get good at one thing. Because if you're a generalist in everything, you're not going to be as good in all of them.
\n\nSo, learning a lot when you're starting and then focusing, I think, makes a lot of sense. But then, the cadence afterward, I would still argue that you should probably be...I'm thinking at a cadence of maybe once every few years, you know, between one and five, you should be learning something new because, eventually, that specialization might peter out. There's value in having a specialization, but some of those specializations lose their utility over time.
\n\nTAD: I've learned a ton of languages, but I don't know that all of them were useful.
\n\nMIKE: Would you say at this stage of your career...you've been doing this for decades.
\n\nTAD: Wow. I've probably been a developer for 20 years or so.
\n\nMIKE: Yeah. What cadence do you think makes sense for you to be learning now? I mean, would you just learn a new language if you had to switch jobs? Would you argue for continually learning new languages so that you're ready for the next thing?
\n\nTAD: Yeah, I think there's probably two different arguments there. Because you probably want to learn things that are relevant for the job market, right? Like, you don't want to be the guy that's still coding COBOL, or maybe you do. I mean, there's still a ton of old systems that still need COBOL programmers and stuff like that. So, there's, like, the financial, like, job thing.
\n\nBut then there's just, like, the personal betterment, like, personal enrichment aspect to it, and, for me, it's a matter of time and a matter of novelty. Like, if I have the time and if I encounter a language that's different than anything I've seen before, I'd look into it. I'd probably learn it. But I see some new languages, but it pretty much covers all the same things I've seen in languages that I already know. I'm just kind of like, eh.
\n\nThat's probably the biggest reason why I haven't learned Python is because Ruby kind of scratches that itch for me or fills that niche. It's an object-oriented, interpreted language that's multi-paradigm and has some cool features, right? And so, I'm like, uh, maybe I'd learn Python if I needed to do some data stuff or if I had some need. But I probably won't learn Python just because I wouldn't learn anything radically new from it.
\n\nMIKE: Sounds like a good checklist [laughs]. Does it help me learn something new? Does it provide utility?
\n\nTAD: Yeah. And so, that's why you probably learn a lot more when you're new and younger than when you're old like us when you're like, I got, like, 20 languages under my belt. 21? Eh, right? Maybe you're a little more discerning.
\n\nMIKE: Like we've been talking about, there may be some new things coming in computing that would mean that number 21 is going to be really valuable [laughs]. Well, I'm looking forward to seeing what that language 21 is. I'd like to see a language called 21 [laughs] that meets those needs. There's probably one out there [laughs] I haven't found.
\n\nBut, you know, this has been a great discussion. I really like some of the thought-provoking questions that we haven't had answers to, recognizing there's a lot out there yet to learn, and that will still be happening in computing. I'm excited. With that, we'll catch you next time on the Acima Development Podcast.
","summary":"","date_published":"2023-12-06T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/3ade316e-c9e1-4ac5-b412-6460896f1d82.mp3","mime_type":"audio/mpeg","size_in_bytes":49428293,"duration_in_seconds":2646}]},{"id":"9eba5757-2a6b-4e7b-95aa-4a66c26cffba","title":"Episode 33: How Does Modern AI Work?","url":"https://acima-development.fireside.fm/33","content_text":"The panel dissects the world of machine learning and artificial intelligence. They unravel how machine learning algorithms function, using the game of Pac-Man to break down complex topics like reinforcement learning and reward-based systems. Mike dives deeper into reinforcement learning, explaining how it operates on reward signals that assess the value of a series of actions over time. Dave chimes in with his insights on AI's ethical considerations, arguing that lacking a moral framework could lead to unintended and potentially harmful outcomes.\n\nThey navigate the expansive \"state space\" concept in machine learning, using chess as an illustrative example, and explore how understanding all possible board states and moves can help develop an unbeatable chess AI agent. This sets the stage for a pivot to natural language processing, where Taylor provides a thorough explanation of transformer architectures, including sequence-to-sequence problems and attention mechanisms. \n\nDave returns to his earlier point about ethical considerations, spotlighting the importance of the paper \"Attention Is All You Need,\" which has been instrumental in developing transformer models. He then shifts to the challenge of making AI systems more explainable. While Taylor and Mike acknowledge that the complexity of neural networks makes them difficult to interpret, Dave insists that striving for explainability is crucial to making AI more accountable and transparent.\n\nTranscript:\n\nMIKE: Hello, and welcome to another episode of the Acima Development podcast. I'm Mike. I'm going to be hosting today. And we have a panel with us here today of Dave, and Taylor, and Francisco. Welcome, everybody. Interesting topic we're going through today. And we're going to approach it a little bit differently than we've sometimes done in the past. We're going to be talking about the fundamentals of machine learning. \n\nTaylor is with us from data science. So, he does this for a living day in and day out.\n\nTAYLOR: Yep.\n\nMIKE: And has the smarts here to talk about it. I am very interested in this topic. I have been for a long time [laughs], honestly, since I probably heard about it as a kid [laughs]. So, this has been a long-standing interest of mine. And I've played around with this. I follow the topic closely, but I am not a professional practitioner. So, hopefully, that'll qualify me to at least give you an overview. And we're going to lean on Taylor [laughs] to be the expert. \n\nUsually, we have a heavy panel discussion. We do have a panel here today to have a discussion. They will maybe be doing more question-answering and filling in the blanks. The goal here...I was talking about this in our pre-call discussion that I'd like somebody who listens today to walk away and say, \"You know, I have a basic idea of how this works. I might not be able to implement it, but it's not magic, you know, it's not this dark magic. It's just somehow these machines can think.\" But you have an idea of how this might work. \n\nI wanted to start by telling a story. Grounding things in real-world stories is usually very helpful to help us conceive of how things work. The story is about a hike I took a number of years ago. And I couldn't tell you what year it was. It was a long time ago. A friend of mine and I decided to go hiking up in the mountains, and we hiked several miles up a trail. And I really wanted to try something different. My buddy had not done a lot of hiking. So, my ambition was probably bigger than it should have been. Chris, if you ever listen to this, I'm sorry. \n\nAnd we decided to go on this hike. And I wanted to try a new route that I'd never been on before because I knew that there were trails and two parallel canyons. And we were going on a canyon that was not that deep up high up on the ridge line. And there was a canyon parallel to the one we were in that was much lower, hundreds of feet down, hundreds of meters for anyone not in the United States, at least 100 meters, right? It was a long way down into this parallel Canyon. And I wanted to see if we could find a route between these two canyons in an area that was trailless. \n\nIt was late spring. I thought, oh, this would be great. The weather's nice. So, we went up. We hiked up the one canyon, got up to the high spot, saw what was an easy place to drop over into the next canyon. And we went over the edge. And it turns out that there was still late spring snow, like, all the way down that canyon wall down through the woods that were there [laughs], and decided to do it anyway. \n\nBut it was smooshy snow. It was, like, up past our knees. So, we were just postholing, you know, stepping into it. You jump down in up above your knees with every step going down this hill. And it was hard work. We were just absolutely exhausted. We did, however, eventually find the trail that we were looking for. And the way we got there was really very simple. I knew that it was down, and I went that way. We had to walk down through the woods, you know, I didn't have a compass. I didn't really have a map of the area. This was kind of pre-smartphone era. This was a long time ago. \n\nBut I did know how to make my way down. And I knew the trail was at the bottom of this canyon. So, what I did was I just walked down. Now, there were certainly obstacles along the way. Again, it was forested. There was a lot of trees to weave our way through. But for the most part, that was obscured by the snow; we just had to, at every point, say, well, which way is down? And take a step in that direction. \n\nAnd when we finally got down to the bottom, there was the trail. And [laughs] we were finally free of the snow. It was wonderful. We got out of the snow, and not much further was the trail. And then things were much better, and we walked down and made our way back, you know, to the car, which was a bit of a walk because we had to go between canyons. Again, Chris, I'm sorry. But we did find out that there was a way. \n\nWhy am I telling this story? It's because you might think that machine learning is based on something really sophisticated and complex, but it's actually a lot simpler than you might think. And the basic math that it uses is something that you probably learned in either junior high or high school. So, think back about your math. And if you're not a math person, think about this mountain I'm talking about, or think about a road that you have to drive that's got a hill. \n\nAnd there's really only a couple of things that define that hill. First of all, how steep is it? [laughs] Like, it matters how steep it is, and that's kind of a direction. And where's your starting point? Like, if you're starting most of the way up the hill, then you don't have very far to go, right? If you're starting at the bottom of the hill, there's a long way up. So, there's kind of two parameters that define that hill, which is how steep it is and your starting point. Now, I'm simplifying some here. \n\nBut in the math that you may have learned way back when and try to remember, you may have learned something like y equals mx plus b, which sounds really mathy, but that's really trying to tell you something simple. It's telling you that you have some input, and you're going to multiply by that and then add a number. Well, and that's still not very practical. \n\nThe second example I'd like to give is one I usually think about, and there's a few that we could think about. But the one I usually think about is, and that I've seen a lot online, is, let's say, that you want to predict how much a house is going to cost. You want to predict how much a house is going to cost. And you only have one piece of information to predict that, and it's the size of the property it's on. And there's probably a pattern there, right? \n\nI would imagine that if you're on a tiny city lot, the value is probably going to be lower than on a large city lot. If you've got a house on a large city lot, that's probably a pretty valuable house because city lots are expensive. And there's going to be a lot of noise in that data, though, because that tiny city lot is probably worth a lot more than a tiny country lot. And, you know, maybe it's in a neighborhood where not many people want to live. How close is it to public transportation? I'm going to get back to that minute. \n\nThere's all of these other things that you could measure. But we're just going to think about one thing, the size in... we'll say in square meters or square feet. I'm in the United States; I'll say square feet. I know that [inaudible 06:07] allows a unit. Meters are better [laughs]. But it's what is commonly used in the United States. So, you know the square footage of your lot. And you want it to have that one number and predict what the price of a house will be. \n\nNow, let's say you're doing it within the city. Well, there's some simple math you could do there. Here's what I'm going to propose you do: you take the size of that lot in square feet, and you have a number, we'll say 1,000. That's a very small size, but I'm going to use a small number. You can say that 1,000, and you will multiply it by a number, by some weight we'll call it. And you'll get another number that you say that's the price of the house. But you're going to add one other thing, and that is, where does it start? Because there may be a floor to how low the prices will go. \n\nIt may be even if you have a square-foot lot, it's worth something. It's still worth something more than zero. So, you've got a starting point that's higher than zero. Or maybe you're in, like, Detroit after they went bankrupt, and some property values are worth less than zero, right? [laughs] The city will pay you to take them [laughs]. Either way, there's a starting point that may be above zero. It might even be below zero that the zero, you know, the property with no size would still be worth. And then you go up from there.\n\nAnd I'm going to call that value...I didn't give it a name. They call it in the machine learning world the bias. They call it the bias. That's the starting point. And the other one, that multiplier you use, is usually called the weight. There's another name you can call it, though, on a line you often heard in math: slope. It's the slope. If you want to get fancy and you think about the steepness of the road that I mentioned before, they call that the grade. \n\nAnd in math, if you're thinking about a complex grade where it's in multiple dimensions, they call that the gradient. They call that the gradient. But it's really just a fancy name for the slope, you know, how steep is it? And so I got two numbers: the weight, which is the steepness, and the bias. Where's your starting point? So, I'm going to look at Taylor here. So, you with me, Taylor? What gaps do you think I have left so far? \n\nTAYLOR: No, I think you're doing pretty well. I mean, that's why we call the y equals mx plus B slope form. It's describing lines and their slope and how they traverse through [inaudible 08:21] space. When you were talking about traversing from different trails––last time, obviously, you're talking about gradient descent here.\n\nMIKE: And I'm going to get there in a minute [laughs].\n\nTAYLOR: Yeah. And one of our co-workers had a sticker that he gave when he left, and it was a ski resort called Gradient Descent or, like, Gradient Slopes or something like that. \n\nMIKE: [laughs].\n\nTAYLOR: I thought that was a really cool sticker. It's a fun play on words. But no, I think you're doing a great job of explaining these concepts so far. I could interject with a lot of, like, data science terms for these. But I think for explaining to a junior high student, then we're spot on.\n\nMIKE: Well, excellent. And you're like, what does this have to do with machine learning? You're talking about the stuff I learned back in junior high. \n\nTAYLOR: [laughs]\n\nMIKE: Well, and here's where the next step is that we really get to magic. I'm going to go back to this idea of houses; then, I'm going to use this to tie things together. If you have ten houses that you want to do this with, and you say, well, here's the property values, and here's the houses, you could draw a picture, right? \n\nYou could say, well, this house has a property size of 30,000 square feet, and this one has a property size of 50,000 square feet. And then, you draw a picture, you know, mapping your...on one axis...so, you just draw a line, and then, as you go higher along, you're going to put the size of the property. The higher the property size, it goes higher on the line. And then, along the other axis, you're going to put the price of the house. \n\nAnd if you kind of map those, you're going to see them following a pattern where it goes up into the right, assuming that the higher values go to the right. And you could draw a line through that and probably eyeball it and get a pretty good number to say, hey, here's the line that I'm going to use to fit to that data, you know, that you got that line of best fit. There's a fancy, mathy word for a line, for things referring to lines. They say linear because it has the word line in it with an E-R at the end, a linear, or an A-R at the end. You know, it's liner. A line you can use to map the data. \n\nAnd it's probably not a perfect fit, right? But lines are pretty simple to use. And one thing about line is they've only got really two characteristics that you care about, which is how steep is it? And what's the starting point? There's starting to be a pattern here. How steep is it, and what's the starting point? Which you can use with that y equals mx plus b. You can use those two numbers. All that is...I can go back. Well, the two numbers that you care about is how steep it is, which is the same thing, as we said before, as that weight. The number that you're going to multiply by the size of your property and that bias sort of, you know, where does your line start? \n\nBut what if you have a million? What if you have a million houses? Well, you're probably not going to do that by hand. It's going to take you a long time. Even with the size of a million modern computers, you could probably figure out an exact line of best fit. But as you get to increasingly large datasets, it becomes less and less tractable. \n\nHere's what gets even worse. What if those other data points that I mentioned are also into play? What if you also want to involve the proximity to public transportation? What about the neighborhood that it's in, and you want to treat that as a data point? What about how urban or rural or, you know, which urban area that it's in? You know, what about the age of the home? What about the company who built the home? There's all kinds of things that you can measure.\n\nWe're often used to thinking about things we can measure as being in our world around us and tend to mention Cartesian coordinates. We often think about, well, how far is it in front of me? How far is it to either side of me? How far is it up and down? So, we've got these three things we can measure: in front of me, to the side, and up, and we call those dimensions. But that word dimension just means things I can measure. So, I could also measure the distance from public transportation. I could measure the distance from the city center. I can measure in kind of a categorical sense categories of, you know, what these neighborhoods are. There's many things that I can measure. \n\nAnd dimension is just something I can measure. Well, I could probably measure hundreds of things. And that's really hard to picture drawing [chuckles] when I've got hundreds of things. And for all of those hundreds of things, I want to find a best fit that kind of maps all of them in some complex multi-dimensional space. Well, that sounds really awful. \n\nBut the concept is very simple. I just want to have a weight for every one of them and a bias for every one of them. And then, I multiply those all together and, add it together, and get a number out of the other end. Well, that sounds like something I could do, although I don't know how to do it on paper. And if I've got a huge number of things coming in, I might not even be able to do it easily on a computer. But there is something I can do. \n\nHere's where the learning part comes in: the moment of magic. What if I do my math...and I'm going to go back to the example of just one, and I'm just going to draw a line completely random, no thought going into it whatsoever. None at all. I'm going to draw a random line. And then, I'm going to take my first house, and I'm going to figure out, like, some exact numbers. Like, what do I have to multiply the property size by to get to the size of that house? And that will give me a number for my weight that's different from the one I have because the one I have is totally random. I mean, the chance those are exactly the same is basically zero. They're different. \n\nAnd I'm going to take my number that I guessed at random, and I'm going to move it a little bit, not much, just a little bit toward the value I got for the house. Remember, these weights can also be called the slope or, in a fancy word, the gradient. So, I'm going to move my gradient a little bit more toward the one that that house would suggest it ought to be. And then, I'm going to do it again with the next house on my list. And then again, and then again, a million times, or a billion times. \n\nAnd if you think about what's going to happen to that gradient, sometimes it's going to go the wrong way because we have some rundown mansion that's actually not worth very much [laughs] and some little place that's actually really fancy. It skews it the other way. But if I keep on doing that a million times, just moving a little bit each time, there's going to be a little bit of bounce around, thinking about following that gradient, following that slope towards the right one. Over time, I'm going to follow that difference, right? The difference between the slope values until I get something really close.\n\nThink about me walking down that hill on that mountain. I didn't always go exactly towards the trail, I guarantee that. Sometimes, I was going around trees. Sometimes, I probably went uphill to dodge an obstacle, but as long as I was going in the direction of the trail, changing my position a little bit each time going in the right direction. And if I'm not being very watchful, maybe I'm going to pass it [chuckles] and then have to come back to that direction. But then I'm going to come back downhill the other way because I go back up the canyon on the other side and wave until I get down to that trail, which happens to be right at the bottom. And there's a fancy name for that: gradient descent. \n\nBut all that that really is...and you think that, oh no, it's got to be more complicated than that. Well, actually, no, it's not. Because simple things are how you solve really ugly problems a lot of times, that is really what machine learning practitioners have been doing for a long time is: they thought, well, okay, well, let's take a simple approach to this problem. Let's take my input data and, multiply it by some weights, add some biases. \n\nAnd I'm just going to start with some random weights and biases. And now I'm going to adjust them a little bit with a batch of data, and then a little bit more and a little bit more and a little bit more. And I'm just going to do this a whole bunch of times. And if I do that enough times with enough data—and it helps to have a lot of data—I'm eventually going to get some pretty good weights and biases, right? It's actually going to be pretty good. And this is not a new idea. There is something called the perceptron, which followed this pattern, and it was invented in 1943. \n\nTAYLOR: Wow.\n\nMIKE: That does just this. Back then, computers were feeble enough compared with today's. They actually originally designed it in software, but they built hardware for it. They built hardware that would do this, and they thought this will change the world. This learning will change the world. Well, they didn't have very much data. And they didn't have, you know, a very big machine. So, it didn't really change the world that much. But it was able to learn from a set of data. Remember, this is 1943. \n\nTAYLOR: That's amazing.\n\nMIKE: And these ideas have been bouncing around since then, and people probably thought of that. This idea of linear approximation or linear regression, which is trying to find that line of best fit, has been around for a long time. Well, in the 1990s, some mathematicians started working more on this. One guy, particularly named Yann LeCun, and the team...he is a professor...a team of his started working on that. And they explored some of these ideas. Another important person here is named Geoffrey Hinton.\n\nThey kept thinking that this idea of using these weights and biases to solve the problem and making a whole network of them was going to be really useful. And at the time, you know, back in the '90s, there were actually a lot of people who thought it wouldn't work. Because they thought, well, that's too simple, you know, our brain really has these concepts of things. And we need to come up with relationships with things and make large databases of things. And that's how we'll really solve the problem.\n\nThe problem with that is you have a lot of different things. You've got a lot of different relationships [inaudible 17:04] them. It's just too hard to map out. The work involved in that is mind-boggling. And how do you do kind of fuzzy relationships between things? The whole thing just falls apart. It's just impossible to build that database, practically. \n\nBut there were a couple of really important things that happened between the '90s and the year...and I'm going to say, specifically, the year 2012. And here's the couple of things that happened. First, well, the internet. People started posting things online, which meant we ended up with vast amounts of data, huge amounts of data points that we could start doing stuff with. And the other thing that happened is maybe a little bit unexpected, which is the rise of computer gaming. And computer gamers really, really love to have good graphics. They want to have beautiful graphics that are very immersive. \n\nAnd so, like, what does all this data and these graphics cards have to do with things? Well, first of all, it's really hard to learn something if you don't have very many examples to learn from. And in the older era, the only way you could get a bunch of examples of things is kind of find them for yourself and write them down, and that's just impractical to do as a single team. But by the early 2000s, there were teams that started scraping the internet, and you could get a million images. \n\nWell, now you got a whole bunch of data. What can we do with this data to learn about it? And second thing with the gaming is that gamers, in order to have these good graphics, they use graphics cards, which is a specific, like, little computer in your computer. So, it's a dedicated processor that's really, really good at doing linear algebra. It's really good at doing this line math that we've been talking about. Well, they do that so they can navigate the way that light passes through space. But that also happens to just match really well anytime you want to find a line of best fit for things.\n\nTAYLOR: Light moves in straight lines. That's why that matches.\n\nMIKE: So, some researchers started to use those graphics cards to start crunching a whole bunch of this linear algebra to say, what if I take a whole bunch of data, start running through these graphics cards using these old techniques that have been around since the 1940s? And really, they go back farther than that, and these predate computers for the linear regression. But, the idea of using gradient descent with a computer to do it has been around since the 1940s. What if we start applying these ideas we already knew to some of the input data? \n\nAnd they start with a lot of input data because an image, you think it has a lot of pixels in there. But really, those are all just a whole bunch of data points. We talked about a lot of dimensions. Well, each of those pixels just has a brightness, right? And some position, you know, it's like an X and a Y position. It's got a position on the screen, and it's got some brightness. Well, those are just data points. Those are just dimensions. \n\nNow, if we throw all of those many, many dimensions into some of these little classifiers I told about where we just add a whole bunch of weights and biases that we picked at random, and then we adjust it and say, \"This image you throw all of these numbers, and then that is a cat,\" this other big set of numbers and say, \"That's not a cat; it's a dog.\" Well, you know, that's something that's just almost impossible to think about doing as a person. But the graphics card it does that all day, every day. And the combination of the two was amazingly effective. \n\nAnd I've mentioned 2012 because, in 2012, the team of Geoffrey Hinton built an image recognition network, as they called it, that followed this process. And there's a couple of little tweaks that I haven't mentioned, which is that they did something a little tricky. Rather than predicting immediately with just one set of weights and biases, Elvis is a cat; they dumped the output of those weights and biases, so those numbers that come out of there into another set of weights and biases. Like, wait, what? What does that even mean? \n\nSo, you put another set of weights and biases in between and then another set, several layers of these linear approximaters, and then they get now put out of it. Well, that's kind of weird, right? I mean, why would you put layers? Because what does that even mean on the in-between?\n\nIt turns out that that allows something magical to happen [laughs]. I'm going to keep using this word magic because it feels like it when it finally works. Is that these in-between layers start not predicting directly the price of the house; they start predicting something maybe more sophisticated. Like, based on this input data, I'd maybe have some prediction about the value of the roof. Even if you didn't have that directly, they start learning that concept because you can see, like, how new it is, maybe something...the color of the roof. They start to learn these concepts. Go ahead, Dave.\n\nDAVE: Right. Is this, like, literally, like, you're like, okay, this is a point six hectare, you know, acre lot. It's going to be a $180,000 house, and you're going to need to take the lead out of the paint because...right?\n\nMIKE: So, that lead may never be explicitly specified. But some of these intermediate layers because they don't have to directly predict the price of the house; they can predict something in between. And remember, they're just starting with random initialization. So, maybe one of them actually started out pretty good at predicting the lead just by random chance. And by keeping with that and getting even closer to this lead idea, somewhere in between these layers, it was able to improve the predictions of the network as a whole. And so, it sticks with it. \n\nAnd with images, you can actually look at what comes out of these intermediate layers when they do this. And you see things like some of them recognize lines, some of them recognize circles. You know, they start recognizing interesting characteristics of the image that are not cat, but they might be important for cat, something like eyes, for example. Or circles lead to eyes [chuckles], which lead to face, which leads to, oh, cat. And just by throwing numbers at it and adjusting your gradients each time. \n\nNow, there's a problem here. It's hard to directly adjust your gradient when you have multiple layers. And here's where I'm going to get a little bit more math-y. And this was some of the trick that some of the researchers figured out. I think it was particularly in the '90s but then in the 2000s. And this trick is...it comes from calculus. And this is where I'm going to get math-y for a second. \n\nIf you've ever done calculus, there's something called the chain rule, which is that if you want to find the derivative, which is another fancy word because mathematicians have, like, ten fancy words for the same idea of this slope. And it's a little more sophisticated because they can find it, you know, it's more than a line. But the idea is another idea of this slope. \n\nAnd if you want to find the slope of some complex curve that has a bunch of things happening to it, there's a rule you can actually use to work back from the final one to the first one. Well, if each of these layers in the network is just applying some lines, some weight, and a bias, well, we know how to find slope from that. And so we can work backwards through the layers using that calculus chain rule. If you know calculus, if you're interested in that, they call that backpropagation. And that was the trick they learned for training this thing when it got more and more layers. And adding those layers really ended up allowing this magic to happen. \n\nSo, in 2012, they made a network called AlexNet that absolutely clobbered a competition for image detection. And people are like, \"Oh wow, I wasn't expecting that [chuckles]. We're onto something.\" And it's approximately decades since things have gone on. So, Taylor.\n\nTAYLOR: Yeah, I was just going to mention that there are standard datasets used to analyze these models. So, if you ever have a great idea on how to like, detect images, and classify images, you can test them on these standard sets of images and produce research using those. And I'm sure they're different today, but I'm sure you can still find the dataset that that was trained on and see how newer models perform on it.\n\nMIKE: It is. It's called ImageNet, and they still use it a lot in training. And ImageNet happened because some professors...I think it was Fei-Fei Li. Is that her name? I think she's at Stanford. And her team got together a whole bunch of images off the internet and came up with a classification competition. And then the graphics cards gave us the power to do a whole bunch of line math of linear algebra, put them together, and out of it comes something that we never had before: the ability for machines to very effectively recognize images. And that really has kind of sparked the progress toward modern artificial intelligence and machine learning. \n\nAnd after that, you know, things started happening like Siri and Alexa, you know, name your smart assistant that can understand language. Well, underneath, they were using these same kinds of linear classifiers built into a network called a deep because there's more than one layer, a deep neural network. And it works. There's a couple of other things that I wanted to throw out there to kind of complete the story. But I'm going to pause here for a minute. \n\nBut I think we should have a little bit of discussion because we've covered the most important parts, which is you start with just trying to find some multiplier for your input, for your input dimension, your input value that will give you the output value you wanted. And you adjust it a little bit each time with your incoming data, and then you just pump a whole bunch of data at it. And that idea is the idea, and it's not a new idea. \n\nBut if you have the computers that can handle it and you have the data, you can throw at it with a whole bunch of values, right? A million images is a whole lot more than five. And today's datasets are absolutely enormous. With some of the text datasets, you have, like, a trillion data points that you...a trillion...I say data points, a trillion examples maybe you'll throw. \n\nSo, there's just huge amounts of data that they can throw at really big networks that are big enough to learn a lot of these little nuances, and that's it. But the math behind it is actually not that scary in the small scale. It really is just finding that line. Now I'm going to be quiet for a bit because I've talked a lot. Like I said, this one's going to be a little bit different because I wanted to lay out these ideas. \n\nDave said he was going to approach this more as the, hey, tell me more, and Taylor is more of the field expert. Well, there's a couple of things that I want to visit. For example, I have not talked about gradient-boosted trees, which applies the same idea to decision trees. There's other ways they apply this gradient idea to something that's also pretty simple but is a little bit different. \n\nAnd I haven't yet talked about transformers and about what might go in between these layers where you do something to get something that's a little bit more than a line. But those are all just tweaks to this core idea. So, Dave, I'm going to look at you first. What are your thoughts?\n\nDAVE: I am just falling all over myself to preemptively yield the floor to Taylor.\n\nMIKE: [laughs]\n\nDAVE: Because I have lots of ideas and lots of questions, but the actual implementation details of machine learning is something so far outside my ken that this is just fantastic. I'm really, really, really digging this.\n\nTAYLOR: Yeah, I honestly deal a lot more with, I guess, the implementation details of machine learning, like in the day-to-day here at Acima. Oftentimes, that is far more important than the training of a model. Handling data in production and, assembling that data, and making successful predictions is very difficult, and doing it correctly at scale is even more difficult. But, Mike, I really liked how you're describing neural networks. They are inspired by the human brain, and that's where the neural part comes from.\n\nSo, it's a really interesting abstraction of how humans learn. And that when we're born, we're sort of initialized with a really basic [chuckles] neural architecture that the weights really aren't well defined, like, outside of our instincts. And as we grow, we really start to develop more neural pathways, and we strengthen those neural pathways. We correct those neural pathways. And over time, we optimize them so we can be, I guess, contributing members of society and successful humans.\n\nBut, like, when I'm learning, I conceptualize it in that way as well. Like, you have to take an integrative approach. If you do things more than once, it's going to take a while to get those weights to where you want them to be and to get them optimized, so, yeah, we take the same approach with machine learning. \n\nBut really contextualizing the problem is a lot more difficult when it comes to machine learning. It's really had to define all your input variables, and you have to structure everything very well, very consistently. You have to be very organized. I think, as humans, we kind of take that for granted. It kind of happens just almost subliminally. Like, we don't have to worry about categorizing data and storing it [inaudible 29:12]\n\nMIKE: Because we've been building our model since we were born [laughs]. It feels like common sense because we have been practicing it.\n\nTAYLOR: Yeah. So, when we're training these machine learning models, we have to be, like, very diligent and very specific. And if you're not careful, you're going to teach the model something that you didn't intend to because you didn't contextualize the problem correctly. And in machine learning, we say that the model is not going to generalize if the data you gave it isn't like the data it's going to see. So, that's yeah; it's just a fundamental part to training machine learning is getting that dataset correct such that it mimics the real world, it mimics what the model is actually going to be predicting on. \n\nAnd we spend a ton of time here at Acima making sure that's the case. Because if you train a model and you think it's doing well, and your accuracy metrics are where you want them to be, but when you deploy, it performs totally different, like, that model is not successful at all. It might have done well in training, but it doesn't do anything for us if it doesn't do that same thing in production. And stuff like that's happened before, and that's when you have to debug and figure out where that dataset was corrupted or queried the wrong way.\n\nMIKE: What you're saying there, it's hard to emphasize this point enough. I'm going to go back to the thought that this perceptron was named in 1943. But we didn't have this big AI explosion until after 2012. And remember, there are two halves to that: first one was getting the computers that could handle it, and the other one was getting the data and [laughs] everything Taylor is talking about here. That work of getting a good dataset was what it took 70 years to get together.\n\nTAYLOR: Yes, it truly is the culmination of several different domains, like, really just getting to the point where they can mesh and do things really well. I think a lot of what we consider machine learning is just classical statistics, and it's been in use for decades at this point. We joke about the term AI in our department, and we think it's kind of funny because it's kind of just a buzzword. And artificial intelligence often isn't that intelligent. Like you said, they're fairly basic concepts that are playing out. \n\nThese newer forms of large language models are closer to what I would consider AI and more of the Sci-Fi stuff. We're still not there yet. But yeah, classical machine learning has been around for quite a while. We've had actuaries for a long time, and statistical methods have been used to underwrite risk for decades.\n\nMIKE: I remember as a kid, a good friend of mine, his dad was a statistician, and I thought, wow, that sounds so boring. And I wanted to go into other areas of science. It turns out now, like, I work with that kind of thing for a living, and it's so cool [laughs]. And he went into other areas of science. We kind of swapped roles. But it's been around for a long time. We've just gotten better tools for applying it. \n\nAnd I want to say kind of repeatedly that the basic ideas here...if you've been scared, like, I want to learn this, but, man, that sounds too complicated, but they use a lot of fancy symbols and stuff in the papers and sometimes, you know, it takes a while to wrap your head around. But the ideas here, at their fundamental, like the basics of what's going on in machine learning, are not that complex. It's mostly these weights and biases.\n\nTAYLOR: Yeah. To add to your point earlier on, like, actually implementing these, the great thing about all these machine learning algorithms is that they're packaged really well, especially in Python. You'll see almost zero math notation when you're training a machine learning model, other than how you choose to define your variables and methods. But it's incredibly easy to sit down and get started with machine learning. There's tons of datasets online that you can play around with. And there's standards that people have come to, prediction standards on those datasets. So, you can get an idea of if you're doing something completely wrong or you're hitting the nail on the head. \n\nBut yeah, they're fairly easy to implement. We actually use a hosted solution to train and deploy all of our machine-learning models; it's DataRobot if you guys are familiar. And there's dozens of machine learning algorithms packaged up in there. It handles all your training data and iterates through different training methods, and we do some work to select the best models in there and deploy them there. \n\nBut tools like that are great, and, like, now is the best time to get into machine learning and artificial intelligence because there truly is just so much material out there to learn, just countless hours of Khan Academy or YouTube videos. Yeah, if you're looking to get into machine learning, you shouldn't be too scared. \n\nI'm trained as a computer scientist. So, I don't have, like, a specific data science degree or even a math degree like some of the co-workers here at Acima. But, I was able to make the transition into data science because it really is just computer science mixed with statistics and mathematics, and I've really enjoyed it. And it's one of my favorite domains of computer science if not my favorite.\n\nMIKE: You know, unless you are inventing some addition to kind of the toolset used in these models, you probably are not going to be doing a lot of math because you're not going to be inventing your own architecture of layers and such because people have already built that. And you can get it pre-packaged. You just should have some understanding of what's going on under the hood.\n\nTAYLOR: Yeah, you can get yourself into trouble if you don't understand the underlying fundamentals. Machine learning models are very finicky. And, like I said earlier, if you feed them wrong data, they're going to learn the wrong thing, and they're not going to perform well.\n\nMIKE: I think I said that I'd come back. There's a couple of things that I want to mention I haven't mentioned before that you're probably going to run into pretty quickly if you start studying this stuff. First of all, we've been talking about neural networks. But, there are a few other approaches that people use to do machine learning. Generally, they also use this gradient descent idea [chuckles] to learn over time. But, they may approach the problem a little bit differently than having layers of weights and biases. \n\nThere's support vector machines, which have kind of fallen out of favor, but there's one that's actually very effective. And if you look at competitions for machine learning where you have tables of data, something that looks like it came from a spreadsheet, they actually don't usually use neural networks because they don't work as well for that kind of category tabular data. You can fit something better with what's called a gradient-boosted tree. \n\nAnd it follows that gradient approach, but they don't apply that to lines exactly. They apply it to decisions that are made to divide the data into sections. You take your data, and you come up with a lot of really simple classifiers that just say, well, taking the input data, I'm going to divide some of the data over onto this side and some of the data on the other side. And then, I'm going to subdivide it again and then subdivide it again until I get all my answers. They call that a decision tree. \n\nAnd if you have a lot of simple decision trees, like, a whole bunch of them, and then you use your gradient descent together with your input data to emphasize, to increase the ranking of some trees versus another, you actually get a very effective model that tends to be better for tabular data. And it's a gradient-boosted tree. So, most of what you see, like ChatGPT, doesn't use gradient-boosted trees. But a lot of the machine learning that you actually use in the real world that you might not even think about is probably coming from those gradient-boosted trees because they're very effective for a lot of the less flashy but also important kinds of things that happen in business. \n\nThe other couple of things I wanted to mention is that if you have a whole bunch of lines, the best prediction you actually can get is just lines. It doesn't map to curve things very well, things that just really don't follow a line. But there's a little bit of magic you can do, which is you take your weights and biases, and you run them through another thing that isn't a straight line. \n\nAnd the thing that they usually run it through, and this is going to sound ridiculous because it's so simple, is that if you get any value that's below zero, just cut it off and say it's zero. It's called a rectified linear unit, which is really a fancy way of just saying if it's less than zero, just call it zero. They call them ReLUs in the literature.\n\nIf you put that on your predictions between your layers, it makes your layers not be able to predict a line because, you know, a line that comes down and then stops at zero is not a line anymore. It's got this point in it that's not linear, and that discontinuous spot there actually–– throws everything off. And it allows these models to learn something that's not aligned that actually might have sophisticated curves in it. Because now it's got something that throws the lines off and can be bendy, and they call that the [crosstalk 37:21] \n\nTAYLOR: Because, yeah, a lot of times in data science, we're talking about error and our loss function. And let's say that the true line of those house prices looks like this. But your prediction might...if it's really bad, it looks like this, and you're off in every direction. And your error is really high because the point over here is really far from the true point, and your point down here is also really far. And our loss function helps determine on each iteration of training how far off we are from that true line. And there's countless different loss functions and accuracy metrics that we use. \n\nAnd, oftentimes, you have to train a lot and test a lot to figure out what the right loss function is or what the right...oftentimes, we're developing [inaudible 37:59]. Like, it's not as simple as just there being a home price. We have to do some work to develop sort of what we want to predict, like, is it home price? Or is it average home price over, like, the last six months? Because home prices change, and some of that's variance and random noise. \n\nBut backing it up to some of the different domains in machine learning, broadly, there's three categories: we call them supervised, unsupervised, and reinforcement learning. Here at Acima, we use supervised learning, so all of our records have outcomes associated with them. We've labeled them. We've supervised the data. We've given it a supervision on what to consider good and what to consider bad. And that's what the gradient-boosted tree classifiers would fall under. Unsupervised would be more of that neural network where it doesn't have labels on how it should consider the data necessarily, but it can learn relationships in that data in an unsupervised fashion.\n\nMIKE: Well, let's talk a little about that because people have actually seen this, and ChatGPT, which has been so famous, is actually a good example of unsupervised learning. They didn't go out and say, \"I want you to predict English, and this is what English is. Match that.\" Did not happen. Because nobody can define English, it's too big. Nobody even knows all of it. Instead, what they did, and this might seem crazy, but they just gave it a bunch of text and said, \"Predict the next word,\" and that's it. They do that billions and billions and billions of times. And you do that enough times; it gets pretty good at figuring out what the next word is going to be. \n\nAnd, in fact, it has to learn concepts about the real world that are embedded in our language, understands hot and cold, and all these other things. It understands these ideas because it had to to be able to figure out what the next word is. But there was no supervision to say, \"Hey, this is what English is. And if you get good grammar, you're right.\" No, all they did was just say, \"I got some data here. Pick the next word.\"\n\nAlso, if you've seen a lot of the amazing image generation that's out there, they did the same thing where they take an image and they'd make it blurry. And then they'd say, \"Predict what the real image is.\" And they got that with blurrier and blurrier images until they just gave it pure noise and say, \"Ah, predict a horse.\" And it manages to predict a horse out of pure noise because it's learned the idea of what a horse looks like. \n\nWhere unsupervised learning is like, what are you talking about? We're just talking about trying to make sense of the world around you without having, like, a standard. You're just trying to predict based on some data that you've got that isn't classified other than to say, well, maybe this is a category.\n\nTAYLOR: And I guess the past few years, it has become less so. But, traditionally, those unsupervised techniques require a huge, enormous amount of data because to figure out the actual underlying meaning in that data requires a whole bunch of data because there are so many examples of, like, what does a horse look like? What does the light look like? Where is it? Like, what color is the horse? So, to be able to extract that information from data,––it requires a whole lot of data––some sophisticated machine-learning techniques. \n\nBut over time, these models have become very good at extracting, like, the underlying relationships between pixels and the full image or words and meaningful texts. And that's really been, I think, the groundbreaking revelation in the past ten years. It's just how much meaning can we extract from this data?\n\nMIKE: And I interrupted a little bit to go into a little more detail about unsupervised learning. You're going to talk about reinforcement learning, something I love as well. Do you want to talk about reinforcement learning? \n\nTAYLOR: Yeah, my first introduction to reinforcement learning was the game of Pac-Man. Our job was to basically build the Pac-Man game such that the ghosts try to eat Pac-Man. and Pac-Man tries to avoid the ghosts and eat the food. \n\nMIKE: [laughs]\n\nTAYLOR: And to do so, you have to go through thousands if not millions of iterations of the game of Pac-Man, developing rules to make Pac-Man eat as many food pellets as you can and not die as often as possible. And on every single one of these iterations, you're learning something, and you're reinforcing the behaviors in the model. Maybe the tweaks that you made didn't perform well, so you have to roll back those changes. Or maybe they perform really well, and you want to see how far you can push those changes. So, that's sort of the idea behind reinforcement learning.\n\nAnd ChatGPT actually has a layer of reinforcement learning on top of it. And this is what you'll see sort of when it says it's just a large language model, and it can't do certain things. This stems from the actual humans' sort of, like, reinforcement learning the underlying transformer model to produce things that, I guess, the humans would prefer not to say. Maybe you guys have seen ChatGPT be hacked before, hacked in a way, or break out of its bounds [crosstalk 42:33] of that. So, you can kind of get, like, the raw output of the transformer model. \n\nYeah, the reinforcement learning on top of ChatGPT is really interesting. In many ways, I think it makes me productive. Like, it keeps students from cheating on their homework, or it stops people from making weapons of mass destruction. But that layer on top is reinforcement learning. And it did require a huge amount of human capital to label output from ChatGPT and kind of weight it in a way where ChatGPT was more user-friendly.\n\nMIKE: Right. And you use reinforcement learning when you have a reward signal like winning the game [chuckles] or getting away from the ghost, or, you know, not saying racist things that you can use to give this number, like, that was good, or that was bad, a reward signal for an output that involves a series of actions over time. Generally, you know, you've got a sequence. And you need to be able to have this incoming state. Well, this is what happens already, and I want you to make a prediction of the value of a certain action going next.\n\nTAYLOR: Yeah, like, in reinforcement learning, we'll oftentimes talk about the idea of, like, the state space. It's really easy to think about, like, in terms of the game of chess. The state space is the chess pieces on the board and the board itself. And depending on how those chess pieces are arranged on the board, you have a different state space. And there's certain optimal moves and the outcomes from that state space. \n\nLike, obviously, the state space of all the possible moves and board conditions in chess is astronomical. But if you were able to calculate that entire state space and the optimal move from every state space, then you have, like, basically a perfect chess agent. And that's kind of where we're at [chuckles] with chess agents. Like, I think it was back in the '90s with Deep Blue. The artificial intelligent chess agents were able to beat...is it Kasparov or? I forget...the Russian grandmaster. \n\nMIKE: Garry Kasparov. \n\nTAYLOR: Yeah, Kasparov. I think there's a phenomenal documentary about that on Netflix or somewhere. But yeah, they developed an algorithm that was able to traverse the chess state space and determine optimal moves. And I believe that was an example of reinforcement learning. I forget what the specific algorithm they used was [inaudible 44:46] model.\n\nMIKE: I think that Deep Blue actually didn't use...I think Deep Blue didn't use reinforcement learning. But --\n\nTAYLOR: Yeah. They might have brute-forced it, right? \n\nMIKE: Yeah, I think they did. It's just that if you look at enough games from enough grandmasters, you can avoid making some of the same mistakes that they did [laughs] --\n\nDAVE: I heard an interview from Kasparov where they told him, \"We just kept adding more and more memory to Deep Blue until it could beat you.\" And he was kind of disgusted to find out that, oh, you did brute force me. And they're like, \"Well, we were going to brute force you from the beginning. That was the whole point.\"\n\nTAYLOR: [laughs].\n\nMIKE: But some of the newer models that have come out of Google's research teams, the Alpha class, AlphaGo, and AlphaZero, that are able to use reinforcement learning to do self-play, play against each other, and learn over time have gotten much better, much better than any previous modeling has.\n\nTAYLOR: Yeah. And, obviously, with the game of go, you weren't able to brute force it because the state space was, I think, it was orders of magnitude higher than chess. \n\nMIKE: Yeah, I think so.\n\nTAYLOR: So, they had to develop these other techniques to extract optimal outcomes from, I guess, more abstract spaces, not specific state spaces.\n\nMIKE: Fascinating stuff. And we're giving you a taste. So, our listeners, we're giving you a taste here of [chuckles] what's going on here. There's one other thing I said that I was going to cover, and so I want to make sure I don't neglect it, which is transformers. There was the wonderfully named paper that came out a few years ago. Taylor, do you remember what year? \"Attention Is All You Need.\" It came out in -- \n\nTAYLOR: 2017.\n\nMIKE: 2017. That has really allowed some of these models to get a lot better. And I mentioned that simple ReLU layer—they cut things off—that puts things in between the linear layers. Well, they came up with a more sophisticated one. It still isn't that sophisticated. They use some Gaussian curves, you know, like, the bell curves you're used to seeing, to try to predict where are the hotspots in the incoming data here. What data is important? And to emphasize that and use that, you know, to be able to kind of focus, again, the attention on some data versus others.\n\nSo, if you look at a lot of text, not all of it is going to be important for what your output is going to be. And being able to predict what is important this works better with these transformer models, as they call them, that pay attention. And those have been developed and have allowed kind of the next stage, the next level of skill in these models. And some of the amazing things like ChatGPT and some of the image generation use some of these transformer layers inside.\n\nTAYLOR: Yeah. If you ever want to learn more about transformers, Spencer Reschke is actually the guy to go to from Acima. He's a mathematician by training. His degree should have also been, like, a computer science degree. He's got a phenomenal understanding of self-attention mechanism. He actually showed me that paper. He's tried to implement a transformer here at Acima. \n\nTransformers are really good at tackling sequence-to-sequence problems. So, in the case of ChatGPT, sequence to sequence is just token to token or word to word or letter to letter. But in the case of Acima, we might use a sequence to sequence to predict how a lease traverses through; I guess, like, the rental period. So, given that the lease is this size and it's the first day, what is the probability, or what's the most probabilistic outcome on the second day? And, like, are they going to be delinquent, or are they going to make their payment? \n\nSo, we'd like to use a sequence-to-sequence model to predict eventual yields on our portfolio. So, these transformers and sequence-to-sequence models can actually generalize to a whole bunch of other problems as long as you can format them in that sequence-to-sequence format.\n\nMIKE: You know, there were other kinds of models used for sequence to sequence prior to that, and they still use some, and hence the name of the paper \"Attention Is All You Need\" said, well, you could use those other techniques. And, originally, some of this transformer used...self-attention was used in tandem with those other techniques. Eventually, they realized––actually, just drop the other techniques entirely. The self-attention is everything you need. And that's been transformative with these transformers. I'm going to look at you, Dave. You've said a little bit, but not a lot. It's mostly the Taylor and Mike show [laughs]. \n\nDAVE: It's been fantastic. I've just been eating this up.\n\nMIKE: Do you have any final questions or, you know, clarification you'd like to put in here?\n\nDAVE: I think this is either going to have a quick answer, or much more likely, it's going to be like the beginning of another episode. But I worked with a PhD gentleman. I guess we call them doctors. I worked with a guy who had a Ph.D. in data science from Stanford. And he said that through the '90s and early noughties, the AI stuff was producing stuff that was really spooky. And it was like, you know, how is this? Why, you know, da da da. And there was a shift in the late noughties, early teens into explainability, where you could literally get your doctorate in explaining why the AI arrived at this. Is that still going on? Is that still a dominant feature of the industry?\n\nMIKE: [laughs] It's still hard -- \n\nDAVE: What's going on with explainability? It's still hard?\n\nMIKE: It's still hard [laughs]. I'll say that. It's still hard. Again, these things are bigger than we can fit in our head. So, somehow, you have to come up with a signal that we can comprehend [chuckles] in something that's far vaster than you can fit in your head. Explainability is still an active area of research. Go ahead, Taylor.\n\nTAYLOR: And I think that's especially true in the areas of, like, transformers and neural networks and these larger models with many layers and tons of neurons. But in terms of some of the more basic machine learning approaches, those are fairly easy to explain or are responsible for explaining some of our decisions using these models here at Acima. And in the case of decision trees, we'll basically say you are on the wrong side of, like, these splits in the tree. Like, your credit score was too high or too low, or your income was too high or too low. \n\nAnd in the context of, like, a trees classifier, you can explain those splits a lot easier than, I guess, the inner layers of a neural network and what those individual neurons meant and why they fired one way for you and worse for another person. So, I do think that is worth spending some time on explainability. Because if you don't understand why your model is producing some outputs, then it lacks in utility in that respect, especially in the area of finance that we're in. \n\nSo, we've never deployed a neural network or something like that. We tend to stick to models that have what's called SHAP predictions or SHAP-supported values. And that's basically a methodology we use to explain prediction output and which features or independent variables lead to the output.\n\nDAVE: Awesome. Does explainability get into the positive side as well of, like, you get back a prediction, and it's like, oh, this lease is going to become delinquent in two weeks? And you're like, wait, what? Because they made a payment at 3:00 p.m. on a Tuesday, that's why. And you're like, okay, that's dumb. Stop...and then two weeks later, the lease goes delinquent, and they all do. It's like the data is there, and it's predicting. Does explainability get into that kind of spooky [inaudible 51:44] Ouija board stuff?\n\nTAYLOR: I mean, sometimes there'll be odd predictions from a model that turn out to be accurate, but in retrospect, I think they would make sense. But for the most part, I think most of the decisions are intuitive. And there is some, like, some understanding you can gain just from looking at the decision. We make predictions a little differently from what you described. Like, we're not predicting delinquency. We're basically predicting if the account is good for the company or bad for the company. \n\nAnd there are certain attributes that make the accounts good, certain attributes that make the accounts bad. It's pretty rare that there'll be an attribute that makes the account good for some strange reason or vice versa. And part of our job is to make sure that doesn't happen. Because that might suggest that the training data was malformed for some reason or it's representing a relationship that's not going to hold true in production, so we'll test to make sure that's not the case. And when we deploy new models, it's definitely something we're looking out for is: why was our input data suddenly not looking like the data we trained on? Like, we've got to do something that will stop this model.\n\nDAVE: That's awesome. I have follow-up questions, but I'll save them for the next time we talk about this. \n\nMIKE: Taylor, do you have any final things you'd like to say?\n\nTAYLOR: I don't think so. I think we've covered a lot. And we can definitely spend another call just covering machine learning and, especially as it pertains to Acima. I would like to extend an invitation to anyone from Acima who wants to learn more or has questions for us; even if it's just a personal project, we're always willing to help and extend an olive branch.\n\nMIKE: Awesome. Well, thank you. Thank you to our listeners for listening to another episode of the Acima Development podcast, and until next time.","content_html":"The panel dissects the world of machine learning and artificial intelligence. They unravel how machine learning algorithms function, using the game of Pac-Man to break down complex topics like reinforcement learning and reward-based systems. Mike dives deeper into reinforcement learning, explaining how it operates on reward signals that assess the value of a series of actions over time. Dave chimes in with his insights on AI's ethical considerations, arguing that lacking a moral framework could lead to unintended and potentially harmful outcomes.
\n\nThey navigate the expansive "state space" concept in machine learning, using chess as an illustrative example, and explore how understanding all possible board states and moves can help develop an unbeatable chess AI agent. This sets the stage for a pivot to natural language processing, where Taylor provides a thorough explanation of transformer architectures, including sequence-to-sequence problems and attention mechanisms.
\n\nDave returns to his earlier point about ethical considerations, spotlighting the importance of the paper "Attention Is All You Need," which has been instrumental in developing transformer models. He then shifts to the challenge of making AI systems more explainable. While Taylor and Mike acknowledge that the complexity of neural networks makes them difficult to interpret, Dave insists that striving for explainability is crucial to making AI more accountable and transparent.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development podcast. I'm Mike. I'm going to be hosting today. And we have a panel with us here today of Dave, and Taylor, and Francisco. Welcome, everybody. Interesting topic we're going through today. And we're going to approach it a little bit differently than we've sometimes done in the past. We're going to be talking about the fundamentals of machine learning.
\n\nTaylor is with us from data science. So, he does this for a living day in and day out.
\n\nTAYLOR: Yep.
\n\nMIKE: And has the smarts here to talk about it. I am very interested in this topic. I have been for a long time [laughs], honestly, since I probably heard about it as a kid [laughs]. So, this has been a long-standing interest of mine. And I've played around with this. I follow the topic closely, but I am not a professional practitioner. So, hopefully, that'll qualify me to at least give you an overview. And we're going to lean on Taylor [laughs] to be the expert.
\n\nUsually, we have a heavy panel discussion. We do have a panel here today to have a discussion. They will maybe be doing more question-answering and filling in the blanks. The goal here...I was talking about this in our pre-call discussion that I'd like somebody who listens today to walk away and say, "You know, I have a basic idea of how this works. I might not be able to implement it, but it's not magic, you know, it's not this dark magic. It's just somehow these machines can think." But you have an idea of how this might work.
\n\nI wanted to start by telling a story. Grounding things in real-world stories is usually very helpful to help us conceive of how things work. The story is about a hike I took a number of years ago. And I couldn't tell you what year it was. It was a long time ago. A friend of mine and I decided to go hiking up in the mountains, and we hiked several miles up a trail. And I really wanted to try something different. My buddy had not done a lot of hiking. So, my ambition was probably bigger than it should have been. Chris, if you ever listen to this, I'm sorry.
\n\nAnd we decided to go on this hike. And I wanted to try a new route that I'd never been on before because I knew that there were trails and two parallel canyons. And we were going on a canyon that was not that deep up high up on the ridge line. And there was a canyon parallel to the one we were in that was much lower, hundreds of feet down, hundreds of meters for anyone not in the United States, at least 100 meters, right? It was a long way down into this parallel Canyon. And I wanted to see if we could find a route between these two canyons in an area that was trailless.
\n\nIt was late spring. I thought, oh, this would be great. The weather's nice. So, we went up. We hiked up the one canyon, got up to the high spot, saw what was an easy place to drop over into the next canyon. And we went over the edge. And it turns out that there was still late spring snow, like, all the way down that canyon wall down through the woods that were there [laughs], and decided to do it anyway.
\n\nBut it was smooshy snow. It was, like, up past our knees. So, we were just postholing, you know, stepping into it. You jump down in up above your knees with every step going down this hill. And it was hard work. We were just absolutely exhausted. We did, however, eventually find the trail that we were looking for. And the way we got there was really very simple. I knew that it was down, and I went that way. We had to walk down through the woods, you know, I didn't have a compass. I didn't really have a map of the area. This was kind of pre-smartphone era. This was a long time ago.
\n\nBut I did know how to make my way down. And I knew the trail was at the bottom of this canyon. So, what I did was I just walked down. Now, there were certainly obstacles along the way. Again, it was forested. There was a lot of trees to weave our way through. But for the most part, that was obscured by the snow; we just had to, at every point, say, well, which way is down? And take a step in that direction.
\n\nAnd when we finally got down to the bottom, there was the trail. And [laughs] we were finally free of the snow. It was wonderful. We got out of the snow, and not much further was the trail. And then things were much better, and we walked down and made our way back, you know, to the car, which was a bit of a walk because we had to go between canyons. Again, Chris, I'm sorry. But we did find out that there was a way.
\n\nWhy am I telling this story? It's because you might think that machine learning is based on something really sophisticated and complex, but it's actually a lot simpler than you might think. And the basic math that it uses is something that you probably learned in either junior high or high school. So, think back about your math. And if you're not a math person, think about this mountain I'm talking about, or think about a road that you have to drive that's got a hill.
\n\nAnd there's really only a couple of things that define that hill. First of all, how steep is it? [laughs] Like, it matters how steep it is, and that's kind of a direction. And where's your starting point? Like, if you're starting most of the way up the hill, then you don't have very far to go, right? If you're starting at the bottom of the hill, there's a long way up. So, there's kind of two parameters that define that hill, which is how steep it is and your starting point. Now, I'm simplifying some here.
\n\nBut in the math that you may have learned way back when and try to remember, you may have learned something like y equals mx plus b, which sounds really mathy, but that's really trying to tell you something simple. It's telling you that you have some input, and you're going to multiply by that and then add a number. Well, and that's still not very practical.
\n\nThe second example I'd like to give is one I usually think about, and there's a few that we could think about. But the one I usually think about is, and that I've seen a lot online, is, let's say, that you want to predict how much a house is going to cost. You want to predict how much a house is going to cost. And you only have one piece of information to predict that, and it's the size of the property it's on. And there's probably a pattern there, right?
\n\nI would imagine that if you're on a tiny city lot, the value is probably going to be lower than on a large city lot. If you've got a house on a large city lot, that's probably a pretty valuable house because city lots are expensive. And there's going to be a lot of noise in that data, though, because that tiny city lot is probably worth a lot more than a tiny country lot. And, you know, maybe it's in a neighborhood where not many people want to live. How close is it to public transportation? I'm going to get back to that minute.
\n\nThere's all of these other things that you could measure. But we're just going to think about one thing, the size in... we'll say in square meters or square feet. I'm in the United States; I'll say square feet. I know that [inaudible 06:07] allows a unit. Meters are better [laughs]. But it's what is commonly used in the United States. So, you know the square footage of your lot. And you want it to have that one number and predict what the price of a house will be.
\n\nNow, let's say you're doing it within the city. Well, there's some simple math you could do there. Here's what I'm going to propose you do: you take the size of that lot in square feet, and you have a number, we'll say 1,000. That's a very small size, but I'm going to use a small number. You can say that 1,000, and you will multiply it by a number, by some weight we'll call it. And you'll get another number that you say that's the price of the house. But you're going to add one other thing, and that is, where does it start? Because there may be a floor to how low the prices will go.
\n\nIt may be even if you have a square-foot lot, it's worth something. It's still worth something more than zero. So, you've got a starting point that's higher than zero. Or maybe you're in, like, Detroit after they went bankrupt, and some property values are worth less than zero, right? [laughs] The city will pay you to take them [laughs]. Either way, there's a starting point that may be above zero. It might even be below zero that the zero, you know, the property with no size would still be worth. And then you go up from there.
\n\nAnd I'm going to call that value...I didn't give it a name. They call it in the machine learning world the bias. They call it the bias. That's the starting point. And the other one, that multiplier you use, is usually called the weight. There's another name you can call it, though, on a line you often heard in math: slope. It's the slope. If you want to get fancy and you think about the steepness of the road that I mentioned before, they call that the grade.
\n\nAnd in math, if you're thinking about a complex grade where it's in multiple dimensions, they call that the gradient. They call that the gradient. But it's really just a fancy name for the slope, you know, how steep is it? And so I got two numbers: the weight, which is the steepness, and the bias. Where's your starting point? So, I'm going to look at Taylor here. So, you with me, Taylor? What gaps do you think I have left so far?
\n\nTAYLOR: No, I think you're doing pretty well. I mean, that's why we call the y equals mx plus B slope form. It's describing lines and their slope and how they traverse through [inaudible 08:21] space. When you were talking about traversing from different trails––last time, obviously, you're talking about gradient descent here.
\n\nMIKE: And I'm going to get there in a minute [laughs].
\n\nTAYLOR: Yeah. And one of our co-workers had a sticker that he gave when he left, and it was a ski resort called Gradient Descent or, like, Gradient Slopes or something like that.
\n\nMIKE: [laughs].
\n\nTAYLOR: I thought that was a really cool sticker. It's a fun play on words. But no, I think you're doing a great job of explaining these concepts so far. I could interject with a lot of, like, data science terms for these. But I think for explaining to a junior high student, then we're spot on.
\n\nMIKE: Well, excellent. And you're like, what does this have to do with machine learning? You're talking about the stuff I learned back in junior high.
\n\nTAYLOR: [laughs]
\n\nMIKE: Well, and here's where the next step is that we really get to magic. I'm going to go back to this idea of houses; then, I'm going to use this to tie things together. If you have ten houses that you want to do this with, and you say, well, here's the property values, and here's the houses, you could draw a picture, right?
\n\nYou could say, well, this house has a property size of 30,000 square feet, and this one has a property size of 50,000 square feet. And then, you draw a picture, you know, mapping your...on one axis...so, you just draw a line, and then, as you go higher along, you're going to put the size of the property. The higher the property size, it goes higher on the line. And then, along the other axis, you're going to put the price of the house.
\n\nAnd if you kind of map those, you're going to see them following a pattern where it goes up into the right, assuming that the higher values go to the right. And you could draw a line through that and probably eyeball it and get a pretty good number to say, hey, here's the line that I'm going to use to fit to that data, you know, that you got that line of best fit. There's a fancy, mathy word for a line, for things referring to lines. They say linear because it has the word line in it with an E-R at the end, a linear, or an A-R at the end. You know, it's liner. A line you can use to map the data.
\n\nAnd it's probably not a perfect fit, right? But lines are pretty simple to use. And one thing about line is they've only got really two characteristics that you care about, which is how steep is it? And what's the starting point? There's starting to be a pattern here. How steep is it, and what's the starting point? Which you can use with that y equals mx plus b. You can use those two numbers. All that is...I can go back. Well, the two numbers that you care about is how steep it is, which is the same thing, as we said before, as that weight. The number that you're going to multiply by the size of your property and that bias sort of, you know, where does your line start?
\n\nBut what if you have a million? What if you have a million houses? Well, you're probably not going to do that by hand. It's going to take you a long time. Even with the size of a million modern computers, you could probably figure out an exact line of best fit. But as you get to increasingly large datasets, it becomes less and less tractable.
\n\nHere's what gets even worse. What if those other data points that I mentioned are also into play? What if you also want to involve the proximity to public transportation? What about the neighborhood that it's in, and you want to treat that as a data point? What about how urban or rural or, you know, which urban area that it's in? You know, what about the age of the home? What about the company who built the home? There's all kinds of things that you can measure.
\n\nWe're often used to thinking about things we can measure as being in our world around us and tend to mention Cartesian coordinates. We often think about, well, how far is it in front of me? How far is it to either side of me? How far is it up and down? So, we've got these three things we can measure: in front of me, to the side, and up, and we call those dimensions. But that word dimension just means things I can measure. So, I could also measure the distance from public transportation. I could measure the distance from the city center. I can measure in kind of a categorical sense categories of, you know, what these neighborhoods are. There's many things that I can measure.
\n\nAnd dimension is just something I can measure. Well, I could probably measure hundreds of things. And that's really hard to picture drawing [chuckles] when I've got hundreds of things. And for all of those hundreds of things, I want to find a best fit that kind of maps all of them in some complex multi-dimensional space. Well, that sounds really awful.
\n\nBut the concept is very simple. I just want to have a weight for every one of them and a bias for every one of them. And then, I multiply those all together and, add it together, and get a number out of the other end. Well, that sounds like something I could do, although I don't know how to do it on paper. And if I've got a huge number of things coming in, I might not even be able to do it easily on a computer. But there is something I can do.
\n\nHere's where the learning part comes in: the moment of magic. What if I do my math...and I'm going to go back to the example of just one, and I'm just going to draw a line completely random, no thought going into it whatsoever. None at all. I'm going to draw a random line. And then, I'm going to take my first house, and I'm going to figure out, like, some exact numbers. Like, what do I have to multiply the property size by to get to the size of that house? And that will give me a number for my weight that's different from the one I have because the one I have is totally random. I mean, the chance those are exactly the same is basically zero. They're different.
\n\nAnd I'm going to take my number that I guessed at random, and I'm going to move it a little bit, not much, just a little bit toward the value I got for the house. Remember, these weights can also be called the slope or, in a fancy word, the gradient. So, I'm going to move my gradient a little bit more toward the one that that house would suggest it ought to be. And then, I'm going to do it again with the next house on my list. And then again, and then again, a million times, or a billion times.
\n\nAnd if you think about what's going to happen to that gradient, sometimes it's going to go the wrong way because we have some rundown mansion that's actually not worth very much [laughs] and some little place that's actually really fancy. It skews it the other way. But if I keep on doing that a million times, just moving a little bit each time, there's going to be a little bit of bounce around, thinking about following that gradient, following that slope towards the right one. Over time, I'm going to follow that difference, right? The difference between the slope values until I get something really close.
\n\nThink about me walking down that hill on that mountain. I didn't always go exactly towards the trail, I guarantee that. Sometimes, I was going around trees. Sometimes, I probably went uphill to dodge an obstacle, but as long as I was going in the direction of the trail, changing my position a little bit each time going in the right direction. And if I'm not being very watchful, maybe I'm going to pass it [chuckles] and then have to come back to that direction. But then I'm going to come back downhill the other way because I go back up the canyon on the other side and wave until I get down to that trail, which happens to be right at the bottom. And there's a fancy name for that: gradient descent.
\n\nBut all that that really is...and you think that, oh no, it's got to be more complicated than that. Well, actually, no, it's not. Because simple things are how you solve really ugly problems a lot of times, that is really what machine learning practitioners have been doing for a long time is: they thought, well, okay, well, let's take a simple approach to this problem. Let's take my input data and, multiply it by some weights, add some biases.
\n\nAnd I'm just going to start with some random weights and biases. And now I'm going to adjust them a little bit with a batch of data, and then a little bit more and a little bit more and a little bit more. And I'm just going to do this a whole bunch of times. And if I do that enough times with enough data—and it helps to have a lot of data—I'm eventually going to get some pretty good weights and biases, right? It's actually going to be pretty good. And this is not a new idea. There is something called the perceptron, which followed this pattern, and it was invented in 1943.
\n\nTAYLOR: Wow.
\n\nMIKE: That does just this. Back then, computers were feeble enough compared with today's. They actually originally designed it in software, but they built hardware for it. They built hardware that would do this, and they thought this will change the world. This learning will change the world. Well, they didn't have very much data. And they didn't have, you know, a very big machine. So, it didn't really change the world that much. But it was able to learn from a set of data. Remember, this is 1943.
\n\nTAYLOR: That's amazing.
\n\nMIKE: And these ideas have been bouncing around since then, and people probably thought of that. This idea of linear approximation or linear regression, which is trying to find that line of best fit, has been around for a long time. Well, in the 1990s, some mathematicians started working more on this. One guy, particularly named Yann LeCun, and the team...he is a professor...a team of his started working on that. And they explored some of these ideas. Another important person here is named Geoffrey Hinton.
\n\nThey kept thinking that this idea of using these weights and biases to solve the problem and making a whole network of them was going to be really useful. And at the time, you know, back in the '90s, there were actually a lot of people who thought it wouldn't work. Because they thought, well, that's too simple, you know, our brain really has these concepts of things. And we need to come up with relationships with things and make large databases of things. And that's how we'll really solve the problem.
\n\nThe problem with that is you have a lot of different things. You've got a lot of different relationships [inaudible 17:04] them. It's just too hard to map out. The work involved in that is mind-boggling. And how do you do kind of fuzzy relationships between things? The whole thing just falls apart. It's just impossible to build that database, practically.
\n\nBut there were a couple of really important things that happened between the '90s and the year...and I'm going to say, specifically, the year 2012. And here's the couple of things that happened. First, well, the internet. People started posting things online, which meant we ended up with vast amounts of data, huge amounts of data points that we could start doing stuff with. And the other thing that happened is maybe a little bit unexpected, which is the rise of computer gaming. And computer gamers really, really love to have good graphics. They want to have beautiful graphics that are very immersive.
\n\nAnd so, like, what does all this data and these graphics cards have to do with things? Well, first of all, it's really hard to learn something if you don't have very many examples to learn from. And in the older era, the only way you could get a bunch of examples of things is kind of find them for yourself and write them down, and that's just impractical to do as a single team. But by the early 2000s, there were teams that started scraping the internet, and you could get a million images.
\n\nWell, now you got a whole bunch of data. What can we do with this data to learn about it? And second thing with the gaming is that gamers, in order to have these good graphics, they use graphics cards, which is a specific, like, little computer in your computer. So, it's a dedicated processor that's really, really good at doing linear algebra. It's really good at doing this line math that we've been talking about. Well, they do that so they can navigate the way that light passes through space. But that also happens to just match really well anytime you want to find a line of best fit for things.
\n\nTAYLOR: Light moves in straight lines. That's why that matches.
\n\nMIKE: So, some researchers started to use those graphics cards to start crunching a whole bunch of this linear algebra to say, what if I take a whole bunch of data, start running through these graphics cards using these old techniques that have been around since the 1940s? And really, they go back farther than that, and these predate computers for the linear regression. But, the idea of using gradient descent with a computer to do it has been around since the 1940s. What if we start applying these ideas we already knew to some of the input data?
\n\nAnd they start with a lot of input data because an image, you think it has a lot of pixels in there. But really, those are all just a whole bunch of data points. We talked about a lot of dimensions. Well, each of those pixels just has a brightness, right? And some position, you know, it's like an X and a Y position. It's got a position on the screen, and it's got some brightness. Well, those are just data points. Those are just dimensions.
\n\nNow, if we throw all of those many, many dimensions into some of these little classifiers I told about where we just add a whole bunch of weights and biases that we picked at random, and then we adjust it and say, "This image you throw all of these numbers, and then that is a cat," this other big set of numbers and say, "That's not a cat; it's a dog." Well, you know, that's something that's just almost impossible to think about doing as a person. But the graphics card it does that all day, every day. And the combination of the two was amazingly effective.
\n\nAnd I've mentioned 2012 because, in 2012, the team of Geoffrey Hinton built an image recognition network, as they called it, that followed this process. And there's a couple of little tweaks that I haven't mentioned, which is that they did something a little tricky. Rather than predicting immediately with just one set of weights and biases, Elvis is a cat; they dumped the output of those weights and biases, so those numbers that come out of there into another set of weights and biases. Like, wait, what? What does that even mean?
\n\nSo, you put another set of weights and biases in between and then another set, several layers of these linear approximaters, and then they get now put out of it. Well, that's kind of weird, right? I mean, why would you put layers? Because what does that even mean on the in-between?
\n\nIt turns out that that allows something magical to happen [laughs]. I'm going to keep using this word magic because it feels like it when it finally works. Is that these in-between layers start not predicting directly the price of the house; they start predicting something maybe more sophisticated. Like, based on this input data, I'd maybe have some prediction about the value of the roof. Even if you didn't have that directly, they start learning that concept because you can see, like, how new it is, maybe something...the color of the roof. They start to learn these concepts. Go ahead, Dave.
\n\nDAVE: Right. Is this, like, literally, like, you're like, okay, this is a point six hectare, you know, acre lot. It's going to be a $180,000 house, and you're going to need to take the lead out of the paint because...right?
\n\nMIKE: So, that lead may never be explicitly specified. But some of these intermediate layers because they don't have to directly predict the price of the house; they can predict something in between. And remember, they're just starting with random initialization. So, maybe one of them actually started out pretty good at predicting the lead just by random chance. And by keeping with that and getting even closer to this lead idea, somewhere in between these layers, it was able to improve the predictions of the network as a whole. And so, it sticks with it.
\n\nAnd with images, you can actually look at what comes out of these intermediate layers when they do this. And you see things like some of them recognize lines, some of them recognize circles. You know, they start recognizing interesting characteristics of the image that are not cat, but they might be important for cat, something like eyes, for example. Or circles lead to eyes [chuckles], which lead to face, which leads to, oh, cat. And just by throwing numbers at it and adjusting your gradients each time.
\n\nNow, there's a problem here. It's hard to directly adjust your gradient when you have multiple layers. And here's where I'm going to get a little bit more math-y. And this was some of the trick that some of the researchers figured out. I think it was particularly in the '90s but then in the 2000s. And this trick is...it comes from calculus. And this is where I'm going to get math-y for a second.
\n\nIf you've ever done calculus, there's something called the chain rule, which is that if you want to find the derivative, which is another fancy word because mathematicians have, like, ten fancy words for the same idea of this slope. And it's a little more sophisticated because they can find it, you know, it's more than a line. But the idea is another idea of this slope.
\n\nAnd if you want to find the slope of some complex curve that has a bunch of things happening to it, there's a rule you can actually use to work back from the final one to the first one. Well, if each of these layers in the network is just applying some lines, some weight, and a bias, well, we know how to find slope from that. And so we can work backwards through the layers using that calculus chain rule. If you know calculus, if you're interested in that, they call that backpropagation. And that was the trick they learned for training this thing when it got more and more layers. And adding those layers really ended up allowing this magic to happen.
\n\nSo, in 2012, they made a network called AlexNet that absolutely clobbered a competition for image detection. And people are like, "Oh wow, I wasn't expecting that [chuckles]. We're onto something." And it's approximately decades since things have gone on. So, Taylor.
\n\nTAYLOR: Yeah, I was just going to mention that there are standard datasets used to analyze these models. So, if you ever have a great idea on how to like, detect images, and classify images, you can test them on these standard sets of images and produce research using those. And I'm sure they're different today, but I'm sure you can still find the dataset that that was trained on and see how newer models perform on it.
\n\nMIKE: It is. It's called ImageNet, and they still use it a lot in training. And ImageNet happened because some professors...I think it was Fei-Fei Li. Is that her name? I think she's at Stanford. And her team got together a whole bunch of images off the internet and came up with a classification competition. And then the graphics cards gave us the power to do a whole bunch of line math of linear algebra, put them together, and out of it comes something that we never had before: the ability for machines to very effectively recognize images. And that really has kind of sparked the progress toward modern artificial intelligence and machine learning.
\n\nAnd after that, you know, things started happening like Siri and Alexa, you know, name your smart assistant that can understand language. Well, underneath, they were using these same kinds of linear classifiers built into a network called a deep because there's more than one layer, a deep neural network. And it works. There's a couple of other things that I wanted to throw out there to kind of complete the story. But I'm going to pause here for a minute.
\n\nBut I think we should have a little bit of discussion because we've covered the most important parts, which is you start with just trying to find some multiplier for your input, for your input dimension, your input value that will give you the output value you wanted. And you adjust it a little bit each time with your incoming data, and then you just pump a whole bunch of data at it. And that idea is the idea, and it's not a new idea.
\n\nBut if you have the computers that can handle it and you have the data, you can throw at it with a whole bunch of values, right? A million images is a whole lot more than five. And today's datasets are absolutely enormous. With some of the text datasets, you have, like, a trillion data points that you...a trillion...I say data points, a trillion examples maybe you'll throw.
\n\nSo, there's just huge amounts of data that they can throw at really big networks that are big enough to learn a lot of these little nuances, and that's it. But the math behind it is actually not that scary in the small scale. It really is just finding that line. Now I'm going to be quiet for a bit because I've talked a lot. Like I said, this one's going to be a little bit different because I wanted to lay out these ideas.
\n\nDave said he was going to approach this more as the, hey, tell me more, and Taylor is more of the field expert. Well, there's a couple of things that I want to visit. For example, I have not talked about gradient-boosted trees, which applies the same idea to decision trees. There's other ways they apply this gradient idea to something that's also pretty simple but is a little bit different.
\n\nAnd I haven't yet talked about transformers and about what might go in between these layers where you do something to get something that's a little bit more than a line. But those are all just tweaks to this core idea. So, Dave, I'm going to look at you first. What are your thoughts?
\n\nDAVE: I am just falling all over myself to preemptively yield the floor to Taylor.
\n\nMIKE: [laughs]
\n\nDAVE: Because I have lots of ideas and lots of questions, but the actual implementation details of machine learning is something so far outside my ken that this is just fantastic. I'm really, really, really digging this.
\n\nTAYLOR: Yeah, I honestly deal a lot more with, I guess, the implementation details of machine learning, like in the day-to-day here at Acima. Oftentimes, that is far more important than the training of a model. Handling data in production and, assembling that data, and making successful predictions is very difficult, and doing it correctly at scale is even more difficult. But, Mike, I really liked how you're describing neural networks. They are inspired by the human brain, and that's where the neural part comes from.
\n\nSo, it's a really interesting abstraction of how humans learn. And that when we're born, we're sort of initialized with a really basic [chuckles] neural architecture that the weights really aren't well defined, like, outside of our instincts. And as we grow, we really start to develop more neural pathways, and we strengthen those neural pathways. We correct those neural pathways. And over time, we optimize them so we can be, I guess, contributing members of society and successful humans.
\n\nBut, like, when I'm learning, I conceptualize it in that way as well. Like, you have to take an integrative approach. If you do things more than once, it's going to take a while to get those weights to where you want them to be and to get them optimized, so, yeah, we take the same approach with machine learning.
\n\nBut really contextualizing the problem is a lot more difficult when it comes to machine learning. It's really had to define all your input variables, and you have to structure everything very well, very consistently. You have to be very organized. I think, as humans, we kind of take that for granted. It kind of happens just almost subliminally. Like, we don't have to worry about categorizing data and storing it [inaudible 29:12]
\n\nMIKE: Because we've been building our model since we were born [laughs]. It feels like common sense because we have been practicing it.
\n\nTAYLOR: Yeah. So, when we're training these machine learning models, we have to be, like, very diligent and very specific. And if you're not careful, you're going to teach the model something that you didn't intend to because you didn't contextualize the problem correctly. And in machine learning, we say that the model is not going to generalize if the data you gave it isn't like the data it's going to see. So, that's yeah; it's just a fundamental part to training machine learning is getting that dataset correct such that it mimics the real world, it mimics what the model is actually going to be predicting on.
\n\nAnd we spend a ton of time here at Acima making sure that's the case. Because if you train a model and you think it's doing well, and your accuracy metrics are where you want them to be, but when you deploy, it performs totally different, like, that model is not successful at all. It might have done well in training, but it doesn't do anything for us if it doesn't do that same thing in production. And stuff like that's happened before, and that's when you have to debug and figure out where that dataset was corrupted or queried the wrong way.
\n\nMIKE: What you're saying there, it's hard to emphasize this point enough. I'm going to go back to the thought that this perceptron was named in 1943. But we didn't have this big AI explosion until after 2012. And remember, there are two halves to that: first one was getting the computers that could handle it, and the other one was getting the data and [laughs] everything Taylor is talking about here. That work of getting a good dataset was what it took 70 years to get together.
\n\nTAYLOR: Yes, it truly is the culmination of several different domains, like, really just getting to the point where they can mesh and do things really well. I think a lot of what we consider machine learning is just classical statistics, and it's been in use for decades at this point. We joke about the term AI in our department, and we think it's kind of funny because it's kind of just a buzzword. And artificial intelligence often isn't that intelligent. Like you said, they're fairly basic concepts that are playing out.
\n\nThese newer forms of large language models are closer to what I would consider AI and more of the Sci-Fi stuff. We're still not there yet. But yeah, classical machine learning has been around for quite a while. We've had actuaries for a long time, and statistical methods have been used to underwrite risk for decades.
\n\nMIKE: I remember as a kid, a good friend of mine, his dad was a statistician, and I thought, wow, that sounds so boring. And I wanted to go into other areas of science. It turns out now, like, I work with that kind of thing for a living, and it's so cool [laughs]. And he went into other areas of science. We kind of swapped roles. But it's been around for a long time. We've just gotten better tools for applying it.
\n\nAnd I want to say kind of repeatedly that the basic ideas here...if you've been scared, like, I want to learn this, but, man, that sounds too complicated, but they use a lot of fancy symbols and stuff in the papers and sometimes, you know, it takes a while to wrap your head around. But the ideas here, at their fundamental, like the basics of what's going on in machine learning, are not that complex. It's mostly these weights and biases.
\n\nTAYLOR: Yeah. To add to your point earlier on, like, actually implementing these, the great thing about all these machine learning algorithms is that they're packaged really well, especially in Python. You'll see almost zero math notation when you're training a machine learning model, other than how you choose to define your variables and methods. But it's incredibly easy to sit down and get started with machine learning. There's tons of datasets online that you can play around with. And there's standards that people have come to, prediction standards on those datasets. So, you can get an idea of if you're doing something completely wrong or you're hitting the nail on the head.
\n\nBut yeah, they're fairly easy to implement. We actually use a hosted solution to train and deploy all of our machine-learning models; it's DataRobot if you guys are familiar. And there's dozens of machine learning algorithms packaged up in there. It handles all your training data and iterates through different training methods, and we do some work to select the best models in there and deploy them there.
\n\nBut tools like that are great, and, like, now is the best time to get into machine learning and artificial intelligence because there truly is just so much material out there to learn, just countless hours of Khan Academy or YouTube videos. Yeah, if you're looking to get into machine learning, you shouldn't be too scared.
\n\nI'm trained as a computer scientist. So, I don't have, like, a specific data science degree or even a math degree like some of the co-workers here at Acima. But, I was able to make the transition into data science because it really is just computer science mixed with statistics and mathematics, and I've really enjoyed it. And it's one of my favorite domains of computer science if not my favorite.
\n\nMIKE: You know, unless you are inventing some addition to kind of the toolset used in these models, you probably are not going to be doing a lot of math because you're not going to be inventing your own architecture of layers and such because people have already built that. And you can get it pre-packaged. You just should have some understanding of what's going on under the hood.
\n\nTAYLOR: Yeah, you can get yourself into trouble if you don't understand the underlying fundamentals. Machine learning models are very finicky. And, like I said earlier, if you feed them wrong data, they're going to learn the wrong thing, and they're not going to perform well.
\n\nMIKE: I think I said that I'd come back. There's a couple of things that I want to mention I haven't mentioned before that you're probably going to run into pretty quickly if you start studying this stuff. First of all, we've been talking about neural networks. But, there are a few other approaches that people use to do machine learning. Generally, they also use this gradient descent idea [chuckles] to learn over time. But, they may approach the problem a little bit differently than having layers of weights and biases.
\n\nThere's support vector machines, which have kind of fallen out of favor, but there's one that's actually very effective. And if you look at competitions for machine learning where you have tables of data, something that looks like it came from a spreadsheet, they actually don't usually use neural networks because they don't work as well for that kind of category tabular data. You can fit something better with what's called a gradient-boosted tree.
\n\nAnd it follows that gradient approach, but they don't apply that to lines exactly. They apply it to decisions that are made to divide the data into sections. You take your data, and you come up with a lot of really simple classifiers that just say, well, taking the input data, I'm going to divide some of the data over onto this side and some of the data on the other side. And then, I'm going to subdivide it again and then subdivide it again until I get all my answers. They call that a decision tree.
\n\nAnd if you have a lot of simple decision trees, like, a whole bunch of them, and then you use your gradient descent together with your input data to emphasize, to increase the ranking of some trees versus another, you actually get a very effective model that tends to be better for tabular data. And it's a gradient-boosted tree. So, most of what you see, like ChatGPT, doesn't use gradient-boosted trees. But a lot of the machine learning that you actually use in the real world that you might not even think about is probably coming from those gradient-boosted trees because they're very effective for a lot of the less flashy but also important kinds of things that happen in business.
\n\nThe other couple of things I wanted to mention is that if you have a whole bunch of lines, the best prediction you actually can get is just lines. It doesn't map to curve things very well, things that just really don't follow a line. But there's a little bit of magic you can do, which is you take your weights and biases, and you run them through another thing that isn't a straight line.
\n\nAnd the thing that they usually run it through, and this is going to sound ridiculous because it's so simple, is that if you get any value that's below zero, just cut it off and say it's zero. It's called a rectified linear unit, which is really a fancy way of just saying if it's less than zero, just call it zero. They call them ReLUs in the literature.
\n\nIf you put that on your predictions between your layers, it makes your layers not be able to predict a line because, you know, a line that comes down and then stops at zero is not a line anymore. It's got this point in it that's not linear, and that discontinuous spot there actually–– throws everything off. And it allows these models to learn something that's not aligned that actually might have sophisticated curves in it. Because now it's got something that throws the lines off and can be bendy, and they call that the [crosstalk 37:21]
\n\nTAYLOR: Because, yeah, a lot of times in data science, we're talking about error and our loss function. And let's say that the true line of those house prices looks like this. But your prediction might...if it's really bad, it looks like this, and you're off in every direction. And your error is really high because the point over here is really far from the true point, and your point down here is also really far. And our loss function helps determine on each iteration of training how far off we are from that true line. And there's countless different loss functions and accuracy metrics that we use.
\n\nAnd, oftentimes, you have to train a lot and test a lot to figure out what the right loss function is or what the right...oftentimes, we're developing [inaudible 37:59]. Like, it's not as simple as just there being a home price. We have to do some work to develop sort of what we want to predict, like, is it home price? Or is it average home price over, like, the last six months? Because home prices change, and some of that's variance and random noise.
\n\nBut backing it up to some of the different domains in machine learning, broadly, there's three categories: we call them supervised, unsupervised, and reinforcement learning. Here at Acima, we use supervised learning, so all of our records have outcomes associated with them. We've labeled them. We've supervised the data. We've given it a supervision on what to consider good and what to consider bad. And that's what the gradient-boosted tree classifiers would fall under. Unsupervised would be more of that neural network where it doesn't have labels on how it should consider the data necessarily, but it can learn relationships in that data in an unsupervised fashion.
\n\nMIKE: Well, let's talk a little about that because people have actually seen this, and ChatGPT, which has been so famous, is actually a good example of unsupervised learning. They didn't go out and say, "I want you to predict English, and this is what English is. Match that." Did not happen. Because nobody can define English, it's too big. Nobody even knows all of it. Instead, what they did, and this might seem crazy, but they just gave it a bunch of text and said, "Predict the next word," and that's it. They do that billions and billions and billions of times. And you do that enough times; it gets pretty good at figuring out what the next word is going to be.
\n\nAnd, in fact, it has to learn concepts about the real world that are embedded in our language, understands hot and cold, and all these other things. It understands these ideas because it had to to be able to figure out what the next word is. But there was no supervision to say, "Hey, this is what English is. And if you get good grammar, you're right." No, all they did was just say, "I got some data here. Pick the next word."
\n\nAlso, if you've seen a lot of the amazing image generation that's out there, they did the same thing where they take an image and they'd make it blurry. And then they'd say, "Predict what the real image is." And they got that with blurrier and blurrier images until they just gave it pure noise and say, "Ah, predict a horse." And it manages to predict a horse out of pure noise because it's learned the idea of what a horse looks like.
\n\nWhere unsupervised learning is like, what are you talking about? We're just talking about trying to make sense of the world around you without having, like, a standard. You're just trying to predict based on some data that you've got that isn't classified other than to say, well, maybe this is a category.
\n\nTAYLOR: And I guess the past few years, it has become less so. But, traditionally, those unsupervised techniques require a huge, enormous amount of data because to figure out the actual underlying meaning in that data requires a whole bunch of data because there are so many examples of, like, what does a horse look like? What does the light look like? Where is it? Like, what color is the horse? So, to be able to extract that information from data,––it requires a whole lot of data––some sophisticated machine-learning techniques.
\n\nBut over time, these models have become very good at extracting, like, the underlying relationships between pixels and the full image or words and meaningful texts. And that's really been, I think, the groundbreaking revelation in the past ten years. It's just how much meaning can we extract from this data?
\n\nMIKE: And I interrupted a little bit to go into a little more detail about unsupervised learning. You're going to talk about reinforcement learning, something I love as well. Do you want to talk about reinforcement learning?
\n\nTAYLOR: Yeah, my first introduction to reinforcement learning was the game of Pac-Man. Our job was to basically build the Pac-Man game such that the ghosts try to eat Pac-Man. and Pac-Man tries to avoid the ghosts and eat the food.
\n\nMIKE: [laughs]
\n\nTAYLOR: And to do so, you have to go through thousands if not millions of iterations of the game of Pac-Man, developing rules to make Pac-Man eat as many food pellets as you can and not die as often as possible. And on every single one of these iterations, you're learning something, and you're reinforcing the behaviors in the model. Maybe the tweaks that you made didn't perform well, so you have to roll back those changes. Or maybe they perform really well, and you want to see how far you can push those changes. So, that's sort of the idea behind reinforcement learning.
\n\nAnd ChatGPT actually has a layer of reinforcement learning on top of it. And this is what you'll see sort of when it says it's just a large language model, and it can't do certain things. This stems from the actual humans' sort of, like, reinforcement learning the underlying transformer model to produce things that, I guess, the humans would prefer not to say. Maybe you guys have seen ChatGPT be hacked before, hacked in a way, or break out of its bounds [crosstalk 42:33] of that. So, you can kind of get, like, the raw output of the transformer model.
\n\nYeah, the reinforcement learning on top of ChatGPT is really interesting. In many ways, I think it makes me productive. Like, it keeps students from cheating on their homework, or it stops people from making weapons of mass destruction. But that layer on top is reinforcement learning. And it did require a huge amount of human capital to label output from ChatGPT and kind of weight it in a way where ChatGPT was more user-friendly.
\n\nMIKE: Right. And you use reinforcement learning when you have a reward signal like winning the game [chuckles] or getting away from the ghost, or, you know, not saying racist things that you can use to give this number, like, that was good, or that was bad, a reward signal for an output that involves a series of actions over time. Generally, you know, you've got a sequence. And you need to be able to have this incoming state. Well, this is what happens already, and I want you to make a prediction of the value of a certain action going next.
\n\nTAYLOR: Yeah, like, in reinforcement learning, we'll oftentimes talk about the idea of, like, the state space. It's really easy to think about, like, in terms of the game of chess. The state space is the chess pieces on the board and the board itself. And depending on how those chess pieces are arranged on the board, you have a different state space. And there's certain optimal moves and the outcomes from that state space.
\n\nLike, obviously, the state space of all the possible moves and board conditions in chess is astronomical. But if you were able to calculate that entire state space and the optimal move from every state space, then you have, like, basically a perfect chess agent. And that's kind of where we're at [chuckles] with chess agents. Like, I think it was back in the '90s with Deep Blue. The artificial intelligent chess agents were able to beat...is it Kasparov or? I forget...the Russian grandmaster.
\n\nMIKE: Garry Kasparov.
\n\nTAYLOR: Yeah, Kasparov. I think there's a phenomenal documentary about that on Netflix or somewhere. But yeah, they developed an algorithm that was able to traverse the chess state space and determine optimal moves. And I believe that was an example of reinforcement learning. I forget what the specific algorithm they used was [inaudible 44:46] model.
\n\nMIKE: I think that Deep Blue actually didn't use...I think Deep Blue didn't use reinforcement learning. But --
\n\nTAYLOR: Yeah. They might have brute-forced it, right?
\n\nMIKE: Yeah, I think they did. It's just that if you look at enough games from enough grandmasters, you can avoid making some of the same mistakes that they did [laughs] --
\n\nDAVE: I heard an interview from Kasparov where they told him, "We just kept adding more and more memory to Deep Blue until it could beat you." And he was kind of disgusted to find out that, oh, you did brute force me. And they're like, "Well, we were going to brute force you from the beginning. That was the whole point."
\n\nTAYLOR: [laughs].
\n\nMIKE: But some of the newer models that have come out of Google's research teams, the Alpha class, AlphaGo, and AlphaZero, that are able to use reinforcement learning to do self-play, play against each other, and learn over time have gotten much better, much better than any previous modeling has.
\n\nTAYLOR: Yeah. And, obviously, with the game of go, you weren't able to brute force it because the state space was, I think, it was orders of magnitude higher than chess.
\n\nMIKE: Yeah, I think so.
\n\nTAYLOR: So, they had to develop these other techniques to extract optimal outcomes from, I guess, more abstract spaces, not specific state spaces.
\n\nMIKE: Fascinating stuff. And we're giving you a taste. So, our listeners, we're giving you a taste here of [chuckles] what's going on here. There's one other thing I said that I was going to cover, and so I want to make sure I don't neglect it, which is transformers. There was the wonderfully named paper that came out a few years ago. Taylor, do you remember what year? "Attention Is All You Need." It came out in --
\n\nTAYLOR: 2017.
\n\nMIKE: 2017. That has really allowed some of these models to get a lot better. And I mentioned that simple ReLU layer—they cut things off—that puts things in between the linear layers. Well, they came up with a more sophisticated one. It still isn't that sophisticated. They use some Gaussian curves, you know, like, the bell curves you're used to seeing, to try to predict where are the hotspots in the incoming data here. What data is important? And to emphasize that and use that, you know, to be able to kind of focus, again, the attention on some data versus others.
\n\nSo, if you look at a lot of text, not all of it is going to be important for what your output is going to be. And being able to predict what is important this works better with these transformer models, as they call them, that pay attention. And those have been developed and have allowed kind of the next stage, the next level of skill in these models. And some of the amazing things like ChatGPT and some of the image generation use some of these transformer layers inside.
\n\nTAYLOR: Yeah. If you ever want to learn more about transformers, Spencer Reschke is actually the guy to go to from Acima. He's a mathematician by training. His degree should have also been, like, a computer science degree. He's got a phenomenal understanding of self-attention mechanism. He actually showed me that paper. He's tried to implement a transformer here at Acima.
\n\nTransformers are really good at tackling sequence-to-sequence problems. So, in the case of ChatGPT, sequence to sequence is just token to token or word to word or letter to letter. But in the case of Acima, we might use a sequence to sequence to predict how a lease traverses through; I guess, like, the rental period. So, given that the lease is this size and it's the first day, what is the probability, or what's the most probabilistic outcome on the second day? And, like, are they going to be delinquent, or are they going to make their payment?
\n\nSo, we'd like to use a sequence-to-sequence model to predict eventual yields on our portfolio. So, these transformers and sequence-to-sequence models can actually generalize to a whole bunch of other problems as long as you can format them in that sequence-to-sequence format.
\n\nMIKE: You know, there were other kinds of models used for sequence to sequence prior to that, and they still use some, and hence the name of the paper "Attention Is All You Need" said, well, you could use those other techniques. And, originally, some of this transformer used...self-attention was used in tandem with those other techniques. Eventually, they realized––actually, just drop the other techniques entirely. The self-attention is everything you need. And that's been transformative with these transformers. I'm going to look at you, Dave. You've said a little bit, but not a lot. It's mostly the Taylor and Mike show [laughs].
\n\nDAVE: It's been fantastic. I've just been eating this up.
\n\nMIKE: Do you have any final questions or, you know, clarification you'd like to put in here?
\n\nDAVE: I think this is either going to have a quick answer, or much more likely, it's going to be like the beginning of another episode. But I worked with a PhD gentleman. I guess we call them doctors. I worked with a guy who had a Ph.D. in data science from Stanford. And he said that through the '90s and early noughties, the AI stuff was producing stuff that was really spooky. And it was like, you know, how is this? Why, you know, da da da. And there was a shift in the late noughties, early teens into explainability, where you could literally get your doctorate in explaining why the AI arrived at this. Is that still going on? Is that still a dominant feature of the industry?
\n\nMIKE: [laughs] It's still hard --
\n\nDAVE: What's going on with explainability? It's still hard?
\n\nMIKE: It's still hard [laughs]. I'll say that. It's still hard. Again, these things are bigger than we can fit in our head. So, somehow, you have to come up with a signal that we can comprehend [chuckles] in something that's far vaster than you can fit in your head. Explainability is still an active area of research. Go ahead, Taylor.
\n\nTAYLOR: And I think that's especially true in the areas of, like, transformers and neural networks and these larger models with many layers and tons of neurons. But in terms of some of the more basic machine learning approaches, those are fairly easy to explain or are responsible for explaining some of our decisions using these models here at Acima. And in the case of decision trees, we'll basically say you are on the wrong side of, like, these splits in the tree. Like, your credit score was too high or too low, or your income was too high or too low.
\n\nAnd in the context of, like, a trees classifier, you can explain those splits a lot easier than, I guess, the inner layers of a neural network and what those individual neurons meant and why they fired one way for you and worse for another person. So, I do think that is worth spending some time on explainability. Because if you don't understand why your model is producing some outputs, then it lacks in utility in that respect, especially in the area of finance that we're in.
\n\nSo, we've never deployed a neural network or something like that. We tend to stick to models that have what's called SHAP predictions or SHAP-supported values. And that's basically a methodology we use to explain prediction output and which features or independent variables lead to the output.
\n\nDAVE: Awesome. Does explainability get into the positive side as well of, like, you get back a prediction, and it's like, oh, this lease is going to become delinquent in two weeks? And you're like, wait, what? Because they made a payment at 3:00 p.m. on a Tuesday, that's why. And you're like, okay, that's dumb. Stop...and then two weeks later, the lease goes delinquent, and they all do. It's like the data is there, and it's predicting. Does explainability get into that kind of spooky [inaudible 51:44] Ouija board stuff?
\n\nTAYLOR: I mean, sometimes there'll be odd predictions from a model that turn out to be accurate, but in retrospect, I think they would make sense. But for the most part, I think most of the decisions are intuitive. And there is some, like, some understanding you can gain just from looking at the decision. We make predictions a little differently from what you described. Like, we're not predicting delinquency. We're basically predicting if the account is good for the company or bad for the company.
\n\nAnd there are certain attributes that make the accounts good, certain attributes that make the accounts bad. It's pretty rare that there'll be an attribute that makes the account good for some strange reason or vice versa. And part of our job is to make sure that doesn't happen. Because that might suggest that the training data was malformed for some reason or it's representing a relationship that's not going to hold true in production, so we'll test to make sure that's not the case. And when we deploy new models, it's definitely something we're looking out for is: why was our input data suddenly not looking like the data we trained on? Like, we've got to do something that will stop this model.
\n\nDAVE: That's awesome. I have follow-up questions, but I'll save them for the next time we talk about this.
\n\nMIKE: Taylor, do you have any final things you'd like to say?
\n\nTAYLOR: I don't think so. I think we've covered a lot. And we can definitely spend another call just covering machine learning and, especially as it pertains to Acima. I would like to extend an invitation to anyone from Acima who wants to learn more or has questions for us; even if it's just a personal project, we're always willing to help and extend an olive branch.
\n\nMIKE: Awesome. Well, thank you. Thank you to our listeners for listening to another episode of the Acima Development podcast, and until next time.
","summary":"","date_published":"2023-11-29T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/9eba5757-2a6b-4e7b-95aa-4a66c26cffba.mp3","mime_type":"audio/mpeg","size_in_bytes":58261651,"duration_in_seconds":3214}]},{"id":"19ed164d-d8c6-4e8c-ac70-df1e5ee5d3b1","title":"Episode 32: Coming Up With Project Ideas","url":"https://acima-development.fireside.fm/32","content_text":"In this episode, the panel dives into the nuances of learning and developing as a coder. They discuss various approaches to learning, such as \"committing\" code every day, even if it's just a tiny chunk, to build fluency and comfort with programming. Mark mentions the trend of long online tutorials aimed to take someone from \"zero to master\" and the varied success of these methods. However, they stress the importance of building foundational skills first and note the ever-increasing capabilities of technology, stating that if you can imagine it, you can code it.\n\nAs the conversation progresses, they focus on managing one's learning through their work environment. There's a discussion on the benefits of aligning one's professional tasks with personal learning goals by steering management toward mutually beneficial projects. They also discuss various approaches to learning from online video tutorials, with some arguing that replicating a project step-by-step doesn't provide real value. In contrast, others see merit in iterative learning, especially when the tutorials are feature-focused. The panel then discusses the importance of balancing this with hands-on coding, experimenting on personal projects, and checking out the latest documentation to stay updated.\n\nThey conclude with an emphasis on adequately utilizing video tutorials and online resources for optimized learning. While video tutorials are helpful, they aren't the end-all solution; referring back to community insights and updated documentation is crucial for growth. They also appreciate the duality in learning methods, acknowledging that there's a time for guided learning through tutorials and a time for experimental, hands-on coding. Overall, the episode serves as a comprehensive guide for developers at all levels, highlighting that the journey of learning and growing in coding is ongoing and multifaceted.\n\nTranscript:\n\nDAVID: Hello and welcome to the Acima Developer podcast. I'm your host today, David Brady. We have a small panel with us today. We've got Eddy Lopez, Kyle Archer. We've got Mark Hymowitz. It's going to be a fun, tight little show. Today, we want to talk about picking projects to learn from. Or how do we pick personal projects? Where do we get the ideas for that? I will just open it to you guys right off the bat. How do you guys pick personal projects? Or what problems do you have?\n\nEDDY: When I first started working with the idea, well, actually, before I even got into the tech industry, right? Here at Acima, I started to discipline myself and be like, hey, I want to learn programming. How can I better rearrange my habits so I can learn and hit the ground running when I do get hired on, et cetera? When I get good enough to convince someone to hire me [laughs]. \n\nAnd my origins when I started learning, I was like, cool, yeah, let me pick up random projects, you know, let me watch a tutorial on YouTube, you know, about someone who is walking me through on how to implement an app on a certain framework, et cetera. So, that was my origins. And I was extremely motivated to do that. \n\nNow, when I was finally able to progress to the point to where I was able to convince someone, \"Hey, yeah, bring me on the team,\" you know, and they accepted, the majority of the bulk of the learning that I have had up to this point has just been business needs, right? Like, \"Hey, Eddy, I need you to implement this. Hey, we need this to work this way. Can you make the changes?\" Under pressure [laughs], I worked pretty well, right? But suddenly, as far as having personal projects to work on, et cetera, has kind of dwindled to better cater to specific business asks. So, the bulk of my learning has been on the job versus personal projects, if that makes sense.\n\nMARK: For me, the first part of personal project was just creating something that didn't exist. Like, my first personal project wasn't some elaborate code or anything complex. It was, hey, I wanted to make an EPUB file of an online book because you can read the book online, but there's no offline version of it. And they didn't sell a paperback or digital copies. My first project was to, hey, how do I create an EPUB file? How --\n\nDAVID: Nice. EPUB, that's like send it to your Kindle, right? \n\nMARK: Yeah, it's a book format just like PDFs and other file formats that you can import into Kindles, iBooks. It's a very generic book file that you could just import and just start reading from. So, my first project was like, hey, I wanted to create an EPUB file for this book. But I didn't want to make it for everything. I wanted to make sure I properly broke it down into multiple EPUB files for each volume of the book. And from there, I started going, hey, I want to automate this. I got into Python and just learning web scraping and trying to automate my process of getting the book from the website and turning it into an EPUB file so I can just read it offline. \n\nAnd that's been my kind of goal since, like, personal projects: build something that doesn't exist. My current personal project is I have so much media now. I can't keep track of where it all is. So, I'm trying to create a web app that can organize it and then be able to use that web app both on my phone and my laptop while having a universal experience.\n\nDAVID: Back in my day, back when the dinosaurs roamed the earth, there was a thing that we kept in our kitchens called a recipe box. And it was just a thing the size of, like, a stack of three-by-five index cards. And when the first PCs were coming out in the '80s when I was a kid, the first program we all went off and wrote...well, the first program was always \"Hello, World.\" \n\nBut, like, the first, like, real big program we always wrote was, hey, let's put recipes on computers. And we were able to, like, transcribe all these recipes into computer format and put them on a floppy diskette and then lose them because floppies were wildly unreliable. But, you know, that was educational as well.\n\nMark, you said something that caught my attention. You came up with a problem. Like, you had the idea after you had a problem. And one of the things that you will hear in the open-source community over and over and over is scratch your own itch. And I think you've nailed that right on the head, right? Find a problem, find something that bugs you, and then figure out how to solve it.\n\nMARK: Exactly. Like, no matter how much I search online, I can find, A, there's a web app for just tracking one thing, or, hey, this is the greatest news app for learning all the new media you want. I just want one app that I can just index to all these things and say, hey, I'm tracking all these things. Where do I go to find it? I have five apps on my phone. I have 13 bookmarks in my browser. I have Amazon and Apple. Where am I keeping all this stuff? \n\nBecause I want to make sure I don't fall behind or forget about it because there are so many things I enjoy, and then I just lose track of them and forget about them. And then I come back, like, months to a year later and be like, oh, I remember that. I liked it a lot. But I'm, like, so far behind now I don't want to...I'm a little scared to actually jump back into it again. Hence, my current project: something that indexes my life so I can actually remember where everything is.\n\nDAVID: I can confirm to you that that is a common itch. And, actually, what I'm going to say I'm going to say this very carefully. I have scratched that itch many times and have never been completely satisfied with my own scratching of that itch. I'm not going to tell you that, \"Oh, good luck with that. You'll never solve it, da da da.\" No, no, no, you're going to learn a ton coming up with partially great solutions to that problem. Pick an itch that's just chronic, right? And just find a way to scratch it, find a way to scratch it, find a way to scratch it. \n\nI gave a talk at a conference years ago about building a planner page. Like, I used to work for Covey Leadership Center years and years and years ago. And so, I designed my own day planner system off the back of that, and I would print them out. And every week, I would print out a single eight-and-a-half by 11 sheet that had the week's plan on it, and then I would fold it up and, you know, stick it in my pocket, and down the road I go. \n\nAnd I ended up writing a thing that would open up a Visio document. This was, like, a Windows automation script that would open up a Visio document, fill in all the dates and stuff like that, and then send it to the printer. And it would run every Monday morning, and I would have a day planner for the week. And then, a few years later—I got into Perl at the time—I automated the Visio scripting thing with a Perl script. A couple of years later, I got into Python, and I just ported it straight over from Perl to Python. And then, when I got into Ruby, I ported it from Python to Ruby. \n\nAnd the interesting thing was is I had written the original version in Perl. And I had not used any object orientation. I had not used any object messaging. It was all just start at line 1 and just go for 1,200 lines of manipulation code. At some point, I stopped printing a Visio document, and I switched to drawing a PDF document myself by hand because [chuckles] Visio quit making Visio. It kind of sucked. But that's the problem with having a project that lives for 20 years, right? It outlives the architecture it's built on. \n\nSo, I got to a point where I was writing this thing in Ruby. And I was literally trying to port it to Smalltalk, which is a very object-oriented language. It's very hard to write imperative scripts in Smalltalk. And I couldn't do it. And it's because I had written this thing in an imperative style so many times that I did not know how to do it in object-oriented. And so, this was, like, a super great learning curve for me or a way to approach a learning curve. And this is a really subtle thing of, like, how do you pick a project to learn? The question is, what do you want to learn, right? \n\nWhen I ported this from Python to Ruby, I had two goals in mind: one is, I wanted my stupid planner sheet to work again. I just needed to solve that itch. But the other thing was I wanted to know how to automate this from Ruby, the same kind of automation that I was doing from Python. And I did not want to know how to solve the problem of drawing a planner sheet. That was solved. That itch was well scratched. \n\nBut now I wanted to learn this new language, and I wanted to learn this automation system. And I wanted to have the planner sheets working again. Those were the itches that I wanted scratched. So, it's a really important thing to think about what exactly is the itch that you want. And sometimes, finishing the project isn't the itch. Does that make sense?\n\nMARK: I know exactly what you mean. Besides, like, my current project, I've had several other projects over the year where the itch was just thinking of the project or just starting out some of it and then just getting a bare-bones thing working. Like, there's many different phases to the itch.\n\nDAVID: So, okay, I have a trick question. And that kind of sets up everyone to understand that this is a trick question. But I'm going to ask it with a straight face, and then we can decide...we can get into answering it, like, straight. And then, we can get into, like, why it's a trick question and what is the trick here. Big project or little project? Should you tackle, like, oh, hey, I'm going to go learn this web framework, and I'm going to do full-stack JavaScript to database and back again, or should you take a little, tiny thing like, oh, hey, I want to boldface the titles in all of the EPUBS in this directory?\n\nMARK: I'd say little projects are better. You have incentives of thinking, hey, this isn't a lot of work. You can get this done over a period of time. But you should try and have an idea that have these little projects stacked on top of each other or expand on each other so that, eventually, it becomes a fairly big project. But you never thought of it as a big project. You always thought of it as many small projects.\n\nDAVID: Nice. I like that answer. You've got half of the trick figured out. When would you want to tackle a big project?\n\nMARK: I guess that depends on, like, what the problem is I'm trying to solve.\n\nDAVID: The trick to it is that it's the exact same answer, just in the other direction, right? You can take on a big project. How do you take on a big project? Well, you start breaking it down into smaller and smaller things, right? On one end, you can start small and stack your way up. On the other end, you can start big and crack your way down. \n\nI tackled learning Ruby and Ruby on Rails in, like, 2005 because it looked like a really interesting language. And I was making a good living as a PHP programmer, but I hated PHP. And I thought Ruby looks like a really interesting language. I want to get paid doing this. So, I jumped straight into; I'm going to learn this whole darn framework from tip to tail and just grind my way all the way down through it and see how far I can get. So, the itch there was I wanted a job. Does that make sense? I wasn't trying to learn how to stack up bits and bytes. I was trying to learn how to get paid.\n\nMARK: I understand that feeling. But my experience is, like, with a school, like, I had a teacher who gave us one large project, but instead of having us build the whole project at once, she would make us build each portion of the project over the quarter. If you fail to make even one portion of the project, you were going to fail that class.\n\nDAVID: Wow.\n\nMARK: Because you just couldn't build on what you had achieved. \n\nDAVID: Yeah, that's a great way to teach someone how dangerous the waterfall process is [laughter]. You tripped in week one. Congratulations, you're going to flunk the entire year. That seems a little excessive. Although I guess that would be an important lesson, wouldn't it?\n\nMARK: Yeah. Anyway, how do you guys think of project ideas?\n\nKYLE: Well, as far as coming up with, like, project ideas, for me, I look at kind of just issues that I run into in my daily life, maybe not just issues but just, like, things that I think could be more convenient or make my life easier for me. Like, you know, my dream project...I worked in restaurants for a really long time. You know, I've used ten different POS systems, you know, point of sale systems for selling different stuff. You know, there's a nickname for POS, but we won't go into it. \n\nBut, you know, dream project: I've always wanted to make my own POS just because, you know, I think I have valuable insight just working in the industry. So, I think there's at least some part of me that might be able to do some things better than, you know, the big competitors: Square, Toast, whatever. Obviously, that's a long shot to dream. \n\nBut more, like, reasonable more, like, viable things, I suppose, is I'm really into chess. So, I really always wanted to create some kind of application where it's like, oh, I can record all my chess games and figure out a way to, I don't know, make some algorithm or study some books into my site that's able to, like, tell me where my weaknesses are or, you know, things like that. So [inaudible 12:31] will improve my game. I guess, really, it's just personal things that I think I can improve. That's usually inspiration for projects.\n\nDAVID: Absolutely. That is awesome. One of the best examples of scratching your own itch...I had a friend. He and I had worked in the gaming industry together, the video game industry. And we went our separate ways after leaving that company. And he decided to go back to school. He had been making six figures as a developer, and he went back...because he was going back to school, he had to work part-time, and part-time pays entry-level. So, he was making, like, seven bucks an hour doing data entry. \n\nAnd his job was to key in all of these checks, like, literally paper checks that people were writing with dollar and cent amounts. And he had to balance up the till at the end of the day with, you know, like, typing these 150 check amounts. And he would be off by a penny, or he would be off by 11 cents somewhere. And he'd have to go back through all these things. And he was on, like, a Windows, you know, like, Windows 95 or Windows 2000, just a desktop and with, you know, no tools, no dev environment, nothing. But he's like, this seems like a problem that a computer would be really good at solving. \n\nAnd so, he went home. He wrote a little application in Visual Basic that let him key in all of the checks to copy and paste them because he could copy them out of the system that he was entering them into. So, he would key in all the checks into the system. And he would be off by 22 cents somewhere. And he would select the whole thing–paste it into his app. \n\nAnd all his app would do is it would just go through every single item and add one and subtract one from every item. It would swap every pair of digits. And after each change, it would add up everything and check to see, you know, do I have the same wrong answer that you do? And if I do, I'm going to show you what mistake I made so that you can go look for it and see if that's the mistake that you made. \n\nAnd he went from spending, like, 30 to 90 minutes a day tracking down, you know, transposition errors in his ten-keying to just copying and pasting and getting these answers out. And the hilarious bit is, because programmers are terrible at optimizing their time, he probably spent 15 hours writing the application to solve that kind of problem. And so, it was probably a wash by the end of, like, the semester. He probably had gotten those 15 hours back, probably. And if he worked another semester, he probably would have been time ahead. \n\nBut I think it was really, really neat for him to spend 15 hours doing something he loved to solve a problem that really pissed him off. And, in a way, it's an immediate victory because he's spending time doing what he loves in order to not have to spend any time doing something he hates. \n\nSo, it's not really, like, a 15-hour, you know, loss against a half an hour gain. He's, like, the very first time I pasted this in, and it found my error right off the bat; I sat back and pumped both fists in the air and just went, \"Yes!\" And everybody was looking at me like, \"What? What's going on?\" He's, \"Oh, never mind, I just found what check I messed up. I'm off by 22 cents. And I had keyed in a minus 11 instead of a plus 11, and that's why I'm off by 22.\" That kind of thing. \n\nI think it's a lot of fun to, like, scratch your own itch. Find out what bugs you because when you're done with it, instead of going, \"Oh, I can't believe I spent all this time working on this stupid thing, and now I'm just happy that it's over,\" you're like, \"Ah, I got to spend all this time learning this really cool thing. And now I have this cool tool.\" So, it's like you're doubly ahead instead of, like, just trying to struggle to break even.\n\nMARK: What's also nice is having that tool to look back on and whenever you're, like, working in the same language again, and going like, how did I do that again? Oh, right, I built that within my app. Let me see if I can find the code. \n\nI once interned at a place where they had me write the same program twice, once in Python, once in...I'm forgetting the other language. And I still had a copy of both programs in my GitHub repo. So, I was referring back to the Python version, going like, I definitely did this before, and the documentation hasn't changed. But, like, how did I do it in Python? That helped me understand the API a lot quicker than trying to relearn the entire documentation again.\n\nDAVID: You've fallen neatly into the trap that I have set for you. You have stepped perfectly into a segue to something that I wrote down before coming on the show today, which is that I love really small tactical learning. Like, I love to just sit down and go, you know, I don't have a built-in sort of method. How am I going to do this? Or how do I do this thing in Python? That kind of thing. I know how to do it in Ruby. How do I do it in Python? \n\nSo, there's two repos that I keep on GitHub; one is just called bin. And bin is always in my path. And anytime I need to do anything from the command line––if it's more than 20 characters long or it's hard to remember, I will write a script and put it in there. And my scripts do two things: one is they do the thing I need to do, and the other one is they print the thing on the screen the way it needs to be done. \n\nSo, I see the correct command fully typed out. That way, if I ever don't have my script folder with me, I'm like, oh, yeah, yeah, I remember. It's dash dash force, or whatever, right? Whatever the options are to that particular script. And so, that's like, super, super useful. \n\nAnd so, bin is this place with tiny, tiny solutions, right? I literally wrote a thing to remember when I create a pull request on GitHub. I wrote a thing called git set PR. So, I can go in, and I can say, okay, this branch is PR 10902. Then I wrote two more scripts; one called git get PR, which then just says, oh, you're in this folder, and you're on that branch. Yeah, you made a pull request for this, and you told me it was 10902. Go nuts. \n\nAnd then the other one I wrote was because I don't want to have to open a browser and type in github.com, slash the name of the company slash name of the project. The computer knows all that. So, I wrote a thing called git open PR that opens up the git config, finds the fetch URL, where is it on GitHub, what's the repo name. And then just puts in the slash pull and then the PR number, which was recorded earlier. And then it tells the computer, \"Open this in a web browser, please.\" So, I type git open PR, and I'm in a webpage with the PR, super handy. \n\nAnd that's just something that's, like, bothered me off and on. And I got that working, like, yesterday at work. Like, we were in the middle of, like, deploying three PRs, and I was switching back and forth between them. And I'm like, this is annoying me. It's making me crazy. I'm just going to switch back and forth between these. And so, [inaudible 18:56]. \n\nSo, bin is where I keep tiny, tiny, little solutions. But, Mark, you nailed the other side of this. I keep another repo called scrap bin. And scrap bin is where I store fragments or scraps. So, scrap bin is where I'm going to have a thing that says, how do I get the current date stamp in Python? Like, in Ruby, I just know it's time dot now dot star f time. How do I do that in Python? Oh, it's import date time, date time, dot date time, dot...and down the road, you go. But you have to know what module it's in. \n\nAnd if you forget the module, if you're coming from Python to Ruby, you might want to make a little scrap that says, hey, here's how you get the date stamp, and you open...oh yeah, it's time dot now. Okay, cool. That's what I keep in scrap bin is, like, oh, how do I loop over this thing? Or how do I...it's like Python doesn't have a detect method. I might be a liar about that. It might not be detect. Like the ability to loop over a collection and find the first thing that matches some criteria. \n\nAnd I want to say I'm going to get flamed in the comments. You know what? I need to learn, so teach me a lesson, people, if you're listening to this. I think in Python, you have to give it either like a lambda, or you just have to write a loop and loop over the collection, and if you find it, then bounce out. And that's how I ended up solving it, as I recall. This was a couple of weeks ago on the Python team. \n\nAnd I love that Ruby just lets you say collection dot detect or collection dot find, and you give it a block that matches a condition. And that's great. I love it. It's super easy. But I couldn't remember how to do it in Python. So, I ended up writing these four lines of code loop every time I needed the stupid thing. And once I've found a good way to do it, oh, I take it back. I did find a way to do it. You build an enum, and then you call next on it. That's right. \n\nMy point is that's in my scrap bin. I don't have my scrap bin open, or I would have known this off the top of my head, which, by the way, is the value of the scrap bin is: you don't make yourself look dumb on a podcast. But yeah, anyway [chuckles], the point is, I have two repos: one for solutions and one for fragments of solutions, itches that I have scratched in the past. It helps you build the next back scratcher.\n\nMARK: You're reminding me of my...Slack gives you your own channel of just you talk to yourself. And I've been using that as my scrap bin where I'll post any useful commands or pieces of information that I need to remember. Now that we're switching teams, I need to export that entire scrap [laughs] bin into, like --\n\nDAVID: Nice.\n\nMARK: A git repo. You just reminded me of another scratch that I itched recently. It was a...I had a pull request that was, I don't know, 50-60 commits long. And every time I rebased it, I was so concerned about things getting overwritten because of all the merge conflicts that kept popping up every time. I ended up writing an alias to squash the entire branch into one commit, destroying the history, but it put all my changes into a single commit. \n\nSo, every time I get a commit list that's too long, I will squash the branch. That way, it's just all right in that nice, one commit. So, even though it gets rid of the history, it gets rid of, like, all the conflicts or at least most of the conflicts that you have when doing your rebase. And the other concern, I added conditions to it to say, hey, if on master, if on develop, if on main, abort because I don't want to be the guy responsible for erasing our entire [laughs] Git history.\n\nDAVID: Yeah, I've got a thing in my bash prompt that will check to see what is the current branch that we're on. And yeah, in my bin folder, I have a script called git current branch, you know, git space current dash branch, and it tells you what the name of the current branch is. And there's a peer script in my bin folder called git main that gets the main because five years ago, the master branch was just master. \n\nAnd that's become problematic in some cultures here in the West, especially because it's problematic language. So, there are people that are switching to a main branch called main or a branch called develop. Well, now you have this problem that, like, what do we call the master branch, right? If we can't call it that anymore because, problematic. \n\nSo, I wrote a thing called git main that figures out what is the name of your main branch. And when I put the git branch in my bash prompt, if it's the main branch, it will bold white text on a red background, like just a warning label in your bash prompt letting you know, hey, you are on the main branch, right? Have a care. Go cautiously. But if you're on a story branch, it turns green. And I find this, like, super, super helpful, as, like, just a little warning flag that says, hey, maybe don't squash the entire branch history right now.\n\nMARK: [laughs] Yeah.\n\nDAVID: There's two fragments that I ended up writing. One is called git is clean, that checks to see if you've got any files just hanging out modified and not committed. And a lot of my git tinkering operations, the first thing they'll do is check to see, do you have modified changes that are staged or that are modified and not staged? Maybe you don't want to remaster this branch right now. Maybe you don't want to pull in everything and rebase the main branch back into this. You're going to clobber something important. So, I will use that git is clean all the time. \n\nAnd yeah, and then the other one is, are you on the main branch? If you are, maybe don't do the thing you're doing, or if you do, you need to rerun this script again but run it with dash dash force or dash dash––I know what I'm doing. Let me shoot myself in the foot. \n\nMARK: [laughs]\n\nDAVID: Force is a lot simpler to type. By the way, for the people that have gone to their keyboards to yell at me, it's a list comprehension in Python that then returns something that's enumerable. And if you call next...you build a list of all the things that match the criteria, and then you call next on it, which gets the first item from the list. And I believe that's lazily evaluated. So, it's not actually, like, doing dot map dot first. \n\nIt does actually lazily evaluate through the generator, through the list comprehension to find the thing that you want. So yeah, you say item for item in collection if, and then you give it the matching criteria. And then, you wrap that whole thing in a call to next, which returns the first one. And I got that by looking it up in my scrap bin just now. So, there you go.\n\nMARK: It feels like we're going off-topic because, like, our --\n\nDAVID: Oh, yeah, yeah.\n\nMARK: [laughs].\n\nDAVID: The whole point of, like, learning projects is to get off into the weeds, which I think is great. But you're right. \n\nMARK: [laughs]\n\nDAVID: Let me hang a lampshade on this exact problem. Sometimes, the thing that you want to learn is a meta thing, right? So, you want to take a project you already know and use it to do a thing. So, like, if you want to learn how to do TDD, or if you want to learn how to...I did a thing a few years back where I wanted to get in the habit of committing code every single day. Because I was in the habit...at that point in my career, I was in the habit of authoring 1,000-line commits, which meant that I would go for 2,3,4 or 5 days without committing anything to the source code repo. \n\nNow that we're on git and everybody's got kind of a tiny process, and we're like, you know, we're deploying things that are, like, five-line code changes and that sort of thing...but 10-15 years ago, the tools that we had were much more unwieldy, and it made a lot more sense. It was a lot more efficient to just drag a lot more work in one go. And so, I had to train myself to make tiny commits. I had to literally break the habit because if you're going to do something big, you can keep pushing off some important part of your commit. You can keep pushing it off to the end. \n\nAnd by saying I have to commit every single day...and I'll tell you what, I spent better than half of the days in that experiment timeframe frantically writing code at 11:45 p.m. because I had spent all day pushing something important down the line, right? Sorry, I'm off in the weeds again. But this is kind of the point is that I was trying to learn a technique for how to commit. And so, I just picked a project that I was very comfortable with. Largely, it was my bin folder and my scrap bin folder. \n\nI would go learn a thing, figure out how to do the thing, and then write a five-line thing and, push it up and commit it. And that was my commit for the day, and I was done. And now it's very, very easy for me to write stuff and commit. And it's weird in my development process if I'm not writing commits at least every half hour to an hour, which is fantastic. When I'm on a roll and really cranking code, the commits come every five minutes. Honestly, it's insane. So, the point of that is you can take learning projects in a direction where it's not the project itself that you want to learn.\n\nMARK: Learning can happen in weird and strange ways. One of the most interesting things that I've been seeing now is that there's a lot of online videos saying, \"Hey, take you zero to master in X language,\" right? [laughs] And it's, like, a 12-hour long video. I tried going to a CSS one, and I only got about six hours through before I kind of gave up on it. But you learn so much just getting the basics, learning the cool features they have. And it just causes so many new ideas to spring up in your head. \n\nEven though I'm a developer, I kind of wish I took more user design courses now before I graduated from college. Because I'm now just thinking, like, if I can draw down what I want properly, then there's no way in hell I can't code this. We're, like, at that stage with technology where if you can imagine it, you can definitely code it. Like, there are websites that if you scroll downward, it looks like you're moving in 3D space, seeing stars move around you, and just have amazing animations.\n\nDAVID: When CSS 3 and the 3D transformations came out, there were two things that people wrote and put in the browser that were just amazing. One was an asteroids game where they gave you just a little ship from asteroids, and you could turn and flow and fly it around. But you were shooting the document model. Like, you literally could shoot the title off of the webpage. And then you could shoot the pictures embedded. And the page would, like, collapse. They'd literally shoot words out of the [inaudible 28:44]. It was just weird. Like, why would you want that? Well, because it's cool.\n\nMARK: You're reminding me of, like, all the cool Google searches. Like, if you just search—I think it was monkey bear on Google or gravity in Google—amazing things would just happen to the web page. Like, all the text would fall down spaghetti-wise. -\n\nDAVID: Nice.\n\nMARK: Or it would drift around in space.\n\nDAVID: Nice. \n\nMARK: There's probably [crosstalk 29:06]\n\nDAVID: I like “askew.” If you Google the word askew, A-S-K-E-W, that's a fun one. I had to show this to somebody a couple of weeks ago, and it works on a phone. So, if you're just hanging out around, open up Google and type A-S-K-E-W and hit Enter and just, you know, see what happens. \n\nMARK: Oh my God [laughs].\n\nDAVID: I think Mark just did it. Fantastic. \n\nMARK: [laughs]\n\nDAVID: Circling back around, Eddy, you said something at the top of the call. You mentioned you tend to learn things when your boss hands it down to you. This is something that I was kind of in the same way, well, a little bit in the same way. I've always had just, like, this unnatural fascination with learning things. But this taught me how to kind of manage my manager. \n\nAnd I'm curious if you've given any thought, like, if you walk into work and you know that you learn things when work gives them to you, have you ever considered steering your boss into saying, \"Hey, I want you to give me an assignment that lets me do a thing that we can both agree on that I would like to learn, and you would like to have done\"? Have you ever tried playing that game?\n\nEDDY: I have not. But I know that's an option that is given to employees, right? Just recently, we talked about, hey, if you're wanting to work on a codebase from a different team, you're more than welcome to do that, right? And we're open to the idea. As far as me flirting with the idea of doing that practically, I have not, but it would be something to consider, for sure. \n\nDAVID: Absolutely. I learned this from a boss, ironically. I was really passionate about learning stuff, like, on my lunch break. And I was learning crazy stuff that had nothing to do with what work wanted me to do. So, all right, that's fine. I'm just kind of off in the weeds, learning my own thing. And my boss came in and sat down. And she's like, \"Okay, so, I've got this really crazy hail Mary just bat poo crazy idea. And I think you're the guy for the job.\" And I'm like, \"Oh, do tell.\" \n\nAnd she said, \"We've never been able to script our application from an outside language.\" This was back in 2002. And so, she was like, \"I've heard good things about this language called Python. I want you to go learn enough of that language to see if we can embed it and script our application from Python.\" And so, it became my job to learn Python and to figure out how to hack into it and to, like, compile it into our application so that you could write Python scripts to control the code. \n\nSo, I was basically writing, you know, like the Lua console that when you play video games, that you open up the console and type in cheat codes. It was literally that but for a Planetarian controller, which was crazy awesome. And it had never occurred to me to collaborate with my boss on coming up with weird things until she literally walked in and said, \"We were in a team meeting today. And they said, 'Well, we got this crazy idea, but we have no idea if it'll work.'\" And she said, \"Oh, I've got a guy who loves crazy ideas.\"\n\nEDDY: I have a question. So, a lot of us, when we take inspiration on building an app, do you tend to lean towards something that's more stabilized and uniform in a sense that, like, you'll follow a project where it will walk you step by step to implement something that you're wanting to implement, you know, and then you learn that way? Or do you just start from scratch and you just build it from the ground up, and that's your best method of learning?\n\nKYLE: For me personally, I'd say it's probably, like, a combination of both. I don't see any benefit of just, like, pulling up a YouTube video and copying down a project word for word, bar for bar, because, you know, anybody can do that. You just install something and then just copy exactly what they're writing. But I think having a video like that is helpful because you're able to, like, get a basis on, like, what kind of goal you might be trying to achieve, what kind of project you're trying to make. \n\nAnd then, given that foundation, I think it's important for you to, you know, experiment. And that's where I think, like, reading articles online and checking out what other people have to say is helpful because you can start with this foundation of a project and kind of customize it and explore, create as many new features as you can. And I just think that's the best way to get exposed to new technologies.\n\nEDDY: Let me ask you this: do you think it hurts you in the long run to watch a video tutorial on how to build something?\n\nKYLE: I think if you watch the video and then just copy everything down exactly, absolutely. Like, you know, I could go, you know, watch a three-hour video on how to make a glorious full-stack application, and then I'll do that six times and then put them all on my resume and be like, hey, look at what I did. Like, these are my skills. And then I actually get to the position, or I get to the interview, and I have zero idea what I'm talking about. It's definitely a negative.\n\nMARK: I'm going to have to push back a little. I've done some of those online projects. And it's like, I agree, doing one large video project is bad. But if you're following, like, say, a learn the language guide where they take one project, iterate through it, or make several copies of the same project and then tweak each one separately so you learn the language, I find those helpful. I've done one of those to learn how the Vue framework works, as well as I did the same thing with the CSS. \n\nSo, again, one large project is not helpful, but finding a video that says, \"Hey, you're going to make several, maybe a dozen projects throughout this video. All of them are going to be very bare bones, but they're each going to go over highlighting a different piece of code or how something works within this language,\" I find those useful because then you can actually see, hey, here's a prime example of what this code does, and a bare-bones method of how it's implemented.\n\nKYLE: Yeah, I mean, I think that's fair. I think for learning purposes, it's definitely, like, just going through a video and kind of mocking out the steps going through how, you know, how to actually start doing something; I think that is definitely beneficial. But I wouldn't really consider those to be, like, projects per se. \n\nYou know, my definition of projects are more something that you come up with that, like, has some kind of application that is useful to you or other people that you don't just copy online because, you know, there's a million copies of every single one of these videos. You know, there's a million different people who all made the exact same project. So, it's like, it doesn't add any additional usefulness to do the exact same thing. So yeah, for learning purposes, that definitely is true. Following a video would help. But, like, that's just...in my definition of what a project would be, it doesn't quite fit the criteria, if that makes sense.\n\nDAVID: That's actually really well put. My initial answer to Eddy's question was: it depends. And you guys just beautifully represented both sides of the it depends. There's a time when you want to just, you know what? I don't need to scratch an itch. I'm in a completely foreign land. Please show me how to build back scratchers. And that's nice to have. Well, we start here, and we build all the way to here. And it's undirected. I'm not trying to finish anything. \n\nAnd then, there's other times where it's like, no, just tell me how to get this out of the database and transform it. I don't even need to know how to build a clock. I just need to know what time it is. And those are both, like, really, really useful.\n\nEDDY: I think I've found when working on personal projects myself, I've got this thing where I'm always wanting to use the latest and greatest. So, videos are great for a start, I feel like, but by the time a video is out, it's old information. Some of it will be applicable. But I feel like I have to go to the documentation to figure out, what have they changed? Why is this function not working? Something like that to where may be a good starting spot, but I always refer back to the documentation in the community to be able to move forward.\n\nDAVID: That's well put as well. There was a set of videos called RailsCasts back in the late noughties that were really, really good. Ryan Bates, I think if I'm recalling correctly, Ryan would put together these videos, and he would explain, here's how you do this in Rails. But he would then peel the top off and say, \"And here's what you're doing.\" \n\nAnd so, he's got...I don't know if it's still up there, but, like, the video that he made that made the biggest impression on me was called “How to roll your own authentication or authorization.” And it was literally how to deal with, like, what Devise or Warden or CanCan what all those things do. And it was super useful because then when we stepped into using Devise or some kind of authentication product, I knew what it was doing under the hood.\n\nAnd 15 years down the line, there's a different way to do this every single time. But every time I open up those tools, I find myself, you know, saying to myself, ah, this is solving that same problem. The same three problems that we had in 2008 we still have today. We just have a different DSL for dealing with them, and that's, like, super, super useful. \n\nWhat's less useful is finding a video from three years after that shows you how to solve that problem in a different language that's now too old to be useful and doesn't show you what the underlying problem is. It's like, oh yeah, that's a coat of paint on a different house. And it tells me nothing about architecture, and it doesn't fit the house that I have now. You run into those, too.\n\nThat is actually pushing us close to time. We had a late straggler join. Ramses, welcome. We're talking about how to pick a project to learn from. You've got 30 seconds to give us our closing thought. Go for it.\n\nRAMSES: Pick something that you're passionate about or not passionate about, something that you hate, or something that's really monotonous and brings you pain, and try to solve that.\n\nDAVID: We've been talking about scratching your own itch, but picking something you are passionate about and then saying that you hate it, beautifully put. There you go. Pick something you love or something you hate. That's a fantastic way to sum it up. Thank you, guys, for coming. This was a lot of fun today. I had a great time talking with you guys. We will see you in a couple of weeks.","content_html":"In this episode, the panel dives into the nuances of learning and developing as a coder. They discuss various approaches to learning, such as "committing" code every day, even if it's just a tiny chunk, to build fluency and comfort with programming. Mark mentions the trend of long online tutorials aimed to take someone from "zero to master" and the varied success of these methods. However, they stress the importance of building foundational skills first and note the ever-increasing capabilities of technology, stating that if you can imagine it, you can code it.
\n\nAs the conversation progresses, they focus on managing one's learning through their work environment. There's a discussion on the benefits of aligning one's professional tasks with personal learning goals by steering management toward mutually beneficial projects. They also discuss various approaches to learning from online video tutorials, with some arguing that replicating a project step-by-step doesn't provide real value. In contrast, others see merit in iterative learning, especially when the tutorials are feature-focused. The panel then discusses the importance of balancing this with hands-on coding, experimenting on personal projects, and checking out the latest documentation to stay updated.
\n\nThey conclude with an emphasis on adequately utilizing video tutorials and online resources for optimized learning. While video tutorials are helpful, they aren't the end-all solution; referring back to community insights and updated documentation is crucial for growth. They also appreciate the duality in learning methods, acknowledging that there's a time for guided learning through tutorials and a time for experimental, hands-on coding. Overall, the episode serves as a comprehensive guide for developers at all levels, highlighting that the journey of learning and growing in coding is ongoing and multifaceted.
\n\nTranscript:
\n\nDAVID: Hello and welcome to the Acima Developer podcast. I'm your host today, David Brady. We have a small panel with us today. We've got Eddy Lopez, Kyle Archer. We've got Mark Hymowitz. It's going to be a fun, tight little show. Today, we want to talk about picking projects to learn from. Or how do we pick personal projects? Where do we get the ideas for that? I will just open it to you guys right off the bat. How do you guys pick personal projects? Or what problems do you have?
\n\nEDDY: When I first started working with the idea, well, actually, before I even got into the tech industry, right? Here at Acima, I started to discipline myself and be like, hey, I want to learn programming. How can I better rearrange my habits so I can learn and hit the ground running when I do get hired on, et cetera? When I get good enough to convince someone to hire me [laughs].
\n\nAnd my origins when I started learning, I was like, cool, yeah, let me pick up random projects, you know, let me watch a tutorial on YouTube, you know, about someone who is walking me through on how to implement an app on a certain framework, et cetera. So, that was my origins. And I was extremely motivated to do that.
\n\nNow, when I was finally able to progress to the point to where I was able to convince someone, "Hey, yeah, bring me on the team," you know, and they accepted, the majority of the bulk of the learning that I have had up to this point has just been business needs, right? Like, "Hey, Eddy, I need you to implement this. Hey, we need this to work this way. Can you make the changes?" Under pressure [laughs], I worked pretty well, right? But suddenly, as far as having personal projects to work on, et cetera, has kind of dwindled to better cater to specific business asks. So, the bulk of my learning has been on the job versus personal projects, if that makes sense.
\n\nMARK: For me, the first part of personal project was just creating something that didn't exist. Like, my first personal project wasn't some elaborate code or anything complex. It was, hey, I wanted to make an EPUB file of an online book because you can read the book online, but there's no offline version of it. And they didn't sell a paperback or digital copies. My first project was to, hey, how do I create an EPUB file? How --
\n\nDAVID: Nice. EPUB, that's like send it to your Kindle, right?
\n\nMARK: Yeah, it's a book format just like PDFs and other file formats that you can import into Kindles, iBooks. It's a very generic book file that you could just import and just start reading from. So, my first project was like, hey, I wanted to create an EPUB file for this book. But I didn't want to make it for everything. I wanted to make sure I properly broke it down into multiple EPUB files for each volume of the book. And from there, I started going, hey, I want to automate this. I got into Python and just learning web scraping and trying to automate my process of getting the book from the website and turning it into an EPUB file so I can just read it offline.
\n\nAnd that's been my kind of goal since, like, personal projects: build something that doesn't exist. My current personal project is I have so much media now. I can't keep track of where it all is. So, I'm trying to create a web app that can organize it and then be able to use that web app both on my phone and my laptop while having a universal experience.
\n\nDAVID: Back in my day, back when the dinosaurs roamed the earth, there was a thing that we kept in our kitchens called a recipe box. And it was just a thing the size of, like, a stack of three-by-five index cards. And when the first PCs were coming out in the '80s when I was a kid, the first program we all went off and wrote...well, the first program was always "Hello, World."
\n\nBut, like, the first, like, real big program we always wrote was, hey, let's put recipes on computers. And we were able to, like, transcribe all these recipes into computer format and put them on a floppy diskette and then lose them because floppies were wildly unreliable. But, you know, that was educational as well.
\n\nMark, you said something that caught my attention. You came up with a problem. Like, you had the idea after you had a problem. And one of the things that you will hear in the open-source community over and over and over is scratch your own itch. And I think you've nailed that right on the head, right? Find a problem, find something that bugs you, and then figure out how to solve it.
\n\nMARK: Exactly. Like, no matter how much I search online, I can find, A, there's a web app for just tracking one thing, or, hey, this is the greatest news app for learning all the new media you want. I just want one app that I can just index to all these things and say, hey, I'm tracking all these things. Where do I go to find it? I have five apps on my phone. I have 13 bookmarks in my browser. I have Amazon and Apple. Where am I keeping all this stuff?
\n\nBecause I want to make sure I don't fall behind or forget about it because there are so many things I enjoy, and then I just lose track of them and forget about them. And then I come back, like, months to a year later and be like, oh, I remember that. I liked it a lot. But I'm, like, so far behind now I don't want to...I'm a little scared to actually jump back into it again. Hence, my current project: something that indexes my life so I can actually remember where everything is.
\n\nDAVID: I can confirm to you that that is a common itch. And, actually, what I'm going to say I'm going to say this very carefully. I have scratched that itch many times and have never been completely satisfied with my own scratching of that itch. I'm not going to tell you that, "Oh, good luck with that. You'll never solve it, da da da." No, no, no, you're going to learn a ton coming up with partially great solutions to that problem. Pick an itch that's just chronic, right? And just find a way to scratch it, find a way to scratch it, find a way to scratch it.
\n\nI gave a talk at a conference years ago about building a planner page. Like, I used to work for Covey Leadership Center years and years and years ago. And so, I designed my own day planner system off the back of that, and I would print them out. And every week, I would print out a single eight-and-a-half by 11 sheet that had the week's plan on it, and then I would fold it up and, you know, stick it in my pocket, and down the road I go.
\n\nAnd I ended up writing a thing that would open up a Visio document. This was, like, a Windows automation script that would open up a Visio document, fill in all the dates and stuff like that, and then send it to the printer. And it would run every Monday morning, and I would have a day planner for the week. And then, a few years later—I got into Perl at the time—I automated the Visio scripting thing with a Perl script. A couple of years later, I got into Python, and I just ported it straight over from Perl to Python. And then, when I got into Ruby, I ported it from Python to Ruby.
\n\nAnd the interesting thing was is I had written the original version in Perl. And I had not used any object orientation. I had not used any object messaging. It was all just start at line 1 and just go for 1,200 lines of manipulation code. At some point, I stopped printing a Visio document, and I switched to drawing a PDF document myself by hand because [chuckles] Visio quit making Visio. It kind of sucked. But that's the problem with having a project that lives for 20 years, right? It outlives the architecture it's built on.
\n\nSo, I got to a point where I was writing this thing in Ruby. And I was literally trying to port it to Smalltalk, which is a very object-oriented language. It's very hard to write imperative scripts in Smalltalk. And I couldn't do it. And it's because I had written this thing in an imperative style so many times that I did not know how to do it in object-oriented. And so, this was, like, a super great learning curve for me or a way to approach a learning curve. And this is a really subtle thing of, like, how do you pick a project to learn? The question is, what do you want to learn, right?
\n\nWhen I ported this from Python to Ruby, I had two goals in mind: one is, I wanted my stupid planner sheet to work again. I just needed to solve that itch. But the other thing was I wanted to know how to automate this from Ruby, the same kind of automation that I was doing from Python. And I did not want to know how to solve the problem of drawing a planner sheet. That was solved. That itch was well scratched.
\n\nBut now I wanted to learn this new language, and I wanted to learn this automation system. And I wanted to have the planner sheets working again. Those were the itches that I wanted scratched. So, it's a really important thing to think about what exactly is the itch that you want. And sometimes, finishing the project isn't the itch. Does that make sense?
\n\nMARK: I know exactly what you mean. Besides, like, my current project, I've had several other projects over the year where the itch was just thinking of the project or just starting out some of it and then just getting a bare-bones thing working. Like, there's many different phases to the itch.
\n\nDAVID: So, okay, I have a trick question. And that kind of sets up everyone to understand that this is a trick question. But I'm going to ask it with a straight face, and then we can decide...we can get into answering it, like, straight. And then, we can get into, like, why it's a trick question and what is the trick here. Big project or little project? Should you tackle, like, oh, hey, I'm going to go learn this web framework, and I'm going to do full-stack JavaScript to database and back again, or should you take a little, tiny thing like, oh, hey, I want to boldface the titles in all of the EPUBS in this directory?
\n\nMARK: I'd say little projects are better. You have incentives of thinking, hey, this isn't a lot of work. You can get this done over a period of time. But you should try and have an idea that have these little projects stacked on top of each other or expand on each other so that, eventually, it becomes a fairly big project. But you never thought of it as a big project. You always thought of it as many small projects.
\n\nDAVID: Nice. I like that answer. You've got half of the trick figured out. When would you want to tackle a big project?
\n\nMARK: I guess that depends on, like, what the problem is I'm trying to solve.
\n\nDAVID: The trick to it is that it's the exact same answer, just in the other direction, right? You can take on a big project. How do you take on a big project? Well, you start breaking it down into smaller and smaller things, right? On one end, you can start small and stack your way up. On the other end, you can start big and crack your way down.
\n\nI tackled learning Ruby and Ruby on Rails in, like, 2005 because it looked like a really interesting language. And I was making a good living as a PHP programmer, but I hated PHP. And I thought Ruby looks like a really interesting language. I want to get paid doing this. So, I jumped straight into; I'm going to learn this whole darn framework from tip to tail and just grind my way all the way down through it and see how far I can get. So, the itch there was I wanted a job. Does that make sense? I wasn't trying to learn how to stack up bits and bytes. I was trying to learn how to get paid.
\n\nMARK: I understand that feeling. But my experience is, like, with a school, like, I had a teacher who gave us one large project, but instead of having us build the whole project at once, she would make us build each portion of the project over the quarter. If you fail to make even one portion of the project, you were going to fail that class.
\n\nDAVID: Wow.
\n\nMARK: Because you just couldn't build on what you had achieved.
\n\nDAVID: Yeah, that's a great way to teach someone how dangerous the waterfall process is [laughter]. You tripped in week one. Congratulations, you're going to flunk the entire year. That seems a little excessive. Although I guess that would be an important lesson, wouldn't it?
\n\nMARK: Yeah. Anyway, how do you guys think of project ideas?
\n\nKYLE: Well, as far as coming up with, like, project ideas, for me, I look at kind of just issues that I run into in my daily life, maybe not just issues but just, like, things that I think could be more convenient or make my life easier for me. Like, you know, my dream project...I worked in restaurants for a really long time. You know, I've used ten different POS systems, you know, point of sale systems for selling different stuff. You know, there's a nickname for POS, but we won't go into it.
\n\nBut, you know, dream project: I've always wanted to make my own POS just because, you know, I think I have valuable insight just working in the industry. So, I think there's at least some part of me that might be able to do some things better than, you know, the big competitors: Square, Toast, whatever. Obviously, that's a long shot to dream.
\n\nBut more, like, reasonable more, like, viable things, I suppose, is I'm really into chess. So, I really always wanted to create some kind of application where it's like, oh, I can record all my chess games and figure out a way to, I don't know, make some algorithm or study some books into my site that's able to, like, tell me where my weaknesses are or, you know, things like that. So [inaudible 12:31] will improve my game. I guess, really, it's just personal things that I think I can improve. That's usually inspiration for projects.
\n\nDAVID: Absolutely. That is awesome. One of the best examples of scratching your own itch...I had a friend. He and I had worked in the gaming industry together, the video game industry. And we went our separate ways after leaving that company. And he decided to go back to school. He had been making six figures as a developer, and he went back...because he was going back to school, he had to work part-time, and part-time pays entry-level. So, he was making, like, seven bucks an hour doing data entry.
\n\nAnd his job was to key in all of these checks, like, literally paper checks that people were writing with dollar and cent amounts. And he had to balance up the till at the end of the day with, you know, like, typing these 150 check amounts. And he would be off by a penny, or he would be off by 11 cents somewhere. And he'd have to go back through all these things. And he was on, like, a Windows, you know, like, Windows 95 or Windows 2000, just a desktop and with, you know, no tools, no dev environment, nothing. But he's like, this seems like a problem that a computer would be really good at solving.
\n\nAnd so, he went home. He wrote a little application in Visual Basic that let him key in all of the checks to copy and paste them because he could copy them out of the system that he was entering them into. So, he would key in all the checks into the system. And he would be off by 22 cents somewhere. And he would select the whole thing–paste it into his app.
\n\nAnd all his app would do is it would just go through every single item and add one and subtract one from every item. It would swap every pair of digits. And after each change, it would add up everything and check to see, you know, do I have the same wrong answer that you do? And if I do, I'm going to show you what mistake I made so that you can go look for it and see if that's the mistake that you made.
\n\nAnd he went from spending, like, 30 to 90 minutes a day tracking down, you know, transposition errors in his ten-keying to just copying and pasting and getting these answers out. And the hilarious bit is, because programmers are terrible at optimizing their time, he probably spent 15 hours writing the application to solve that kind of problem. And so, it was probably a wash by the end of, like, the semester. He probably had gotten those 15 hours back, probably. And if he worked another semester, he probably would have been time ahead.
\n\nBut I think it was really, really neat for him to spend 15 hours doing something he loved to solve a problem that really pissed him off. And, in a way, it's an immediate victory because he's spending time doing what he loves in order to not have to spend any time doing something he hates.
\n\nSo, it's not really, like, a 15-hour, you know, loss against a half an hour gain. He's, like, the very first time I pasted this in, and it found my error right off the bat; I sat back and pumped both fists in the air and just went, "Yes!" And everybody was looking at me like, "What? What's going on?" He's, "Oh, never mind, I just found what check I messed up. I'm off by 22 cents. And I had keyed in a minus 11 instead of a plus 11, and that's why I'm off by 22." That kind of thing.
\n\nI think it's a lot of fun to, like, scratch your own itch. Find out what bugs you because when you're done with it, instead of going, "Oh, I can't believe I spent all this time working on this stupid thing, and now I'm just happy that it's over," you're like, "Ah, I got to spend all this time learning this really cool thing. And now I have this cool tool." So, it's like you're doubly ahead instead of, like, just trying to struggle to break even.
\n\nMARK: What's also nice is having that tool to look back on and whenever you're, like, working in the same language again, and going like, how did I do that again? Oh, right, I built that within my app. Let me see if I can find the code.
\n\nI once interned at a place where they had me write the same program twice, once in Python, once in...I'm forgetting the other language. And I still had a copy of both programs in my GitHub repo. So, I was referring back to the Python version, going like, I definitely did this before, and the documentation hasn't changed. But, like, how did I do it in Python? That helped me understand the API a lot quicker than trying to relearn the entire documentation again.
\n\nDAVID: You've fallen neatly into the trap that I have set for you. You have stepped perfectly into a segue to something that I wrote down before coming on the show today, which is that I love really small tactical learning. Like, I love to just sit down and go, you know, I don't have a built-in sort of method. How am I going to do this? Or how do I do this thing in Python? That kind of thing. I know how to do it in Ruby. How do I do it in Python?
\n\nSo, there's two repos that I keep on GitHub; one is just called bin. And bin is always in my path. And anytime I need to do anything from the command line––if it's more than 20 characters long or it's hard to remember, I will write a script and put it in there. And my scripts do two things: one is they do the thing I need to do, and the other one is they print the thing on the screen the way it needs to be done.
\n\nSo, I see the correct command fully typed out. That way, if I ever don't have my script folder with me, I'm like, oh, yeah, yeah, I remember. It's dash dash force, or whatever, right? Whatever the options are to that particular script. And so, that's like, super, super useful.
\n\nAnd so, bin is this place with tiny, tiny solutions, right? I literally wrote a thing to remember when I create a pull request on GitHub. I wrote a thing called git set PR. So, I can go in, and I can say, okay, this branch is PR 10902. Then I wrote two more scripts; one called git get PR, which then just says, oh, you're in this folder, and you're on that branch. Yeah, you made a pull request for this, and you told me it was 10902. Go nuts.
\n\nAnd then the other one I wrote was because I don't want to have to open a browser and type in github.com, slash the name of the company slash name of the project. The computer knows all that. So, I wrote a thing called git open PR that opens up the git config, finds the fetch URL, where is it on GitHub, what's the repo name. And then just puts in the slash pull and then the PR number, which was recorded earlier. And then it tells the computer, "Open this in a web browser, please." So, I type git open PR, and I'm in a webpage with the PR, super handy.
\n\nAnd that's just something that's, like, bothered me off and on. And I got that working, like, yesterday at work. Like, we were in the middle of, like, deploying three PRs, and I was switching back and forth between them. And I'm like, this is annoying me. It's making me crazy. I'm just going to switch back and forth between these. And so, [inaudible 18:56].
\n\nSo, bin is where I keep tiny, tiny, little solutions. But, Mark, you nailed the other side of this. I keep another repo called scrap bin. And scrap bin is where I store fragments or scraps. So, scrap bin is where I'm going to have a thing that says, how do I get the current date stamp in Python? Like, in Ruby, I just know it's time dot now dot star f time. How do I do that in Python? Oh, it's import date time, date time, dot date time, dot...and down the road, you go. But you have to know what module it's in.
\n\nAnd if you forget the module, if you're coming from Python to Ruby, you might want to make a little scrap that says, hey, here's how you get the date stamp, and you open...oh yeah, it's time dot now. Okay, cool. That's what I keep in scrap bin is, like, oh, how do I loop over this thing? Or how do I...it's like Python doesn't have a detect method. I might be a liar about that. It might not be detect. Like the ability to loop over a collection and find the first thing that matches some criteria.
\n\nAnd I want to say I'm going to get flamed in the comments. You know what? I need to learn, so teach me a lesson, people, if you're listening to this. I think in Python, you have to give it either like a lambda, or you just have to write a loop and loop over the collection, and if you find it, then bounce out. And that's how I ended up solving it, as I recall. This was a couple of weeks ago on the Python team.
\n\nAnd I love that Ruby just lets you say collection dot detect or collection dot find, and you give it a block that matches a condition. And that's great. I love it. It's super easy. But I couldn't remember how to do it in Python. So, I ended up writing these four lines of code loop every time I needed the stupid thing. And once I've found a good way to do it, oh, I take it back. I did find a way to do it. You build an enum, and then you call next on it. That's right.
\n\nMy point is that's in my scrap bin. I don't have my scrap bin open, or I would have known this off the top of my head, which, by the way, is the value of the scrap bin is: you don't make yourself look dumb on a podcast. But yeah, anyway [chuckles], the point is, I have two repos: one for solutions and one for fragments of solutions, itches that I have scratched in the past. It helps you build the next back scratcher.
\n\nMARK: You're reminding me of my...Slack gives you your own channel of just you talk to yourself. And I've been using that as my scrap bin where I'll post any useful commands or pieces of information that I need to remember. Now that we're switching teams, I need to export that entire scrap [laughs] bin into, like --
\n\nDAVID: Nice.
\n\nMARK: A git repo. You just reminded me of another scratch that I itched recently. It was a...I had a pull request that was, I don't know, 50-60 commits long. And every time I rebased it, I was so concerned about things getting overwritten because of all the merge conflicts that kept popping up every time. I ended up writing an alias to squash the entire branch into one commit, destroying the history, but it put all my changes into a single commit.
\n\nSo, every time I get a commit list that's too long, I will squash the branch. That way, it's just all right in that nice, one commit. So, even though it gets rid of the history, it gets rid of, like, all the conflicts or at least most of the conflicts that you have when doing your rebase. And the other concern, I added conditions to it to say, hey, if on master, if on develop, if on main, abort because I don't want to be the guy responsible for erasing our entire [laughs] Git history.
\n\nDAVID: Yeah, I've got a thing in my bash prompt that will check to see what is the current branch that we're on. And yeah, in my bin folder, I have a script called git current branch, you know, git space current dash branch, and it tells you what the name of the current branch is. And there's a peer script in my bin folder called git main that gets the main because five years ago, the master branch was just master.
\n\nAnd that's become problematic in some cultures here in the West, especially because it's problematic language. So, there are people that are switching to a main branch called main or a branch called develop. Well, now you have this problem that, like, what do we call the master branch, right? If we can't call it that anymore because, problematic.
\n\nSo, I wrote a thing called git main that figures out what is the name of your main branch. And when I put the git branch in my bash prompt, if it's the main branch, it will bold white text on a red background, like just a warning label in your bash prompt letting you know, hey, you are on the main branch, right? Have a care. Go cautiously. But if you're on a story branch, it turns green. And I find this, like, super, super helpful, as, like, just a little warning flag that says, hey, maybe don't squash the entire branch history right now.
\n\nMARK: [laughs] Yeah.
\n\nDAVID: There's two fragments that I ended up writing. One is called git is clean, that checks to see if you've got any files just hanging out modified and not committed. And a lot of my git tinkering operations, the first thing they'll do is check to see, do you have modified changes that are staged or that are modified and not staged? Maybe you don't want to remaster this branch right now. Maybe you don't want to pull in everything and rebase the main branch back into this. You're going to clobber something important. So, I will use that git is clean all the time.
\n\nAnd yeah, and then the other one is, are you on the main branch? If you are, maybe don't do the thing you're doing, or if you do, you need to rerun this script again but run it with dash dash force or dash dash––I know what I'm doing. Let me shoot myself in the foot.
\n\nMARK: [laughs]
\n\nDAVID: Force is a lot simpler to type. By the way, for the people that have gone to their keyboards to yell at me, it's a list comprehension in Python that then returns something that's enumerable. And if you call next...you build a list of all the things that match the criteria, and then you call next on it, which gets the first item from the list. And I believe that's lazily evaluated. So, it's not actually, like, doing dot map dot first.
\n\nIt does actually lazily evaluate through the generator, through the list comprehension to find the thing that you want. So yeah, you say item for item in collection if, and then you give it the matching criteria. And then, you wrap that whole thing in a call to next, which returns the first one. And I got that by looking it up in my scrap bin just now. So, there you go.
\n\nMARK: It feels like we're going off-topic because, like, our --
\n\nDAVID: Oh, yeah, yeah.
\n\nMARK: [laughs].
\n\nDAVID: The whole point of, like, learning projects is to get off into the weeds, which I think is great. But you're right.
\n\nMARK: [laughs]
\n\nDAVID: Let me hang a lampshade on this exact problem. Sometimes, the thing that you want to learn is a meta thing, right? So, you want to take a project you already know and use it to do a thing. So, like, if you want to learn how to do TDD, or if you want to learn how to...I did a thing a few years back where I wanted to get in the habit of committing code every single day. Because I was in the habit...at that point in my career, I was in the habit of authoring 1,000-line commits, which meant that I would go for 2,3,4 or 5 days without committing anything to the source code repo.
\n\nNow that we're on git and everybody's got kind of a tiny process, and we're like, you know, we're deploying things that are, like, five-line code changes and that sort of thing...but 10-15 years ago, the tools that we had were much more unwieldy, and it made a lot more sense. It was a lot more efficient to just drag a lot more work in one go. And so, I had to train myself to make tiny commits. I had to literally break the habit because if you're going to do something big, you can keep pushing off some important part of your commit. You can keep pushing it off to the end.
\n\nAnd by saying I have to commit every single day...and I'll tell you what, I spent better than half of the days in that experiment timeframe frantically writing code at 11:45 p.m. because I had spent all day pushing something important down the line, right? Sorry, I'm off in the weeds again. But this is kind of the point is that I was trying to learn a technique for how to commit. And so, I just picked a project that I was very comfortable with. Largely, it was my bin folder and my scrap bin folder.
\n\nI would go learn a thing, figure out how to do the thing, and then write a five-line thing and, push it up and commit it. And that was my commit for the day, and I was done. And now it's very, very easy for me to write stuff and commit. And it's weird in my development process if I'm not writing commits at least every half hour to an hour, which is fantastic. When I'm on a roll and really cranking code, the commits come every five minutes. Honestly, it's insane. So, the point of that is you can take learning projects in a direction where it's not the project itself that you want to learn.
\n\nMARK: Learning can happen in weird and strange ways. One of the most interesting things that I've been seeing now is that there's a lot of online videos saying, "Hey, take you zero to master in X language," right? [laughs] And it's, like, a 12-hour long video. I tried going to a CSS one, and I only got about six hours through before I kind of gave up on it. But you learn so much just getting the basics, learning the cool features they have. And it just causes so many new ideas to spring up in your head.
\n\nEven though I'm a developer, I kind of wish I took more user design courses now before I graduated from college. Because I'm now just thinking, like, if I can draw down what I want properly, then there's no way in hell I can't code this. We're, like, at that stage with technology where if you can imagine it, you can definitely code it. Like, there are websites that if you scroll downward, it looks like you're moving in 3D space, seeing stars move around you, and just have amazing animations.
\n\nDAVID: When CSS 3 and the 3D transformations came out, there were two things that people wrote and put in the browser that were just amazing. One was an asteroids game where they gave you just a little ship from asteroids, and you could turn and flow and fly it around. But you were shooting the document model. Like, you literally could shoot the title off of the webpage. And then you could shoot the pictures embedded. And the page would, like, collapse. They'd literally shoot words out of the [inaudible 28:44]. It was just weird. Like, why would you want that? Well, because it's cool.
\n\nMARK: You're reminding me of, like, all the cool Google searches. Like, if you just search—I think it was monkey bear on Google or gravity in Google—amazing things would just happen to the web page. Like, all the text would fall down spaghetti-wise. -
\n\nDAVID: Nice.
\n\nMARK: Or it would drift around in space.
\n\nDAVID: Nice.
\n\nMARK: There's probably [crosstalk 29:06]
\n\nDAVID: I like “askew.” If you Google the word askew, A-S-K-E-W, that's a fun one. I had to show this to somebody a couple of weeks ago, and it works on a phone. So, if you're just hanging out around, open up Google and type A-S-K-E-W and hit Enter and just, you know, see what happens.
\n\nMARK: Oh my God [laughs].
\n\nDAVID: I think Mark just did it. Fantastic.
\n\nMARK: [laughs]
\n\nDAVID: Circling back around, Eddy, you said something at the top of the call. You mentioned you tend to learn things when your boss hands it down to you. This is something that I was kind of in the same way, well, a little bit in the same way. I've always had just, like, this unnatural fascination with learning things. But this taught me how to kind of manage my manager.
\n\nAnd I'm curious if you've given any thought, like, if you walk into work and you know that you learn things when work gives them to you, have you ever considered steering your boss into saying, "Hey, I want you to give me an assignment that lets me do a thing that we can both agree on that I would like to learn, and you would like to have done"? Have you ever tried playing that game?
\n\nEDDY: I have not. But I know that's an option that is given to employees, right? Just recently, we talked about, hey, if you're wanting to work on a codebase from a different team, you're more than welcome to do that, right? And we're open to the idea. As far as me flirting with the idea of doing that practically, I have not, but it would be something to consider, for sure.
\n\nDAVID: Absolutely. I learned this from a boss, ironically. I was really passionate about learning stuff, like, on my lunch break. And I was learning crazy stuff that had nothing to do with what work wanted me to do. So, all right, that's fine. I'm just kind of off in the weeds, learning my own thing. And my boss came in and sat down. And she's like, "Okay, so, I've got this really crazy hail Mary just bat poo crazy idea. And I think you're the guy for the job." And I'm like, "Oh, do tell."
\n\nAnd she said, "We've never been able to script our application from an outside language." This was back in 2002. And so, she was like, "I've heard good things about this language called Python. I want you to go learn enough of that language to see if we can embed it and script our application from Python." And so, it became my job to learn Python and to figure out how to hack into it and to, like, compile it into our application so that you could write Python scripts to control the code.
\n\nSo, I was basically writing, you know, like the Lua console that when you play video games, that you open up the console and type in cheat codes. It was literally that but for a Planetarian controller, which was crazy awesome. And it had never occurred to me to collaborate with my boss on coming up with weird things until she literally walked in and said, "We were in a team meeting today. And they said, 'Well, we got this crazy idea, but we have no idea if it'll work.'" And she said, "Oh, I've got a guy who loves crazy ideas."
\n\nEDDY: I have a question. So, a lot of us, when we take inspiration on building an app, do you tend to lean towards something that's more stabilized and uniform in a sense that, like, you'll follow a project where it will walk you step by step to implement something that you're wanting to implement, you know, and then you learn that way? Or do you just start from scratch and you just build it from the ground up, and that's your best method of learning?
\n\nKYLE: For me personally, I'd say it's probably, like, a combination of both. I don't see any benefit of just, like, pulling up a YouTube video and copying down a project word for word, bar for bar, because, you know, anybody can do that. You just install something and then just copy exactly what they're writing. But I think having a video like that is helpful because you're able to, like, get a basis on, like, what kind of goal you might be trying to achieve, what kind of project you're trying to make.
\n\nAnd then, given that foundation, I think it's important for you to, you know, experiment. And that's where I think, like, reading articles online and checking out what other people have to say is helpful because you can start with this foundation of a project and kind of customize it and explore, create as many new features as you can. And I just think that's the best way to get exposed to new technologies.
\n\nEDDY: Let me ask you this: do you think it hurts you in the long run to watch a video tutorial on how to build something?
\n\nKYLE: I think if you watch the video and then just copy everything down exactly, absolutely. Like, you know, I could go, you know, watch a three-hour video on how to make a glorious full-stack application, and then I'll do that six times and then put them all on my resume and be like, hey, look at what I did. Like, these are my skills. And then I actually get to the position, or I get to the interview, and I have zero idea what I'm talking about. It's definitely a negative.
\n\nMARK: I'm going to have to push back a little. I've done some of those online projects. And it's like, I agree, doing one large video project is bad. But if you're following, like, say, a learn the language guide where they take one project, iterate through it, or make several copies of the same project and then tweak each one separately so you learn the language, I find those helpful. I've done one of those to learn how the Vue framework works, as well as I did the same thing with the CSS.
\n\nSo, again, one large project is not helpful, but finding a video that says, "Hey, you're going to make several, maybe a dozen projects throughout this video. All of them are going to be very bare bones, but they're each going to go over highlighting a different piece of code or how something works within this language," I find those useful because then you can actually see, hey, here's a prime example of what this code does, and a bare-bones method of how it's implemented.
\n\nKYLE: Yeah, I mean, I think that's fair. I think for learning purposes, it's definitely, like, just going through a video and kind of mocking out the steps going through how, you know, how to actually start doing something; I think that is definitely beneficial. But I wouldn't really consider those to be, like, projects per se.
\n\nYou know, my definition of projects are more something that you come up with that, like, has some kind of application that is useful to you or other people that you don't just copy online because, you know, there's a million copies of every single one of these videos. You know, there's a million different people who all made the exact same project. So, it's like, it doesn't add any additional usefulness to do the exact same thing. So yeah, for learning purposes, that definitely is true. Following a video would help. But, like, that's just...in my definition of what a project would be, it doesn't quite fit the criteria, if that makes sense.
\n\nDAVID: That's actually really well put. My initial answer to Eddy's question was: it depends. And you guys just beautifully represented both sides of the it depends. There's a time when you want to just, you know what? I don't need to scratch an itch. I'm in a completely foreign land. Please show me how to build back scratchers. And that's nice to have. Well, we start here, and we build all the way to here. And it's undirected. I'm not trying to finish anything.
\n\nAnd then, there's other times where it's like, no, just tell me how to get this out of the database and transform it. I don't even need to know how to build a clock. I just need to know what time it is. And those are both, like, really, really useful.
\n\nEDDY: I think I've found when working on personal projects myself, I've got this thing where I'm always wanting to use the latest and greatest. So, videos are great for a start, I feel like, but by the time a video is out, it's old information. Some of it will be applicable. But I feel like I have to go to the documentation to figure out, what have they changed? Why is this function not working? Something like that to where may be a good starting spot, but I always refer back to the documentation in the community to be able to move forward.
\n\nDAVID: That's well put as well. There was a set of videos called RailsCasts back in the late noughties that were really, really good. Ryan Bates, I think if I'm recalling correctly, Ryan would put together these videos, and he would explain, here's how you do this in Rails. But he would then peel the top off and say, "And here's what you're doing."
\n\nAnd so, he's got...I don't know if it's still up there, but, like, the video that he made that made the biggest impression on me was called “How to roll your own authentication or authorization.” And it was literally how to deal with, like, what Devise or Warden or CanCan what all those things do. And it was super useful because then when we stepped into using Devise or some kind of authentication product, I knew what it was doing under the hood.
\n\nAnd 15 years down the line, there's a different way to do this every single time. But every time I open up those tools, I find myself, you know, saying to myself, ah, this is solving that same problem. The same three problems that we had in 2008 we still have today. We just have a different DSL for dealing with them, and that's, like, super, super useful.
\n\nWhat's less useful is finding a video from three years after that shows you how to solve that problem in a different language that's now too old to be useful and doesn't show you what the underlying problem is. It's like, oh yeah, that's a coat of paint on a different house. And it tells me nothing about architecture, and it doesn't fit the house that I have now. You run into those, too.
\n\nThat is actually pushing us close to time. We had a late straggler join. Ramses, welcome. We're talking about how to pick a project to learn from. You've got 30 seconds to give us our closing thought. Go for it.
\n\nRAMSES: Pick something that you're passionate about or not passionate about, something that you hate, or something that's really monotonous and brings you pain, and try to solve that.
\n\nDAVID: We've been talking about scratching your own itch, but picking something you are passionate about and then saying that you hate it, beautifully put. There you go. Pick something you love or something you hate. That's a fantastic way to sum it up. Thank you, guys, for coming. This was a lot of fun today. I had a great time talking with you guys. We will see you in a couple of weeks.
","summary":"","date_published":"2023-11-15T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/19ed164d-d8c6-4e8c-ac70-df1e5ee5d3b1.mp3","mime_type":"audio/mpeg","size_in_bytes":42929756,"duration_in_seconds":2358}]},{"id":"d95d0a76-24a8-4eb6-b047-5b0c37e44182","title":"Episode 31: Should I Be A Team Lead?","url":"https://acima-development.fireside.fm/31","content_text":"The panelists discuss the role of a team lead in a software development context. Mike shares a personal story about a family hike and draws parallels between being a team lead and guiding a group of hikers. The discussion revolves around the challenges and benefits of being a team lead, considering factors such as size, experience levels, and the balance between technical contributions and leadership responsibilities.\n\nAfton, Matt, and Eddy share their perspectives on the role of a team lead, emphasizing that it can vary greatly depending on the team's dynamics and the individual's career goals. They discuss how being a team lead can provide opportunities for mentorship, architecture design, and a broader understanding of project management.\n\nOverall, the conversation highlights the importance of considering one's career goals and the specific circumstances of the team when deciding whether to take on a team lead role and how it can enhance one's skill set and career trajectory. \n\nTranscript:\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. Today, we are going to be talking about being a team lead, specifically being a team lead. Why or why not? There's often a choice that you have in your career, and team lead starts you down a path sometimes toward being more involved in leadership. There's trade-offs involved there. \n\nYou know, to have a good conversation, we have several current or former team leads. We have Afton with us, who has been a team lead. We have Jared, who is currently a team lead over at QA team. And we have Matt, who is currently a team lead over an engineering team. Justin, have you been a team lead before?\n\nJUSTIN: Yeah. \n\nMIKE: I figured. And we also have Eddy with us, who has not yet been a team lead. I would like to, as usual, start our discussion with a story to kind of guide the discussion a little bit. And I've been thinking about this and how we might lead out. I decided I'm going to start by talking about a family vacation I took last year to Colorado. On the way out, we weren't quite where we were going yet. We ended up going to the Great Sand Dunes National Park. I think it's one of the less visited ones, and it's really beautiful. \n\nWe stopped in the Denver area. I don't remember exactly where it was, so I can't tell you [laughs] precisely. But we wanted to get some fresh air. And we went for a hike. One thing I learned from my dad, which is a really good idea, is that when you're going for a walk or hike together as a family, it is a great idea to have the youngest or the slowest person on the group that you're with take the lead, be the person in front. The strongest walker or hiker you put in the back, and there are really compelling reasons to do that. \n\nIf you put the fastest person in front, then they will have to look behind them regularly to stay together with everybody else. And pretty soon, they'll be way out ahead, and the group is all separated, which is a bad situation if you ever want to coordinate. That was particularly important back in the days before cell phones. But it works out great. I do the same thing with my family. I generally have the youngest person in front, and then we follow their pace. It works out pretty well.\n\nMATT: That's how wolf packs operate. \n\nMIKE: Is it? That's good to know. It's just a really effective way to get everybody going at the same pace. We went on this hike. Like I said, it was beautiful. And we got up to a good stopping point where there was a loop that went around a small peak that [inaudible 02:27]. And my oldest son was looking at that peak up ahead, and he thought, I'd really like to do that. And he still had the energy, right? He really wanted to go ahead and do that loop. Or he actually just wanted to go straight up the mountain. [laughs]\n\nI said, \"You can go around the loop. There's probably a trail on the backside.\" And everybody else was kind of tired out and wanted to go down. In the end, we kind of compromised. I went with my oldest son. And we quickly went and did the loop around the top. He went up over to the very top, and I went around the side. And we met, and then we came down, and we met the rest of my family. My wife went with my younger kids; them go out in front. We thought we'd catch up to them before we got to the bottom, but they actually beat us by a little bit. \n\nI'm telling this story for a reason. My wife was an excellent team lead because she stayed with the people who needed guidance through the entire hike. My oldest son was the strongest hiker, but he did not stay with the team. He was just really hungry to go get to the top. And there was nothing wrong with that, right? It was great. You know, he's peak age physically. [laughs] So, you know, it's great that he wants to do that. But it meant that he wasn't really a good candidate to lead the rest of the group.\n\nContrasting the differences between what my wife did in staying with the younger kids the entire time, making sure she never left them behind, and my oldest son, who's just really eager to go and get to the top, I think, provides some perspective as to points that all of us may find ourselves in at different points of our career. Being in either position isn't necessarily bad, but they are different. And you kind of need to commit yourself to a role if you're going to be in one or the other. \n\nBut, sometimes, you're going to be an individual contributor, and you just want to get to the top. There's some value there in contributing a lot of code to the team. And sometimes, you can provide more value in helping others along and making sure they get to where they're needing to go. I thought that was, in my mind at least, a good way to kind of frame this conversation. \n\nI'd also like to add that joining us a little bit late is Ben, who's also a team lead and has been a team lead multiple times in the past. So, I think I'm just going to open the question. And what are your thoughts, particularly towards the team leads or former team leads? What are your thoughts about the contrast between being a team lead and not a team lead, and why you would or not take that position?\n\nAFTON: I had some thoughts while you were telling your story because I was a team lead over, at first, 8 to 10 engineers. That dwindled down a few for the longer term. But a few months back, I moved to a new team, back to being an individual contributor. And the dynamics of my new team were so different than I had experienced because the team was much smaller. The average engineer had a lot more experience than on my prior team. \n\nSo, as you were telling your story, I was thinking the leader of the hike would have a vastly different experience and vastly different demands upon them, depending on who they're hiking with. You know, you may have really young, inexperienced, or out-of-shape hikers [laughs] and also very skilled hikers. And keeping them together it takes more work or more coordination, more communication, more group understanding of people's levels and capabilities, and how you can bring those together to meet in the middle. \n\nVersus if your whole group is very skilled, it's going to take a lot less overhead to keep that group in sync with each other and moving along together. Whether that group is all skilled or all inexperienced, it's largely the same. The overhead of managing that group will be, I think, much simpler. [laughs] \n\nThe broader the levels of experience of those team members, the more work it is for the leader to keep everyone together. And the skills required of the leader can be different, so high communication and collaboration and making sure everyone understands each other, so people skills and team building. And you need to know who you're going to be leading, what the dynamics are of that group, the skill levels of that group, in order to ever even start to think, is that the challenge I want to take right now? Is that going to get me where I want to go in the future?\n\nMIKE: That's a fascinating insight. You're saying that being a team lead is not one thing necessarily. It's going to depend a lot on the team that you're working with.\n\nAFTON: Yes, absolutely. The team that I was leading was, I would say, majority junior developers with a sprinkling of very skilled developers, and even developers from different parts of the world. So, I had a few team members in India. So, also cultures of the different team members can come into play as well. \n\nAnd when I moved to my new team that I'm on currently as an individual contributor, most of the team members are very skilled have a lot more experience generally. And also, everyone is local. [laughs] We can all get together and sit by each other, which makes it easier to understand one another, work together, build some sense of teammanship, easier to manage overall. \n\nSo, yes, the dynamics of the team, I think, will change what's required of the team lead, the skills that they're going to need to help their team be successful, and change the experience of what the team lead can then gain from the experience of leaving the team.\n\nMATT: I strongly agree with that statement. You know, as Afton was just saying, I believe, currently, my team is represented in six different countries. And that adds a little bit of complexity because of scheduling, some language barriers occasionally, and just getting the right people on the right project so the communication can be there. \n\nOne thing I think a lot of people worry about is if they become a lead, that they aren't going to be able to contribute. Well, sometimes that's true. And you may not be writing a lot of code like you are as an individual contributor. Your contribution aspect is still there. It's just in different areas. \n\nHere at Acima, our leads do a lot of architecture, and lead the design flow, and help with requirements, and a lot of the higher-level stuff that, as a contributor, you don't get as much experience doing. So, it really depends on where you want to go in your career. But I would highly recommend, if given the opportunity, everyone take the opportunity to lead a team at least once and get that experience.\n\nMIKE: So, Matt, you say that it's worth doing at least once. It's a valuable experience, even if you don't stick with it.\n\nMATT: Absolutely. I've done this a number of times. I enjoy the role personally because I love helping lead the architecture and helping make some of these business decisions, where you might not have the opportunity as an individual contributor because you aren't in the right groups, you know, for instance, in meetings, things like that. I know everyone says they hate meetings, but they're a necessity. And if you want to build good software, it's vital to have that understanding.\n\nMIKE: You mentioned the meetings; that will probably be a recurring theme. If you're going to be doing some leadership, you're probably going to have to meet with some people, which means that you're going to have a higher meeting load than you would otherwise. It's just intrinsic to the nature of the role.\n\nEDDY: Can I add I feel like there's a stigma with being a team lead. There's an association with being bombarded with meetings. So, as someone who enjoys thoroughly coding on a daily basis and constantly contributing to a codebase, would that individual be a prime candidate to the same [inaudible 10:22] position?\n\nMIKE: I might refer some to what Afton said [laughs] that --\n\nMATT: I'd agree.\n\nMIKE: It's going to depend a lot on what team you're working with. If you're going to work with a large, diverse team, probably going to be a lot of demands placed on you, and you're probably not going to have much time to also be an individual contributor. It really does depend a lot. I've had times when I was leading a team, but I'd still spend most of my time coding. And, generally, that was with a fairly small team. And I still had lots of time to code. And I've had times when I had almost no time to code. It really depended on the constraints that were on me.\n\nMATT: Because our listeners may or may not know much about Acima and our structure, I came from a smaller team initially. And, on that team, at the time, we were extremely small. In fact, our team name was Nano. Our lead was able to write a lot of code most of the time because we were a very senior team. And we just kind of divided up projects and went at them. So, there wasn't a whole lot of guidance that he had to provide to us. \n\nWhereas, as Afton stated, the Atlas team is larger and has a lot more junior representation. So, it's a different role as a lead, a lot more mentorship, a lot more guidance, different tool set to lead that team as it is a small, more senior type team.\n\nAFTON: I've been thinking a little bit about this. Eddy's question seemed to be kind of saying, when would this be a good time? [laughs] Like, I've done the team lead for, you know, a year, year and a half, and still love to sit and just write code. Going back to individual contributor, I was in heaven [laughs], spending a whole day writing code again.\n\nMIKE: [laughs]\n\nAFTON: Super fun. But that doesn't mean I didn't love the new skills I was developing and the new challenges I faced as a team lead. My situation was that I had been professionally developing for about three and a half years, is all before I started acting as team lead. And, at the time, I had been around the longest. I had a lot of business knowledge and a good foundation of technical skills. So, I felt like I could be a good mentor. Even if I was lacking in some technical skills, we did have some more experienced developers very available to me and on my team who I could rely on to help with technical leadership.\n\nI do think it's an amazing experience that everyone could benefit from. You know, if you're given an opportunity, think about, well, first of all, the team dynamics of who you're being asked to lead, what it might require of you to lead, and how much time that might leave you to continue developing your technical skills. And if there's potential that you won't have much time, then to realize that you might start to feel like you're falling behind in your technical development, your own technical development, if it requires so much of the other skills to lead a team. But if you are being asked to lead a more experienced team, then you may have more time to continue working on your own development. \n\nI think it's really important to look ahead in the future. Think, a year from now, if I take this role and this is what I see it looking like, a year from now, is that going to move me ahead in my career and where I want to go? Or could this potentially be sidetracking me to somewhere where it might actually hinder my ultimate goal? \n\nSo, think ahead of the future: a year from now, am I going to be glad that I did this? Is it going to put me in a better place? Or could this somehow put me in a worse place [laughs] hold me back from my ultimate goal? So, considering your goals is very important. Think about that and take the time to know where you want to be and to say, a year from now, where do I want to be? Two years from now, where? Five years from now, where? And now, does this fit within a path to get me there?\n\nMIKE: Well said, Afton. You said --\n\nMATT: The way I look at it is, let's use an example. Say I am going to work on my car. I have a toolbox. All I have in this toolbox is a screwdriver and a hammer. I can't get really far with that screwdriver and hammer only. And I see taking on new challenges, for instance, being a team lead, and there are other roles absolutely that help you fill this toolbox. It's just adding more tools to that toolbox. \n\nWhen we're individual contributors, sometimes we also get stuck in the weeds, right? We don't see the broader scale of things because we're picking up a story. We're trying to meet the requirements of that story. And we don't have a lot of input on overall architecture or how it's going to work with, say, other services. \n\nAnd I think when you take on that team role, you start to build those skills as well, more so than you might as a contributor, because you're seeing the bigger picture. You get to help guide how all the things are going to work together, defining contracts. And what does the structure of this look like? Is it a new service that we get to roll out? \n\nAnd you get to help design all these things almost like an architecture role, right? I think it would be a great segue into an architecture role if that's where someone would like to go with their career. And on the other side, if you want to go into people management, also get experience there. It's just I see it as another way to add tools to that toolbox.\n\nMIKE: Kind of combining what you're saying there, Matt, with what Afton had to say, you may be at a point in your career where you look, and you just see that hammer and a screwdriver, and what you need is maybe some wrenches, [laughs] and some basic tools. You don't need a very special tool. You don't need, like, a transit for doing surveying. You just need some wrenches or a saw.\n\nDepending on where you're at in your career, looking at the team lead role, some of the tools that you may be putting into your box are not the ones you need right now. And maybe what you need is more language skills, you know, some of the basics. It's important to look at what you need next in your toolbox.\n\nMATT: Right. Like Afton went to an entirely new language. Now, her toolbox is filling up on that side. \n\nMIKE: Exactly. \n\nMATT: I feel like a lot of people are very apprehensive. And there's kind of a bad stigma behind becoming a lead because of the meetings. But there are skills to be gained. Being able to communicate with business and understand their language and translate that to technical language it's a really positive thing if that's something you might have a little interest in but are apprehensive because you don't want to be in meetings.\n\nAFTON: Yeah. We were discussing earlier how much time is spent in meetings. I don't feel like they were detrimental. In all those meetings, I felt like I was learning communication, collaboration, higher-level business. How do you make decisions? Project management was a big one. I spend a lot of time studying [laughs] how to manage projects. \n\nSo yeah, those are all really good skills to have, like Matt and Mike were saying. But realizing those are the skills you may have to focus more on, of course, again, depending on your team dynamic, but just to realize what skills you're going to need and that that may be your focus for that time. Being aware knowing what you're deciding, what you're choosing is important.\n\nBEN: Kind of a different topic. You know, one of the things that I've seen with businesses is that a lot of times where they fail the most, it seems, is with management. We kind of think of management, at least I have, I guess, as kind of, like, this easy thing that you can learn really easily. And probably anybody can learn how to do it. But I've seen people manage coders, but they kind of are not being the manager. They really just want to code, and yet they're in this manager role. \n\nThey're kind of doing their coders a disservice because they're not really fulfilling the needs of that role, but they are the ones that have that role. And, you know, nobody else can really do it but them. And so, I guess that's one caution I would give out. Like, if you're a lead, be a lead. Don't be in the lead role and just try and keep just being a coder because you do pretty much everybody a disservice by doing that, I think.\n\nMIKE: To go back to my talk about the hikers at the beginning, you might be the fastest hiker in the group. Hiking up ahead of everybody doesn't benefit anybody but yourself. It doesn't get the project over the line. The project is to get everybody up there. There's a lot of value provided by being that person who walks in the back and helps the others along. And acting like that's not the most important thing that you're doing is problematic. \n\nMicromanaging and telling people what to do is usually not very helpful. Helping people out and, figuring out what the requirements are, and removing obstacles for people is immensely useful. You can spend all day removing obstacles for people, helping them along, and move the project forward much faster than you would if you were just chipping away at your own little piece.\n\nJUSTIN: If you look at your effectiveness as an individual, you need to look at yourself as, like, how can I multiply my effectiveness? Where am I most effective? Once you understand that it's through helping other people be more productive themselves, it's kind of a game changer. That's one of the reasons why I was kind of attracted to this app sec actually was, you know, oh, I can go out and help a lot of people now develop more securely and more productively. \n\nBut, you know, as a team lead, you have the closest insight to all of your team members, and you know what their strengths are, what their weaknesses are. And you can go in and talk to them each individually and help them get over the things that are affecting them, and help them be more effective engineers, more effective communicators, and lots of different things. \n\nAnd so, it's kind of a great opportunity to—you've probably heard of this—but be a leader servant, where you are helping others and, ultimately, you aren't being the great individual contributor that you possibly could be. But you are raising the overall work output of the group and helping them in their careers and, you know, just as individuals. So, I think it's one of the best ways to really help other people, you know, a great position to be in just because you can help them at that personal level.\n\nMATT: Helping other people level up is extremely fulfilling as well. A great analogy would be sports. You might be the best player on the court, but if you're not a team player, your team isn't going to be successful. If you're just going out trying to score all of your team's points all the time and not passing the ball, your team isn't going to win. So, sharing that knowledge and picking things up for them, you get double covered; perfect time to lift someone else up and get them some points. And that's how you win. \n\nAs Mike said, the only person you're helping is yourself sometimes if you're not fulfilling those other needs as a lead. I feel like you're even doing yourself a detriment. And it doesn't reflect well. So, you just have to be really open to what the role is. And it isn't just going out and getting all the points for your team. It's helping your team win.\n\nJARED: You know, Matt, I really like those sports analogies. I've been listening and reflecting upon my career and where I'd been a leader. And I've been thinking about when I first got into a management position when I was managing a restaurant; I came at it from the approach of...everybody's heard this phrase, \"If you want it done right, you do it yourself.\" I stressed myself out. I was a very mean and angry person.\n\nAs I grew in a leadership position, I learned that that's not how you manage. That's not how you handle people. And when you're a lead, people are the most important aspect of that. At this point, as a lead, you should be coaching, and mentoring, and training, and allowing your team to also take leadership responsibility and empower them to do their role. \n\nAnd also for me, I think that, if you want it done right, do it yourself, came from a lack of trust. And so, as a lead, you also need to trust your team to do it right. But also, you should train them to do it either the way that you would do it or the way that you would expect to have it done. But also give them the leeway to learn and expand there. \n\nI don't know if this is even a controversial take, but I don't like the idea of people wanting to be leads. That, to me, always seems like a red flag. And I'd like to hear everybody else's experience. But I truly think that leaders are found by different leadership and say that, you know, \"You are level-headed and can handle stress. And I think you can handle working and meeting these other people.\" \n\nAnd for the most part, they step up to the plate and learn this new skill set. I've never really looked at it like, oh, I want to be a lead. It's that I've been asked to be a lead by somebody who saw potential in me. And I said I'll give it a shot and see where that goes.\n\nMIKE: If I had somebody say, you know, \"I want to tell people what to do,\" then I would not want them to be a lead on my team. On the other hand, I saw somebody who was already helping people around them, mentoring, taking their time to help somebody when they were stuck, going out of their way to remove blocking issues for somebody, or to go get a question answered. Well, that person is already doing what I would want from a leader. There's nothing wrong with aspiring to help people. I think that there is something problematic with aspiring to direct people tell them what to do. What does make things feel better is helping.\n\nMATT: You also hear people say things like, \"A good leader hires people who are better than they are.\" Team leads generally aren't management. They are just leads that help guide their team, right? As a lead, I feel like your goal should be to make your team members better than you, at least try. Give them the skills that you have and share them. Also, learn from them. So, you're gaining skills as well.\n\nEDDY: This is sort of, like, a point-blank question to everyone. Has there ever been a time where you've been afraid to promote someone who is one of your highest producing individuals on your team to assume the role as a team lead, knowing full well that not as much code will be going out or, like, higher difficulty tickets will take longer, et cetera? \n\nMIKE: Yes. [laughs]\n\nMATT: Also, yes.\n\nMIKE: Absolutely. Because there's going to be reduction and just absolute...the amount of code that's getting written. There's a trade-off there. Somebody who's good for the lead role; however, you probably won't lose that much output because the multiplier that Justin was mentioning means that they will be helping other people get more done. So, you don't take as much loss as you might think.\n\nMATT: You may see a drop up front. But if they're doing what they were put there to do, you're going to see a lot of gain on the tail end because everyone else is going to be able to be more productive, and level up their skills, and make up in that difference, right?\n\nAFTON: I keep hearing so many parallels to Parenthood. I just need to mention that real quick because [laughs] one possibly unique thing about our culture here is that we have a wonderful culture of mentorship and learning together. And I think that that must inform our feeling comfortable moving a high producer into a lead position and letting things slow down for a bit, but eventually level up because everyone's benefiting, learning, having good experiences, and growing together from this.\n\nJust like, you know, I think it was Jared who said earlier, if you want it done right, you have to do it yourself. And my first thought was, yeah, I had to let go of that when I had to start teaching kids how to do chores around the house because [laughs] it's not going to be done right. It's going to take longer. It might not even get done. \n\nBut I need to start letting them learn how and do that job for a while, keep helping and instructing, and, eventually, they will grow better. Very like parenting, you want to give everything you can. It's going to take some time, extra effort, but they're going to level up. They're going to grow into capable, skilled people, and that is, you know, worth it.\n\nMIKE: And if you don't give them that opportunity, your kids reach 18, and they're not prepared [laughs], right? \n\nAFTON: Yeah. [laughs]\n\nMIKE: And that happens inadvertently. You think, oh yeah, I'm trying to be helpful and trying to do everything. You help people out by giving them a chance to fail a little bit.\n\nBEN: I think that's a really good point because it's kind of giving up control to some degree. One other thing I was going to say is that it's not necessarily the highest producers. I mean, that may be obvious, but there's some people, you know, that you can tell they would really hate being a team lead, [chuckles] you know, they just want to be in the code. And that's fine.\n\nMATT: And it's not for everybody. It really isn't. Some people just have no interest, and it isn't what they want to do. And that's okay. One of the things that I just would love to be able to do is remove some of the stigmas that come with the role and have people have a more open mind to that opportunity. Because there's a lot of positive aspects of the role. \n\nI personally...I love it. I love being able to work with the other teams, which, as an individual contributor, you don't get quite as much opportunity. You know, Ben, you and I work together a lot, especially recently. And it's great because I may not have had that opportunity otherwise.\n\nAFTON: If there is a stigma, that can be mitigated to some extent by just having a clear structure in your organization, having clear definitions or descriptions of each role and what's expected. And if someone is assuming this new role, they know what they're getting into. They know what new skills they are going to need and what demands will be upon them. Then, people can just make informed decisions. Is that what I want or not? \n\nI'm trying to understand the stigma that you're talking about, Matt. And I'm just kind of assuming that maybe if people think it's going to be something that it ends up not being for them, or if they have frustrations because expectations were not met, which could lead to a stigma of it being a bad thing or the meetings being a bad thing. But, anyway, clarity on what the role is, what the expectations will be, what the demands will be, I think might help.\n\nMIKE: Well, and there's different kinds of meetings, right? If you're in a meeting where you're barely engaged, and people are talking about stuff that doesn't concern you, and it runs on for hours, that's excruciating for me anyway. [chuckles] You have to be attentive enough to see if your attention is ever needed. So, you can't really put your attention elsewhere, you know, you don't really need that attention there. So, you're in this in-between area where it's really hard. \n\nThat kind of thing can make anybody say, \"Well, I hate meetings,\" if they've been in meetings like that. But this is kind of...it comes down to our individual responsibility. Especially if you have a lead role, you have an opportunity to kind of define what that meeting looks like, say, \"Well, we're going to have an agenda. We're here for a reason. The reason that we're meeting is because we need to solve problem X. We need to talk through it.\" And the whole reason that you're meeting with somebody is because you need to communicate and come to some shared understanding. \n\nAnd once you've met the purpose of that meeting, then you can be done. And the kinds of meetings that have an agenda, that have a clear goal, and that end with action items and a decision, those are invigorating. That kind of meeting doesn't drag you down. It actually is very rewarding. You can be architecting and feel much like...and is even part of the coding process in defining, you know, say, architecture, or determining requirements, even, you know, refining stories.\n\nIt's all part of the coding process, just as much as having your fingers on the keyboard, you know, typing code. The stigma of meetings or the sense that, oh, I'm just going to be in endless meetings, even if it was true, which it probably is not, the meetings that you're going to be in, that you can influence, you can make actually very effective. And it's not a negative thing. It can be a lot of fun.\n\nMATT: Yeah. And I kind of have a personal rule that if a meeting doesn't end with any action items, that meeting was all for naught. Meetings need to have agendas. They need to have action items that can come out of them, and then they're productive.\n\nMIKE: It seems simple. Like, well, it's really that easy? It kind of is. [laughs]\n\nMATT: I would have no problem if people were in a meeting that I organized, and they got an understanding that they didn't need to be there. They can just drop. You know, hey, I don't think I need to be a part of this meeting. I'm going to go help out my team or take care of other things that need to be addressed. And, you know, maybe that's something that people could set as a rule. If you don't feel like it's necessary that you're in this meeting, you are free to leave.\n\nEDDY: Let's say that you just, like, naturally enjoy being in a leadership role. Would it make sense in regards to being a team lead for a development team? Would you say that it's a requisite to have knowledge in programming in order to be effective in that role?\n\nMATT: For an engineering lead, I would say yes. For an engineering manager, not as much. Though it is helpful when you understand what your team is talking about, right? And it can help guide them because that's part of the job, aside from just HR duties. But there are a lot of CTOs at companies that really don't have a whole lot of technical experience. They're just really good at guiding. They're great with ideas and helping build teams to see those ideas through.\n\nMIKE: I think that somebody who's very effective does, however, understand the engineering process. Even if they are not necessarily in the code, they understand what it means to engineer something, that creative process of building things. \n\nAFTON: Yeah, when I started as team lead and was trying to really grasp what it would mean to be successful in that role, I did a lot of research on the various roles in engineering. And most of what I came across when talking about team leads was actually referred to as a tech lead, a tech lead meaning that their role really is to be a technical leader, which meant they needed technical experience and, you know, a lot of development skills. So, above that, would be more manager, like they were saying. So, here, I believe, team lead is essentially a tech lead role.\n\nJUSTIN: Just a quick comment about the CTO and any leadership position that isn't coding directly and that can go up from manager to director to VP. The ability to know what it takes to build something and know when, you know, there's some BS going on on the engineering side that's a very vital skill that those leaders need. If those leaders don't have the ability to detect when the wool is being pulled over their eyes or when they don't know what's really going on, or they don't have the skills to find out, they usually aren't that effective as a tech leader. \n\nThe best leaders I've seen, or some of the best leaders I've seen do, come from an engineering background. They founded the company as the original engineer, or they came up through the engineering ranks. And they happen to have the very great leadership skills that allowed them to be at the top. And those types of people actually inspire great loyalty and inspire their workers to work hard and to be able to see their vision. \n\nIt's not easy, certainly not. But if you do have those skills or if you have interest in going in that direction, it's worth researching how to do that, how to be a leader, because not everybody just picks it up naturally or anything. It's something that you study. It's something that you decide you want to go do. And it's something you practice. It's something that you interact with others and receive feedback on. And that's hard, receiving feedback. And actually, I'll go into that receiving feedback a little later. \n\nBut all those things, it's a lot of work to be those leaders, especially ones that can inspire their engineers and be able to share the vision that they have. And it's what inspires people, you know, to go that extra mile and to make sure that the work that they're doing is correct and that they care about their work. The great leaders can share their vision, and they can also understand what work is needed and what work is really going on.\n\nAFTON: This is my first career job. And so my experience is limited to here at Acima. But I would imagine that what's expected of you, or what you need to be able to do, skills you need to have, or the amount of technical skill you need versus managerial skill could vary greatly depending on the company, like the size of the company you're working for. \n\nIf you're a brand-new startup and they're trying to get things established, the demands on you may require lots of technical but also lots of managerial skill to fill a role as the company is trying to get established. Or if it's a larger company and they have enough people and enough foundation to have just a tech lead who doesn't have to do anything managerial or just managers who don't actually have to know anything technical [laughs]...I don't know; I'm just imagining that that actually could vary greatly, depending on the company you're working for the size of the organization. \n\nAnd one thing for me: when I started as a lead, I was trying to understand my role and what was expected here at Acima so that I could put some kind of boundary on what was expected of me because I know myself personally. If I don't know kind of what success means, then I'll just keep pushing and trying to do everything and get overwhelmed or, like, burn myself out very quickly. [laughs]\n\nI tend to try to do it all unless I have some kind of ceiling I can say, this is as far as my reach needs to go, or these are kind of the boundaries around what I need to do to do my roles successfully, to meet expectations, to exceed them, to be effective, to have the greatest impact in my role.\n\nMIKE: I think you're dead on, Afton. There's companies that have HR-only managers, right? They have no technical expertise at all. But they do a great job of the aspect of management that has nothing to do with technology. And then they have tech managers who are purely responsible for the technical side. But I think most companies, the roles will have kind of a hybrid of both. I think you're dead on, and figuring out what the requirements are where you're at is going to be really valuable so you'll know what the expectations actually are.\n\nEDDY: I just want to add this has been extremely insightful. I'm better grasping the idea of what a team lead does. [laughs] Because prior to this, again, I fell victim to the whole, oh yeah, team lead, meetings, right? So, this was great.\n\nMIKE: And it's been good to have you, Eddy, as that voice who's not done it before who can ask those kinds of questions. Really appreciate it.\n\nJUSTIN: I briefly mentioned this before, but I think that team leads need to remember to be humble and to ask for feedback from their team members. Getting that feedback is key to leveling up your team lead ability. And finding a mentor who perhaps is another team lead or some other tech leader is also key. And that way, you can gather that feedback about how you're doing, what your weaknesses are, and what you can do to get better.\n\nMIKE: Thank you. And maybe that's a good place to draw this to a close. As you're considering taking a lead role, find somebody who can talk to you about it, who can mentor you, and kind of explain to you what's going to be going on and can help you as you make the transition and grow your toolbox. Thank you to our panel today. It's been a great conversation. I guess we won't see you again, but you'll hear us again [laughs] on the next episode of the Acima Development Podcast.","content_html":"The panelists discuss the role of a team lead in a software development context. Mike shares a personal story about a family hike and draws parallels between being a team lead and guiding a group of hikers. The discussion revolves around the challenges and benefits of being a team lead, considering factors such as size, experience levels, and the balance between technical contributions and leadership responsibilities.
\n\nAfton, Matt, and Eddy share their perspectives on the role of a team lead, emphasizing that it can vary greatly depending on the team's dynamics and the individual's career goals. They discuss how being a team lead can provide opportunities for mentorship, architecture design, and a broader understanding of project management.
\n\nOverall, the conversation highlights the importance of considering one's career goals and the specific circumstances of the team when deciding whether to take on a team lead role and how it can enhance one's skill set and career trajectory.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. Today, we are going to be talking about being a team lead, specifically being a team lead. Why or why not? There's often a choice that you have in your career, and team lead starts you down a path sometimes toward being more involved in leadership. There's trade-offs involved there.
\n\nYou know, to have a good conversation, we have several current or former team leads. We have Afton with us, who has been a team lead. We have Jared, who is currently a team lead over at QA team. And we have Matt, who is currently a team lead over an engineering team. Justin, have you been a team lead before?
\n\nJUSTIN: Yeah.
\n\nMIKE: I figured. And we also have Eddy with us, who has not yet been a team lead. I would like to, as usual, start our discussion with a story to kind of guide the discussion a little bit. And I've been thinking about this and how we might lead out. I decided I'm going to start by talking about a family vacation I took last year to Colorado. On the way out, we weren't quite where we were going yet. We ended up going to the Great Sand Dunes National Park. I think it's one of the less visited ones, and it's really beautiful.
\n\nWe stopped in the Denver area. I don't remember exactly where it was, so I can't tell you [laughs] precisely. But we wanted to get some fresh air. And we went for a hike. One thing I learned from my dad, which is a really good idea, is that when you're going for a walk or hike together as a family, it is a great idea to have the youngest or the slowest person on the group that you're with take the lead, be the person in front. The strongest walker or hiker you put in the back, and there are really compelling reasons to do that.
\n\nIf you put the fastest person in front, then they will have to look behind them regularly to stay together with everybody else. And pretty soon, they'll be way out ahead, and the group is all separated, which is a bad situation if you ever want to coordinate. That was particularly important back in the days before cell phones. But it works out great. I do the same thing with my family. I generally have the youngest person in front, and then we follow their pace. It works out pretty well.
\n\nMATT: That's how wolf packs operate.
\n\nMIKE: Is it? That's good to know. It's just a really effective way to get everybody going at the same pace. We went on this hike. Like I said, it was beautiful. And we got up to a good stopping point where there was a loop that went around a small peak that [inaudible 02:27]. And my oldest son was looking at that peak up ahead, and he thought, I'd really like to do that. And he still had the energy, right? He really wanted to go ahead and do that loop. Or he actually just wanted to go straight up the mountain. [laughs]
\n\nI said, "You can go around the loop. There's probably a trail on the backside." And everybody else was kind of tired out and wanted to go down. In the end, we kind of compromised. I went with my oldest son. And we quickly went and did the loop around the top. He went up over to the very top, and I went around the side. And we met, and then we came down, and we met the rest of my family. My wife went with my younger kids; them go out in front. We thought we'd catch up to them before we got to the bottom, but they actually beat us by a little bit.
\n\nI'm telling this story for a reason. My wife was an excellent team lead because she stayed with the people who needed guidance through the entire hike. My oldest son was the strongest hiker, but he did not stay with the team. He was just really hungry to go get to the top. And there was nothing wrong with that, right? It was great. You know, he's peak age physically. [laughs] So, you know, it's great that he wants to do that. But it meant that he wasn't really a good candidate to lead the rest of the group.
\n\nContrasting the differences between what my wife did in staying with the younger kids the entire time, making sure she never left them behind, and my oldest son, who's just really eager to go and get to the top, I think, provides some perspective as to points that all of us may find ourselves in at different points of our career. Being in either position isn't necessarily bad, but they are different. And you kind of need to commit yourself to a role if you're going to be in one or the other.
\n\nBut, sometimes, you're going to be an individual contributor, and you just want to get to the top. There's some value there in contributing a lot of code to the team. And sometimes, you can provide more value in helping others along and making sure they get to where they're needing to go. I thought that was, in my mind at least, a good way to kind of frame this conversation.
\n\nI'd also like to add that joining us a little bit late is Ben, who's also a team lead and has been a team lead multiple times in the past. So, I think I'm just going to open the question. And what are your thoughts, particularly towards the team leads or former team leads? What are your thoughts about the contrast between being a team lead and not a team lead, and why you would or not take that position?
\n\nAFTON: I had some thoughts while you were telling your story because I was a team lead over, at first, 8 to 10 engineers. That dwindled down a few for the longer term. But a few months back, I moved to a new team, back to being an individual contributor. And the dynamics of my new team were so different than I had experienced because the team was much smaller. The average engineer had a lot more experience than on my prior team.
\n\nSo, as you were telling your story, I was thinking the leader of the hike would have a vastly different experience and vastly different demands upon them, depending on who they're hiking with. You know, you may have really young, inexperienced, or out-of-shape hikers [laughs] and also very skilled hikers. And keeping them together it takes more work or more coordination, more communication, more group understanding of people's levels and capabilities, and how you can bring those together to meet in the middle.
\n\nVersus if your whole group is very skilled, it's going to take a lot less overhead to keep that group in sync with each other and moving along together. Whether that group is all skilled or all inexperienced, it's largely the same. The overhead of managing that group will be, I think, much simpler. [laughs]
\n\nThe broader the levels of experience of those team members, the more work it is for the leader to keep everyone together. And the skills required of the leader can be different, so high communication and collaboration and making sure everyone understands each other, so people skills and team building. And you need to know who you're going to be leading, what the dynamics are of that group, the skill levels of that group, in order to ever even start to think, is that the challenge I want to take right now? Is that going to get me where I want to go in the future?
\n\nMIKE: That's a fascinating insight. You're saying that being a team lead is not one thing necessarily. It's going to depend a lot on the team that you're working with.
\n\nAFTON: Yes, absolutely. The team that I was leading was, I would say, majority junior developers with a sprinkling of very skilled developers, and even developers from different parts of the world. So, I had a few team members in India. So, also cultures of the different team members can come into play as well.
\n\nAnd when I moved to my new team that I'm on currently as an individual contributor, most of the team members are very skilled have a lot more experience generally. And also, everyone is local. [laughs] We can all get together and sit by each other, which makes it easier to understand one another, work together, build some sense of teammanship, easier to manage overall.
\n\nSo, yes, the dynamics of the team, I think, will change what's required of the team lead, the skills that they're going to need to help their team be successful, and change the experience of what the team lead can then gain from the experience of leaving the team.
\n\nMATT: I strongly agree with that statement. You know, as Afton was just saying, I believe, currently, my team is represented in six different countries. And that adds a little bit of complexity because of scheduling, some language barriers occasionally, and just getting the right people on the right project so the communication can be there.
\n\nOne thing I think a lot of people worry about is if they become a lead, that they aren't going to be able to contribute. Well, sometimes that's true. And you may not be writing a lot of code like you are as an individual contributor. Your contribution aspect is still there. It's just in different areas.
\n\nHere at Acima, our leads do a lot of architecture, and lead the design flow, and help with requirements, and a lot of the higher-level stuff that, as a contributor, you don't get as much experience doing. So, it really depends on where you want to go in your career. But I would highly recommend, if given the opportunity, everyone take the opportunity to lead a team at least once and get that experience.
\n\nMIKE: So, Matt, you say that it's worth doing at least once. It's a valuable experience, even if you don't stick with it.
\n\nMATT: Absolutely. I've done this a number of times. I enjoy the role personally because I love helping lead the architecture and helping make some of these business decisions, where you might not have the opportunity as an individual contributor because you aren't in the right groups, you know, for instance, in meetings, things like that. I know everyone says they hate meetings, but they're a necessity. And if you want to build good software, it's vital to have that understanding.
\n\nMIKE: You mentioned the meetings; that will probably be a recurring theme. If you're going to be doing some leadership, you're probably going to have to meet with some people, which means that you're going to have a higher meeting load than you would otherwise. It's just intrinsic to the nature of the role.
\n\nEDDY: Can I add I feel like there's a stigma with being a team lead. There's an association with being bombarded with meetings. So, as someone who enjoys thoroughly coding on a daily basis and constantly contributing to a codebase, would that individual be a prime candidate to the same [inaudible 10:22] position?
\n\nMIKE: I might refer some to what Afton said [laughs] that --
\n\nMATT: I'd agree.
\n\nMIKE: It's going to depend a lot on what team you're working with. If you're going to work with a large, diverse team, probably going to be a lot of demands placed on you, and you're probably not going to have much time to also be an individual contributor. It really does depend a lot. I've had times when I was leading a team, but I'd still spend most of my time coding. And, generally, that was with a fairly small team. And I still had lots of time to code. And I've had times when I had almost no time to code. It really depended on the constraints that were on me.
\n\nMATT: Because our listeners may or may not know much about Acima and our structure, I came from a smaller team initially. And, on that team, at the time, we were extremely small. In fact, our team name was Nano. Our lead was able to write a lot of code most of the time because we were a very senior team. And we just kind of divided up projects and went at them. So, there wasn't a whole lot of guidance that he had to provide to us.
\n\nWhereas, as Afton stated, the Atlas team is larger and has a lot more junior representation. So, it's a different role as a lead, a lot more mentorship, a lot more guidance, different tool set to lead that team as it is a small, more senior type team.
\n\nAFTON: I've been thinking a little bit about this. Eddy's question seemed to be kind of saying, when would this be a good time? [laughs] Like, I've done the team lead for, you know, a year, year and a half, and still love to sit and just write code. Going back to individual contributor, I was in heaven [laughs], spending a whole day writing code again.
\n\nMIKE: [laughs]
\n\nAFTON: Super fun. But that doesn't mean I didn't love the new skills I was developing and the new challenges I faced as a team lead. My situation was that I had been professionally developing for about three and a half years, is all before I started acting as team lead. And, at the time, I had been around the longest. I had a lot of business knowledge and a good foundation of technical skills. So, I felt like I could be a good mentor. Even if I was lacking in some technical skills, we did have some more experienced developers very available to me and on my team who I could rely on to help with technical leadership.
\n\nI do think it's an amazing experience that everyone could benefit from. You know, if you're given an opportunity, think about, well, first of all, the team dynamics of who you're being asked to lead, what it might require of you to lead, and how much time that might leave you to continue developing your technical skills. And if there's potential that you won't have much time, then to realize that you might start to feel like you're falling behind in your technical development, your own technical development, if it requires so much of the other skills to lead a team. But if you are being asked to lead a more experienced team, then you may have more time to continue working on your own development.
\n\nI think it's really important to look ahead in the future. Think, a year from now, if I take this role and this is what I see it looking like, a year from now, is that going to move me ahead in my career and where I want to go? Or could this potentially be sidetracking me to somewhere where it might actually hinder my ultimate goal?
\n\nSo, think ahead of the future: a year from now, am I going to be glad that I did this? Is it going to put me in a better place? Or could this somehow put me in a worse place [laughs] hold me back from my ultimate goal? So, considering your goals is very important. Think about that and take the time to know where you want to be and to say, a year from now, where do I want to be? Two years from now, where? Five years from now, where? And now, does this fit within a path to get me there?
\n\nMIKE: Well said, Afton. You said --
\n\nMATT: The way I look at it is, let's use an example. Say I am going to work on my car. I have a toolbox. All I have in this toolbox is a screwdriver and a hammer. I can't get really far with that screwdriver and hammer only. And I see taking on new challenges, for instance, being a team lead, and there are other roles absolutely that help you fill this toolbox. It's just adding more tools to that toolbox.
\n\nWhen we're individual contributors, sometimes we also get stuck in the weeds, right? We don't see the broader scale of things because we're picking up a story. We're trying to meet the requirements of that story. And we don't have a lot of input on overall architecture or how it's going to work with, say, other services.
\n\nAnd I think when you take on that team role, you start to build those skills as well, more so than you might as a contributor, because you're seeing the bigger picture. You get to help guide how all the things are going to work together, defining contracts. And what does the structure of this look like? Is it a new service that we get to roll out?
\n\nAnd you get to help design all these things almost like an architecture role, right? I think it would be a great segue into an architecture role if that's where someone would like to go with their career. And on the other side, if you want to go into people management, also get experience there. It's just I see it as another way to add tools to that toolbox.
\n\nMIKE: Kind of combining what you're saying there, Matt, with what Afton had to say, you may be at a point in your career where you look, and you just see that hammer and a screwdriver, and what you need is maybe some wrenches, [laughs] and some basic tools. You don't need a very special tool. You don't need, like, a transit for doing surveying. You just need some wrenches or a saw.
\n\nDepending on where you're at in your career, looking at the team lead role, some of the tools that you may be putting into your box are not the ones you need right now. And maybe what you need is more language skills, you know, some of the basics. It's important to look at what you need next in your toolbox.
\n\nMATT: Right. Like Afton went to an entirely new language. Now, her toolbox is filling up on that side.
\n\nMIKE: Exactly.
\n\nMATT: I feel like a lot of people are very apprehensive. And there's kind of a bad stigma behind becoming a lead because of the meetings. But there are skills to be gained. Being able to communicate with business and understand their language and translate that to technical language it's a really positive thing if that's something you might have a little interest in but are apprehensive because you don't want to be in meetings.
\n\nAFTON: Yeah. We were discussing earlier how much time is spent in meetings. I don't feel like they were detrimental. In all those meetings, I felt like I was learning communication, collaboration, higher-level business. How do you make decisions? Project management was a big one. I spend a lot of time studying [laughs] how to manage projects.
\n\nSo yeah, those are all really good skills to have, like Matt and Mike were saying. But realizing those are the skills you may have to focus more on, of course, again, depending on your team dynamic, but just to realize what skills you're going to need and that that may be your focus for that time. Being aware knowing what you're deciding, what you're choosing is important.
\n\nBEN: Kind of a different topic. You know, one of the things that I've seen with businesses is that a lot of times where they fail the most, it seems, is with management. We kind of think of management, at least I have, I guess, as kind of, like, this easy thing that you can learn really easily. And probably anybody can learn how to do it. But I've seen people manage coders, but they kind of are not being the manager. They really just want to code, and yet they're in this manager role.
\n\nThey're kind of doing their coders a disservice because they're not really fulfilling the needs of that role, but they are the ones that have that role. And, you know, nobody else can really do it but them. And so, I guess that's one caution I would give out. Like, if you're a lead, be a lead. Don't be in the lead role and just try and keep just being a coder because you do pretty much everybody a disservice by doing that, I think.
\n\nMIKE: To go back to my talk about the hikers at the beginning, you might be the fastest hiker in the group. Hiking up ahead of everybody doesn't benefit anybody but yourself. It doesn't get the project over the line. The project is to get everybody up there. There's a lot of value provided by being that person who walks in the back and helps the others along. And acting like that's not the most important thing that you're doing is problematic.
\n\nMicromanaging and telling people what to do is usually not very helpful. Helping people out and, figuring out what the requirements are, and removing obstacles for people is immensely useful. You can spend all day removing obstacles for people, helping them along, and move the project forward much faster than you would if you were just chipping away at your own little piece.
\n\nJUSTIN: If you look at your effectiveness as an individual, you need to look at yourself as, like, how can I multiply my effectiveness? Where am I most effective? Once you understand that it's through helping other people be more productive themselves, it's kind of a game changer. That's one of the reasons why I was kind of attracted to this app sec actually was, you know, oh, I can go out and help a lot of people now develop more securely and more productively.
\n\nBut, you know, as a team lead, you have the closest insight to all of your team members, and you know what their strengths are, what their weaknesses are. And you can go in and talk to them each individually and help them get over the things that are affecting them, and help them be more effective engineers, more effective communicators, and lots of different things.
\n\nAnd so, it's kind of a great opportunity to—you've probably heard of this—but be a leader servant, where you are helping others and, ultimately, you aren't being the great individual contributor that you possibly could be. But you are raising the overall work output of the group and helping them in their careers and, you know, just as individuals. So, I think it's one of the best ways to really help other people, you know, a great position to be in just because you can help them at that personal level.
\n\nMATT: Helping other people level up is extremely fulfilling as well. A great analogy would be sports. You might be the best player on the court, but if you're not a team player, your team isn't going to be successful. If you're just going out trying to score all of your team's points all the time and not passing the ball, your team isn't going to win. So, sharing that knowledge and picking things up for them, you get double covered; perfect time to lift someone else up and get them some points. And that's how you win.
\n\nAs Mike said, the only person you're helping is yourself sometimes if you're not fulfilling those other needs as a lead. I feel like you're even doing yourself a detriment. And it doesn't reflect well. So, you just have to be really open to what the role is. And it isn't just going out and getting all the points for your team. It's helping your team win.
\n\nJARED: You know, Matt, I really like those sports analogies. I've been listening and reflecting upon my career and where I'd been a leader. And I've been thinking about when I first got into a management position when I was managing a restaurant; I came at it from the approach of...everybody's heard this phrase, "If you want it done right, you do it yourself." I stressed myself out. I was a very mean and angry person.
\n\nAs I grew in a leadership position, I learned that that's not how you manage. That's not how you handle people. And when you're a lead, people are the most important aspect of that. At this point, as a lead, you should be coaching, and mentoring, and training, and allowing your team to also take leadership responsibility and empower them to do their role.
\n\nAnd also for me, I think that, if you want it done right, do it yourself, came from a lack of trust. And so, as a lead, you also need to trust your team to do it right. But also, you should train them to do it either the way that you would do it or the way that you would expect to have it done. But also give them the leeway to learn and expand there.
\n\nI don't know if this is even a controversial take, but I don't like the idea of people wanting to be leads. That, to me, always seems like a red flag. And I'd like to hear everybody else's experience. But I truly think that leaders are found by different leadership and say that, you know, "You are level-headed and can handle stress. And I think you can handle working and meeting these other people."
\n\nAnd for the most part, they step up to the plate and learn this new skill set. I've never really looked at it like, oh, I want to be a lead. It's that I've been asked to be a lead by somebody who saw potential in me. And I said I'll give it a shot and see where that goes.
\n\nMIKE: If I had somebody say, you know, "I want to tell people what to do," then I would not want them to be a lead on my team. On the other hand, I saw somebody who was already helping people around them, mentoring, taking their time to help somebody when they were stuck, going out of their way to remove blocking issues for somebody, or to go get a question answered. Well, that person is already doing what I would want from a leader. There's nothing wrong with aspiring to help people. I think that there is something problematic with aspiring to direct people tell them what to do. What does make things feel better is helping.
\n\nMATT: You also hear people say things like, "A good leader hires people who are better than they are." Team leads generally aren't management. They are just leads that help guide their team, right? As a lead, I feel like your goal should be to make your team members better than you, at least try. Give them the skills that you have and share them. Also, learn from them. So, you're gaining skills as well.
\n\nEDDY: This is sort of, like, a point-blank question to everyone. Has there ever been a time where you've been afraid to promote someone who is one of your highest producing individuals on your team to assume the role as a team lead, knowing full well that not as much code will be going out or, like, higher difficulty tickets will take longer, et cetera?
\n\nMIKE: Yes. [laughs]
\n\nMATT: Also, yes.
\n\nMIKE: Absolutely. Because there's going to be reduction and just absolute...the amount of code that's getting written. There's a trade-off there. Somebody who's good for the lead role; however, you probably won't lose that much output because the multiplier that Justin was mentioning means that they will be helping other people get more done. So, you don't take as much loss as you might think.
\n\nMATT: You may see a drop up front. But if they're doing what they were put there to do, you're going to see a lot of gain on the tail end because everyone else is going to be able to be more productive, and level up their skills, and make up in that difference, right?
\n\nAFTON: I keep hearing so many parallels to Parenthood. I just need to mention that real quick because [laughs] one possibly unique thing about our culture here is that we have a wonderful culture of mentorship and learning together. And I think that that must inform our feeling comfortable moving a high producer into a lead position and letting things slow down for a bit, but eventually level up because everyone's benefiting, learning, having good experiences, and growing together from this.
\n\nJust like, you know, I think it was Jared who said earlier, if you want it done right, you have to do it yourself. And my first thought was, yeah, I had to let go of that when I had to start teaching kids how to do chores around the house because [laughs] it's not going to be done right. It's going to take longer. It might not even get done.
\n\nBut I need to start letting them learn how and do that job for a while, keep helping and instructing, and, eventually, they will grow better. Very like parenting, you want to give everything you can. It's going to take some time, extra effort, but they're going to level up. They're going to grow into capable, skilled people, and that is, you know, worth it.
\n\nMIKE: And if you don't give them that opportunity, your kids reach 18, and they're not prepared [laughs], right?
\n\nAFTON: Yeah. [laughs]
\n\nMIKE: And that happens inadvertently. You think, oh yeah, I'm trying to be helpful and trying to do everything. You help people out by giving them a chance to fail a little bit.
\n\nBEN: I think that's a really good point because it's kind of giving up control to some degree. One other thing I was going to say is that it's not necessarily the highest producers. I mean, that may be obvious, but there's some people, you know, that you can tell they would really hate being a team lead, [chuckles] you know, they just want to be in the code. And that's fine.
\n\nMATT: And it's not for everybody. It really isn't. Some people just have no interest, and it isn't what they want to do. And that's okay. One of the things that I just would love to be able to do is remove some of the stigmas that come with the role and have people have a more open mind to that opportunity. Because there's a lot of positive aspects of the role.
\n\nI personally...I love it. I love being able to work with the other teams, which, as an individual contributor, you don't get quite as much opportunity. You know, Ben, you and I work together a lot, especially recently. And it's great because I may not have had that opportunity otherwise.
\n\nAFTON: If there is a stigma, that can be mitigated to some extent by just having a clear structure in your organization, having clear definitions or descriptions of each role and what's expected. And if someone is assuming this new role, they know what they're getting into. They know what new skills they are going to need and what demands will be upon them. Then, people can just make informed decisions. Is that what I want or not?
\n\nI'm trying to understand the stigma that you're talking about, Matt. And I'm just kind of assuming that maybe if people think it's going to be something that it ends up not being for them, or if they have frustrations because expectations were not met, which could lead to a stigma of it being a bad thing or the meetings being a bad thing. But, anyway, clarity on what the role is, what the expectations will be, what the demands will be, I think might help.
\n\nMIKE: Well, and there's different kinds of meetings, right? If you're in a meeting where you're barely engaged, and people are talking about stuff that doesn't concern you, and it runs on for hours, that's excruciating for me anyway. [chuckles] You have to be attentive enough to see if your attention is ever needed. So, you can't really put your attention elsewhere, you know, you don't really need that attention there. So, you're in this in-between area where it's really hard.
\n\nThat kind of thing can make anybody say, "Well, I hate meetings," if they've been in meetings like that. But this is kind of...it comes down to our individual responsibility. Especially if you have a lead role, you have an opportunity to kind of define what that meeting looks like, say, "Well, we're going to have an agenda. We're here for a reason. The reason that we're meeting is because we need to solve problem X. We need to talk through it." And the whole reason that you're meeting with somebody is because you need to communicate and come to some shared understanding.
\n\nAnd once you've met the purpose of that meeting, then you can be done. And the kinds of meetings that have an agenda, that have a clear goal, and that end with action items and a decision, those are invigorating. That kind of meeting doesn't drag you down. It actually is very rewarding. You can be architecting and feel much like...and is even part of the coding process in defining, you know, say, architecture, or determining requirements, even, you know, refining stories.
\n\nIt's all part of the coding process, just as much as having your fingers on the keyboard, you know, typing code. The stigma of meetings or the sense that, oh, I'm just going to be in endless meetings, even if it was true, which it probably is not, the meetings that you're going to be in, that you can influence, you can make actually very effective. And it's not a negative thing. It can be a lot of fun.
\n\nMATT: Yeah. And I kind of have a personal rule that if a meeting doesn't end with any action items, that meeting was all for naught. Meetings need to have agendas. They need to have action items that can come out of them, and then they're productive.
\n\nMIKE: It seems simple. Like, well, it's really that easy? It kind of is. [laughs]
\n\nMATT: I would have no problem if people were in a meeting that I organized, and they got an understanding that they didn't need to be there. They can just drop. You know, hey, I don't think I need to be a part of this meeting. I'm going to go help out my team or take care of other things that need to be addressed. And, you know, maybe that's something that people could set as a rule. If you don't feel like it's necessary that you're in this meeting, you are free to leave.
\n\nEDDY: Let's say that you just, like, naturally enjoy being in a leadership role. Would it make sense in regards to being a team lead for a development team? Would you say that it's a requisite to have knowledge in programming in order to be effective in that role?
\n\nMATT: For an engineering lead, I would say yes. For an engineering manager, not as much. Though it is helpful when you understand what your team is talking about, right? And it can help guide them because that's part of the job, aside from just HR duties. But there are a lot of CTOs at companies that really don't have a whole lot of technical experience. They're just really good at guiding. They're great with ideas and helping build teams to see those ideas through.
\n\nMIKE: I think that somebody who's very effective does, however, understand the engineering process. Even if they are not necessarily in the code, they understand what it means to engineer something, that creative process of building things.
\n\nAFTON: Yeah, when I started as team lead and was trying to really grasp what it would mean to be successful in that role, I did a lot of research on the various roles in engineering. And most of what I came across when talking about team leads was actually referred to as a tech lead, a tech lead meaning that their role really is to be a technical leader, which meant they needed technical experience and, you know, a lot of development skills. So, above that, would be more manager, like they were saying. So, here, I believe, team lead is essentially a tech lead role.
\n\nJUSTIN: Just a quick comment about the CTO and any leadership position that isn't coding directly and that can go up from manager to director to VP. The ability to know what it takes to build something and know when, you know, there's some BS going on on the engineering side that's a very vital skill that those leaders need. If those leaders don't have the ability to detect when the wool is being pulled over their eyes or when they don't know what's really going on, or they don't have the skills to find out, they usually aren't that effective as a tech leader.
\n\nThe best leaders I've seen, or some of the best leaders I've seen do, come from an engineering background. They founded the company as the original engineer, or they came up through the engineering ranks. And they happen to have the very great leadership skills that allowed them to be at the top. And those types of people actually inspire great loyalty and inspire their workers to work hard and to be able to see their vision.
\n\nIt's not easy, certainly not. But if you do have those skills or if you have interest in going in that direction, it's worth researching how to do that, how to be a leader, because not everybody just picks it up naturally or anything. It's something that you study. It's something that you decide you want to go do. And it's something you practice. It's something that you interact with others and receive feedback on. And that's hard, receiving feedback. And actually, I'll go into that receiving feedback a little later.
\n\nBut all those things, it's a lot of work to be those leaders, especially ones that can inspire their engineers and be able to share the vision that they have. And it's what inspires people, you know, to go that extra mile and to make sure that the work that they're doing is correct and that they care about their work. The great leaders can share their vision, and they can also understand what work is needed and what work is really going on.
\n\nAFTON: This is my first career job. And so my experience is limited to here at Acima. But I would imagine that what's expected of you, or what you need to be able to do, skills you need to have, or the amount of technical skill you need versus managerial skill could vary greatly depending on the company, like the size of the company you're working for.
\n\nIf you're a brand-new startup and they're trying to get things established, the demands on you may require lots of technical but also lots of managerial skill to fill a role as the company is trying to get established. Or if it's a larger company and they have enough people and enough foundation to have just a tech lead who doesn't have to do anything managerial or just managers who don't actually have to know anything technical [laughs]...I don't know; I'm just imagining that that actually could vary greatly, depending on the company you're working for the size of the organization.
\n\nAnd one thing for me: when I started as a lead, I was trying to understand my role and what was expected here at Acima so that I could put some kind of boundary on what was expected of me because I know myself personally. If I don't know kind of what success means, then I'll just keep pushing and trying to do everything and get overwhelmed or, like, burn myself out very quickly. [laughs]
\n\nI tend to try to do it all unless I have some kind of ceiling I can say, this is as far as my reach needs to go, or these are kind of the boundaries around what I need to do to do my roles successfully, to meet expectations, to exceed them, to be effective, to have the greatest impact in my role.
\n\nMIKE: I think you're dead on, Afton. There's companies that have HR-only managers, right? They have no technical expertise at all. But they do a great job of the aspect of management that has nothing to do with technology. And then they have tech managers who are purely responsible for the technical side. But I think most companies, the roles will have kind of a hybrid of both. I think you're dead on, and figuring out what the requirements are where you're at is going to be really valuable so you'll know what the expectations actually are.
\n\nEDDY: I just want to add this has been extremely insightful. I'm better grasping the idea of what a team lead does. [laughs] Because prior to this, again, I fell victim to the whole, oh yeah, team lead, meetings, right? So, this was great.
\n\nMIKE: And it's been good to have you, Eddy, as that voice who's not done it before who can ask those kinds of questions. Really appreciate it.
\n\nJUSTIN: I briefly mentioned this before, but I think that team leads need to remember to be humble and to ask for feedback from their team members. Getting that feedback is key to leveling up your team lead ability. And finding a mentor who perhaps is another team lead or some other tech leader is also key. And that way, you can gather that feedback about how you're doing, what your weaknesses are, and what you can do to get better.
\n\nMIKE: Thank you. And maybe that's a good place to draw this to a close. As you're considering taking a lead role, find somebody who can talk to you about it, who can mentor you, and kind of explain to you what's going to be going on and can help you as you make the transition and grow your toolbox. Thank you to our panel today. It's been a great conversation. I guess we won't see you again, but you'll hear us again [laughs] on the next episode of the Acima Development Podcast.
","summary":"The panelists discuss the role of a team lead in a software development context. Mike shares a personal story about a family hike and draws parallels between being a team lead and guiding a group of hikers. The discussion revolves around the challenges and benefits of being a team lead, considering factors such as size, experience levels, and the balance between technical contributions and leadership responsibilities.\r\n\r\nAfton, Matt, and Eddy share their perspectives on the role of a team lead, emphasizing that it can vary greatly depending on the team's dynamics and the individual's career goals. They discuss how being a team lead can provide opportunities for mentorship, architecture design, and a broader understanding of project management.\r\n\r\nOverall, the conversation highlights the importance of considering one's career goals and the specific circumstances of the team when deciding whether to take on a team lead role and how it can enhance one's skill set and career trajectory. ","date_published":"2023-11-01T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/d95d0a76-24a8-4eb6-b047-5b0c37e44182.mp3","mime_type":"audio/mpeg","size_in_bytes":36144989,"duration_in_seconds":2370}]},{"id":"b076c97a-7e6c-4b85-9cf0-40ff5e09ce05","title":"Episode 30: Why is RSpec So Hard? (Part II)","url":"https://acima-development.fireside.fm/30","content_text":"The panelists continue for part two of their discussion on testing code with RSpec! \n\n✨ Check out Part I here! ✨ \n\nMike kicks things off with a maze metaphor, illustrating the importance of navigating code branches. He emphasizes the branch-focused approach for comprehensive test coverage and cautions against excessive testing of external libraries while highlighting the significance of testing public interfaces.\n\nThe episode also addresses the hurdles newcomers encounter when venturing into the world of RSpec. Hailey and Eddy share their initial struggles, likening it to learning a new language. They agree that familiarity with RSpec's unique language and structure grows with time.\n\nIn the latter part of the discussion, Eddy and David share insights on RSpec's error messages. Eddy expresses frustration with cryptic messages, particularly involving hashes and scientific notation. David recommends using the --format documentation option in RSpec to enhance error message clarity and suggests writing descriptive context, and it blocks for improved test readability. Mike highlights the importance of enhancing error messages and proposes an unconventional approach to structuring tests while emphasizing the value of starting with the unhappy path.\n\nAll said and done, this episode takes you on a journey through RSpec, covering testing strategies, best practices, newcomer challenges, error message improvement, and intriguing insights into test structuring. It underscores the significance of clear error messages and offers valuable guidance for enhancing test readability and effective debugging.\n\nTranscript:\n\nDAVID: Hello and welcome to the Acima Development Podcast. I'm David Brady. I'm hosting today. We've got a really great panel. We've got Ramses, and Jonathan, Freedom, Mike, a couple of people snuck in. I think I see Eddy. Hailey just walked in. This is going to be a good episode. We're going to talk about how to organize RSpec to make it a little more understandable and how to deal with some of the difficulties in it. Mike has a thing to drop on us.\n\nMIKE: And the way that I'd like to kick this off is to talk about a maze, either a maze or a cave. Visualize your pick. You're either going to walk through a labyrinth above ground, or you're going to walk through a labyrinth below ground. Either way, you're lost in endless passages that branch here and there. You know that you want to find your way out, right? There is a way out, but going into this maze or this cave, you don't know which way that is. And how do you solve that problem? \n\nI'll make a proposal here of a solution, a straightforward solution. And here's my proposal: Every time you come to a fork in the path, you have the ability to mark it, right? And this is actually a very simple rule. One way you can do this is just to always go right [laughs] first, right? You always turn right when you get to a branch. You explore to the right. And then, once you get to another branch, you go right. You get to another branch; you go right. You get to another branch; you go right. There's even a name for this in the computer science literature of, you know, you're doing a depth-first search. \n\nYou're going to go down as deep as you can in the cave, right? You're going to go follow that all the way to the end. And when you reach the end, you backtrack to the previous branch. And then, you turn left, and you don't turn left down any branch until you've explored as far as you can to the right. And then, you can go and explore down that branch to the left. And then, again, you have your right rule where you're going on as deep as you can. You come back, and you backtrack. When you finally have to, follow the left. And you keep on doing that, making sure that both sides, both branches, at every point until you've explored the full maze. \n\nI actually read about this once. I've thought about this since I was, like, a teenager because I read once that they design mazes for which this rule doesn't work. I'm like, wait, what? How? Well, the way that you design mazes doesn't work as you have concentric rings, which means the branches don't quite follow the right rule. Because if you have concentric rings and your solution is at the center, you can have a wall all the way around at the outermost layer. All of the turns are left. And if you turn left, then you're just going to be going around a ring again. So, at every point, the rule doesn't work. But you can make some minor adjustments to it to kind of make it work. \n\nBut in a traditional maze, like the kind that would be underground in a cave, they can't do that sort of thing generally. You have to follow one branch or the other. And why am I talking about this for RSpec? I say this because our goal when we are testing code is to get coverage. We want to make sure that everything works. And a lot of times, we think, well, my code is really sophisticated. It does really interesting things, which is probably true. When you break down those interesting things, in the end, they tend to be binary decisions. You go right, or you go left. It's a decision tree. \n\nAs you follow down on your code, at every point in your code, you're either executing something, in which case you're always going through it, or you have some sort of condition. And sometimes, I will say, sometimes those conditions are implicit. It doesn't always include an if clause, for example. A return sends something out or a break. Maybe it's not explicitly doing an if, but there's some implicit types of conditions. Either way, it's a branch. \n\nAt every point in your code, it's either going to go straightforward, right? It's going to keep on executing through instructions, or it's going to branch somehow. And if that's what your code always is, which it should be, it's either going to progress linearly, go through procedural step by step, or it's going to branch. And so, if you want to have complete coverage of your code, then what you need to do is simply cover every branch. \n\nI'm going to stop on that for a second because I think it's a critical realization that's really helped me with RSpec. Because if instead of thinking about my code as a set of functions and maybe I've got some anonymous functions, and classes, and objects, which is all true, from a testing perspective, I think that your code is just a set of branches. I don't really care about your objects other than as entry points. What I care about from the testing perspective is coverage. So, I care about the branches. \n\nAnd thinking about it from that branching perspective changes your mindset. You're exploring the cave, right? And you want to explore every branch. And once you've changed that from thinking about it as this sophisticated, beautiful labyrinth, which it may be, from a testing perspective, you should think about it differently. You should think about it as a bunch of branches. It's a tree with branches. And if you cover all the branches, your testing is complete. \n\nI'm going to pause there for a second to think about the metaphor. Well, RSpec has tools to do that, but I'd like to talk a little about the metaphor first. That's how I kind of wanted to introduce our discussion. I had that idea in mind before we talked. \n\nDAVID: Now I'm very excited about this because I'm either going right where you want me to go or I'm hopping into, like, a just a weird hair up my brain spark, which is that when I sit down with a great, big thing to work on, I get daunted. I get blank page syndrome where I'm like, ooh, how am I going to get all this tested? \n\nIn the maze world, I've heard this called the right-hand rule or the left-hand rule. And it's got an interesting property that if you put your right hand on the wall, then when you get to the branch, you'll go down, like, the right-hand side of the branch. You get to the room at the end of that thing. You walk around the outside of the room...or the inside of the room. You keep your right hand, and now you're leaving the room with your hand on the other wall. When you get back to the branch, you're now touching the wall between the thing you just went down and the next one over. So, you just keep your hand on it, right?\n\nThe thing that I love about breaking it down this way is that it's very, very clear where you start, which is, to quote Alice in Wonderland, \"At the beginning,\" right? And then, what do I test next? You've always got a next. It's hard to know how am I going to test all of this? I don't know. I don't know. But I know what I need to test first. And what do I test next? Well, when I finish the thing I was on, I'm just going to test the first thing that's left. It's a lovely, little recursive thing. You always know what's next until you run out of next, and that's when you're done.\n\nMIKE: So well said. I've worked with a lot of people over the years who've looked at their code, like, where do I start this test? Because it is daunting. It doesn't just apply to testing. It applies to a lot of things. But we're talking about the testing problem, in particular, and that's exactly it. Well, what's the entry point of your code? And let's start by creating a context for your first branch. And there is your first step. \n\nAnd once you've explored that, you know, and maybe you have to do some nested contexts in there because that branch branches. And you keep on exploring those nested branches until you get to the bottom. And you come back out, and you're like, well, okay, what's the next branch? And I maybe need another context [inaudible 07:02] explores the next one. And that's it. And you can run through the test just like that. And there's always a next step. It's really easy to think about. And the only thing you have to think about at every step is, well, what's the other branch?\n\nEDDY: You know, Mike, I have a question regarding coverage. When writing tests for that file, in particular, should we always be shooting for 100%? And if not, what are the exceptions?\n\nMIKE: Well, that's a great question. Let me answer it this way. And we're talking about RSpec. RSpec is so named because there's, like, a specification there, right? It's a way of specifying what your code does. And if we have not fully specified what our code does, then it isn't very good documentation, and there's undocumented parts of our code.\n\nDAVID: I'm going to come at this from a completely different angle. I'm going to say something...here's my hot take: You should never be striving for 100%. You should be striving for what's the most important thing to test. Or like Mike's saying, literally, if you're going through an order, you branch. I like the branch, in my mind, between the most important thing that's in front of me and everything else. So, like, when I'm testing an API call, my first branch is the happy path. I want when I do call the thing; I want it to work.\n\nThen, what I will do is I will branch into the unhappy stuff. What's the biggest, most important unhappy path? That's my next branch, and the next one, and the next one, and the next one. At some point, I'm going to realize I've tested enough or I'm out of functionality, especially if you're doing RSpec and you go in and you literally spec the code. You've all heard of TDD, Test-Driven Development. You go in, and you say, I'm going to call this API. And when I pass it this user and this status, I'm going to get back a 200 OK, and that user will be updated.\n\nAnd I love how expressive RSpec is for this because it makes it very, very easy to specify what the code will do, and you haven't even written the code. You reach 100% the same way, which is you're like, what's the next thing I need to work on? Oh, I'm out of functionality to specify.\n\nMIKE: I was just saying if you have a cave system that has multiple entrances, those should be seen as separate systems. Your code has a public interface, public methods. And those are the entry points, right? That's the entrance to the cave. You should go into every entry point that is public, and that's it. If it's private, well, then it's not effectively part of the code that you're testing because it's unreachable. The goal here is to specify every branch that is reachable through the public interfaces. \n\nI'll put one other caveat here, which is that we should explore the boundaries of our unit of code because we're talking about unit testing here, not integration testing. We should explore the boundaries of our unit of code, which means that you get something that leaves, say, the class that you're testing. That should be mocked or stubbed, so you don't actually go beyond that point. You don't ever leave your cave. \n\nMIKE: Mike, I take back every bad thing I've ever said about you. That was beautifully put.\n\nEDDY: [laughs] I was going to say because then you get in the realm of integration tests, and that's not what you want. \n\nDAVID: Yeah. \n\nEDDY: But specifically, I was going to say, what if you have methods that just do trivial logic, but it's still public? At that point, should you be testing something so trivial as to, like, display a text or, like, decorate a text [inaudible 10:08]?\n\nMIKE: Well, if your code is so trivial that it doesn't need to be tested, then why did you write it?\n\nDAVID: There's actually a good answer to both of these questions. The testing push came around, like Y2K, late '90s, like with extreme programming. And those folks...and they were coming from Java where you could specify accessors. So, you could very easily say, this is a read accessor on this. It's a public entry point. Therefore, it is behavior; therefore, it should be tested. \n\nAnd everyone kind of stepped back and said, \"Yeah, but this is a language feature. It's never going to have a bug. It's never going to be a problem.\" And they collectively decided this is the one case when we do not test public behavior because it can't fail. Or if it does, you've got bigger problems, or you've literally misspelled the method name.\n\nMIKE: You said something that I think was critical, which is related to what I said about not leaving the cave. You don't test outside your cave. That is, if you didn't write the code, you don't test it. If it's the language or the framework that is providing the feature, it's not your code, and you shouldn't test it because then you're testing somebody else's code. You're not testing your unit of code anymore.\n\nDAVID: Right. 100%, I'm embarrassed to say how late in my career I got before really having this hammered home because it was this morning. I'm writing a thing that talks to an API. And I have always considered the HTTP library, like Ruby's Net::HTTP library, that's framework code. That's core library code. We don't want to test into that. But my application is going to talk to Net::HTTP. I might want to specify that the conversation there is handled correctly. \n\nI've been on project after project after project where we've said, let's not use Net::HTTP; let's use Faraday. Or let's not use Faraday; let's use HTTParty. Or let's not use HTTParty; let's use Typhoeus. And just on and on and on and on all the way down the road. And I ended up getting to this point where I would walk around the application out the backend, where the cables go off into the internet. I'd use, like, WebMock and intercept calls going out over the wire to HTTP over the wire. It's a little bit of an exaggeration, but you get the idea. I'm all the way at the other end of Ruby catching these things coming out. \n\nAnd I was talking with my team lead. And he's like, \"Why don't you just stub the call to Faraday?\" And I'm like, \"But...but...but,\" right? Because if we change that library, it's going to change the conversation on my specs. It's going to break. I actually had to step back and go; I didn't write Faraday. I didn't write HTTP. I am writing the code that has the conversation with whatever web library. And guess what? That is exactly the kind of thing I want to test. I want to assert that I'm having the correct conversation with whatever web library I'm using. And I want to specify that it's having the conversation with that web library. You don't want to send Faraday calls to HTTParty, right? It's not going to make sense. \n\nSo, yeah, like I said, a lot later in my career. It literally was this morning. I'm not exaggerating. I'm like, oh, oh yeah, I had a heuristic to make that call the other way around. And the trade-off there was that, yeah, sometimes I end up testing library code that I didn't write. And, [vocalization], boy, yeah, sometimes you run into trouble because the library maintainer can change their implementation. And yeah, you see the trade-off there, right? It just spooled out of control. You don't want to do that. Never test a Rails private method.\n\nMIKE: And, again, let's make sure we're making the distinction between unit tests and integration tests. \n\nDAVID: Yes.\n\nMIKE: And I think that's where we get into a lot of trouble. If you want to make sure your system works with another system, you should have a small set, I would argue, because they're really expensive and slow, of tests to make sure that integration works, which is different from your standard test suite that you run over and over and over again because it's fast and effective, and it doesn't break all the time.\n\nDAVID: Right. Right. I realized the other part of the trade-off is that coming from API land previously in my career; I'm used to being handed a JSON document of post this to our REST server. And we will give you—then they hand me another JSON document—we'll give you this document in return. And having that and being able to specify that exactly I want this many bytes to go out, and I want these exact bytes to come back, then it does make sense. \n\nAnd, like you said, integration test. Yeah, you don't want to test 401, 403, 405, 422, 404, every single possible 400 error. You don't want to test every one in an integration test. These things take forever, relatively speaking. Maybe I fire you the happy path, and I stub out with a response. And then I fire out one or two unhappy paths, and then we're done. We walk away.\n\nMIKE: So, I've talked a lot about my idea of how to test branches. For me, it's been kind of an epiphany [laughs] when I saw this, and it's relatively late in my career as well, not quite this morning but not five years in, to realize, oh, well, all I'm doing is testing branches. But, you know, having that different lens with which to see the world has dramatically affected testing. \n\nAnd I've seen it really work well for other people as well. People who were just banging their heads, like, where do I start? Were able to very quickly progress by thinking about things through that lens of, well, what's just my next branch? And there may be others on this call who've approached things that way, and I'd be interested in hearing other people's experience with that approach.\n\nEDDY: You know, I'm kind of curious in gauging people's perspectives here. Everyone on this call, I think, to some degree, has touched RSpec for the past couple of months. I'm curious to gauge what other people's perspective was the initial exposure that they had to RSpec. Did it give a facade of difficulty, and if it did, to what degree?\n\nDAVID: I got into RSpec with version 1.0, which put the should method on every object in Ruby, like, throughout the entire space. Of course, in Ruby, even integers are objects that you can call methods on. And so, you could literally write three dot should equal three. That was the moment that test-driven development really lit up. And I'm like; I can write this before; I mean, there was nothing stopping me from saying assert equal three comma three prior to this. But, for some reason, in my brain, assert equal three; three is something you write after. You know, assert equal, A plus B equals five, right? \n\nIn my mind, that's something you do after you have written the code, and you're just trying to button things up and prove to the maintainer that it works. But, in my mind, A plus B should equal three. It pushes you to say, hey, write this before you write the code. We're not going to say it does equal three; we're going to say it should equal three. \n\nAnd I really liked that RSpec, when they got rid of the should monkey patch—which makes me sad, but I understand why people get rid of it—I liked that they kept that future subjunctive tense by saying, we're not going to assert. We're going to expect. And so we say expect A plus B to equal three. It's a little easier for me to write that after the fact and see it kind of in both verb tenses. But it does let me hang on to that bright torch of, I'm going to write this, and then I'm going to go write the code, which I realize is tangent to the topic of today, which is making RSpec easier. But, you know, it's my baby, and I like to show it off. \n\nHAILEY: I'll speak on my first experience with RSpec. I feel like it was probably just a few months ago. I think as interns joined in on The Skills Clinic, we were working on some advent of code. And we were, like, in the middle of the project. So, we didn't see, like, the spec being created. I just saw, like, a completed spec file, and I think that was really confusing for me. Because, like, I feel Ruby is similar enough to other languages that I was able to understand, okay, this is, like, a loop. This is an if statement. You know, I'm returning this section of code, things like that. \n\nBut words like describe, and let, and subject, context, before do blocks I hadn't seen those before. And so, that was all really new to me. And to just see, like, 50 lines of code of things that I hadn't seen before that was really confusing. And then, once we ended up breaking it down, and once I was able to write my own spec and see them being written, not just a completed spec, that really helped me understand how RSpec works.\n\nDAVID: Nice.\n\nEDDY: That was my same experience when I first picked up on RSpec to [inaudible 18:26] in QA. When I first started, I was like, wow, what is this whole other language, right? Like, how is the structure, and why is every one so opinionated? [laughs] And how this is written. So...\n\nHAILEY: Right. It seemed like a different language. \n\nEDDY: Absolutely. You got some overlap here and there, very subtle. But overall, yeah, it can be a bit overwhelming if it's the first experience with it. So, I think that's, like, sort of, like, makes it a little difficult for new developers who are testing in RSpec initially, right? There's, like, some sort of ramp-up to it.\n\nDAVID: Yeah. And there are some surprising things that come from that, right? If you pick up, like Jasmine, which is a JavaScript testing framework inspired by RSpec, then it has context and describe, and it. It's a function that takes the name of the thing that you want to describe or specify. And then, it takes a Lambda of just the function you want to execute when that happens. And that's kind of what you see in RSpec, right? You see, describe, and then a thing, and then do/end. And the do/end is like that...it's a proc. It's literally a block of code that's going to get executed as, like, an anonymous function. \n\nBut it's really easy to just go, oh, it's magic, and I don't need to worry about it. And that's absolutely true 99% of the time. But eventually, you start wondering, how does this function ever get called? And that's when you start lifting up the tablecloth and looking underneath RSpec, and you start seeing that, oh, that it do it doesn't define a method. It defines a class. A what? Yeah, it defines an entire class, an anonymous class. Its execute method...I can't remember the name of it. Is it run? It might be a run () method, but it's got a method on it that will, you know, execute the test. \n\nAnd when you run RSpec over, like, a directory, it picks up every one of these files. And that it do makes a class, it do makes a class; it do makes a class. And then those three classes are inside a context, which makes a class. And the definition of that class is define these three classes that we just talked about. Once they are all defined, and everything is completely loaded, that's when RSpec says, okay, you know, roll call, who all did we get defined? Okay, cool. Start at the beginning and start running your stuff. And it starts executing it through. \n\nAnd that is why you can end up with, like, this really weird stuff, like, where you have a spec that fails, and instead of giving you, like, the name of the spec, you end up with example three, bracket five, bracket two, and you're like, what...what is this? Well, okay, it's actually you were doing it do context do without a name. You were just doing, like, it do. Like, you used subject instead of saying, you know, describe thing. You're just like, well, describe do. You shouldn't do that, but you can. And there are people that if you can do it, they will. \n\nAnd [chuckles], Robert, if you're listening to me, I love you. We can still be friends. I had a co-worker named Robert. He could point anywhere in a file, and he could tell you what the bracket offsets, the indexing scheme that RSpec uses under the hood. The point that I'm trying to make...I'm actually not going to talk all the way through to [inaudible 21:14]. I'm just going to assume that we all got lost in that weird classes of definitions because that's the whole point. It's magic, and 99% of the time, you don't need to keep track of it. \n\nBut the entire point of this is there are people who will defend, like, Test::Unit, which is really, really old, Minitest, which is getting old. Minitest is very, very simple. The entire source code for Minitest used to fit on, like, two printed pages back when printing was a thing that people did in the world. So, it was very easy to understand everything Minitest does under the hood. And RSpec was just this document the size of, you know, the federal tax code. And so, trying to get your head around what it does was very, very hard. \n\nSo, I 100% agree. Most of the heavy lift that RSpec does is to create this domain-specific language, a DSL for testing. Well, not for testing, for specifying the way code should behave and then making it behave that way. As long as it works the way you want, you don't ever have to open it up. And you're like, oh okay, yeah, once I've learned this language, then I can use it. And it's very fluent, and it's very easy to understand. \n\nBut, Hailey, you are 100% right that I started that with once you learn that language, and it almost sounds like I said the word just right or easy. Or how hard would it be, right? No, no. I fully admit that that once implies not until, right? You have to learn the DSL before you can leverage it.\n\nMIKE: But I will say something interesting about this. I'm going to kind of go back to the cave idea, this maze traversal, which is that RSpec is actually kind of opinionated. It lets you do a lot of things. But that syntax that it uses, those contexts, for example, encourage...just like Dave was saying about that should or that, you know, is expected or, you know, expect, there's some suggestion as to which way you should go. \n\nRSpec doesn't have a lot of top-level methods, but it has describe. It has it, which is where your assertions go, and it has context. The workhorse of RSpec is the context. And a context represents a branch built into the framework. If you think, well, oh, I'm going to set up tests for a branch, and I'm going to give it an anonymous function, and conceptually and in practice, that's what's happening is you're saying this branch is going to get an anonymous function that will run the tests on it. And that's what RSpec is doing. \n\nIf you want to know what that domain-specific language is doing, it is giving you the ability to set up a test for a branch. And I think seeing that and understanding that's what it's nudging you to do can help overcome a lot of apprehension.\n\nDAVID: Absolutely. \n\nEDDY: I do want to say that ever since I started testing with RSpec, I've hated red dots forever. \n\nDAVID: You absolutely should.\n\nEDDY: Anytime I see a red dot, I just hate it, period. Number two, I think what makes RSpec really difficult, especially for someone coming in fresh, is the fact that the error messages could be a lot better, right? \n\nDAVID: Yeah.\n\nEDDY: Like, some of the messages that you get for errors, you're just like, what are you talking about? Like, what do you mean no_args expected, [laughs] right? \n\nDAVID: I have a strong opinion about that. Finish your idea, and then ask me about the errors.\n\nEDDY: I was just going to say, I think what really makes it really difficult to pick up initially is just that the error messages that are spitting out, like, unless you have context on that, like, it makes it extremely difficult to really debug, like, what the actual bug is in your code.\n\nDAVID: Yeah. So, here's my strong opinion. Please, please, please consider this. If you've never done this, do it as an experiment and, like, do it for a week. Do it every time. And that is, whenever you run RSpec, put dash dash format equals documentation. Or, if you're, you know, quick and in a hurry, dash F Space D. This turns off the dots. You don't get green dots, red Fs, and little yellow asterisks. What you get is this nested tree of text, and it gives you the object you're describing. \n\nAnd if you've got a context of, like, you know, happy path versus unhappy path, it will put happy path on a line by itself indented underneath the object that you're describing. And then, when you're in the happy path, let's say we're going to describe the initialize merchant, you know, method, so you've got a describe, initialize merchant, well, that shows up as the third line indented twice underneath happy path. \n\nSo, you get this beautifully indented tree of text, text, text, text, text. And then, you finally get, like, you know, it should create it at timestamp, you know. So, it's like, it sets created at your RSpec declaration, right? You get to that line in the documentation, and that entire line of text turns green if it passes, or the entire line turns red if it fails. So, that's the first half of the experiment. \n\nThe nuance to this is run it in format documentation and read it as if you had never seen your code before or as if you were sitting down to train another intern on how your code works. And you really, really, really want them to be able to read that stuff on the screen and not have follow-up questions. So, have them just read your documentation and go, hmm, okay, seems legit, I got it. \n\nEddy, this then circles back to your point. If you take the time to type out correct clauses in your thing...and it's real simple, never type context without typing when after it. So, I don't write context happy path. Instead of saying context user is unauthorized, I will write context when the user is unauthorized or when user is unauthorized. And then we get to the it, which is, you know, it redirects to the login page. It displays a 404 error, you know, a 401 error. \n\nHere's the thing: when you run this in FD, in format documentation, the last step is force every single spec to fail and watch it in the format documentation. You will end up seeing, describe this API context, you know, on the happy path when the user is authorized. It logs them into the homepage. You get this lovely little documentation thing. And you're like, okay, yeah, logically, that follows all the way down. I got it. Cool, no problem. It's green. Everything is good. \n\nNow, you make it fail, and then you scroll down to the error message. And RSpec will take all of those nested snippets of text and it will chain them together into complete mishmash gobbledygook that nobody looks at unless you were using the grammar. If you've been writing context when and, you know, describe, you know, da da da, also with, you know, context with this thing going on or with this flag set, all of a sudden, that error message down at the bottom...and these are the ones where you get, like, we're no longer showing the blocks at test. We just got, like, an error and the line of code that it was on. \n\nYou get this chunk of red text that literally forms a sentence in English. On the happy path, when the user is authorized, and they log in, they get redirected to the homepage. And that whole thing is red, and it fails. Let's say we say the user's password, you know, doesn't match. We're going to assert that the text \"Welcome, Eddy\"...we're going to set this username with the name of Eddy. The text, \"Welcome, Eddy,\" should be on the page. \n\nSo, you get this long, red sentence. You know, on the happy path, when the user is authorized, they log in, and they get redirected to home. That's right. It failed. Then the error message on line 273 of your spec file: expected to find welcome, Eddy, but that text was not on the page. Now, without opening the code or the spec, you know what was going on when it failed. And you know what the program did that was wrong. \n\nAnd I promise you, if you do this, this weird, oddly specific thing will happen, which is four out of five times, you'll go, oh yeah, we commented out the user welcome thing. You haven't even opened the code, and you know where the bug is. You know what happened. And that is this weird, oddly specific, delightfully pleasing thing that happens if you write context when, you know, describe thing context when it does a thing. And then, you run the format documentation and make sure it makes a sentence. It's lovely. \n\nAnd then, anytime you have an expect, expect 42 to equal 43, and then see what exactly is the error message. Because you'll end up with somebody else's code, and they'll be like, \"Uh, yeah, we tried to log in, but we couldn't. Oh, and the error messages on line 229 expected 42, but it wasn't.\" What? This helps me not at all. Well, it does help you. It's going to give you the line of code in, you know, what file and exactly the line of code. But now you have to open that file, and you have to go to that line of code. \n\nWhereas if you get the error message expected to find \"Welcome, Eddy\" on the page but I didn't, you know exactly what's going on. And much of the time, you know exactly what you just did a few minutes ago. Like, oh yeah, we forgot to turn this back on. It's so delightful when that happens when you can literally debug your code without opening it. And a good spec suite will give you that.\n\nEDDY: Yeah. I just kind of wish, like, the error messaging was a lot better. Like, this is sort of, like, going off the top of my head where it's sort of, like, class double [inaudible 30:10] expected arguments.\n\nDAVID: Unexpected method, blah, yeah.\n\nEDDY: Yeah. Blah, blah, blah. I'm like, that doesn't really make sense, right?\n\nDAVID: Force your expectations to fail and run them and see how they fail, and then reconstruct your context. If it's really oblique...we had a meeting earlier where we were talking about whether or not we should display a link. And the code underneath it was, is this object not invalid? You can infer that we don't want to show this thing if the object is invalid. But I didn't realize in the API that if the object is valid, we absolutely should show it. There's no other conditions to check, right? \n\nSo, if you get a red dot and it said, \"Expected true got false,\" oh, that doesn't help. Does it? Right? So, if we then turn around and say, when the link is valid, it should show, then when that fails, you can say, hey, I expected the progress bar to show the link, and it didn't. Or the, you know, I expected it to be show link or, you know, to have the show link enabled, and it wasn't. Now, that error message takes you exactly where it was. \n\nThere was another developer on the call that offhandedly said, \"Why don't we just put, you know, not invalid in the code that calls it?\" Show link is a conversation I want to have with a progress bar. Invalid or valid is a conversation I want to have with the model underneath it. And I don't want to have to remember that valid invalid implies show link, not show link, and that nothing else is part of that implication, right? I don't want to keep track of that. \n\nSo, like, what you're saying, Eddy, we don't want to say, on line 73, this code failed, expected false got true. We want to say, on the happy path, when this link is valid, when I ask the progress bar, should I show this link? It should say, \"Yeah, yeah, you should show this link.\" And then, you get the error message: expected false got true, or expected progress bar to be show link, which is a little bit awkward English. \n\nBut, I mean, we expected that you know, to have the show link status be enabled, but it wasn't. And you're like, oh, okay, yeah, now I know exactly where we are. I know what conversation we're having with what object, and I know what the semantic meaning of that conversation is. Does that make sense, Eddy? I just realized you've now said twice this is hard to understand. And I'm like, oh, no, no, no, [inaudible 32:22]. And I just realized I'm just throwing words at you. Is this helping at all? \n\nEDDY: Yeah, yeah, yeah.\n\nDAVID: You can say no. The listeners will laugh.\n\nEDDY: [laughs]\n\nMIKE: You know, Dave is saying use RSpec differently, and the errors will make more sense. Distill all that down. And I think that there's a lot of truth to that. It's easy to map, and I think it's kind of instinctive (I think I did it when I first used RSpec.) to map frameworks that are, like, Test::Unit style that are run assertion, run assertion, run assertion to RSpec, which has a different paradigm. \n\nRSpec is designed to be thought of as a documentation generator as much as a testing framework. It says [inaudible 32:59] the same thing. And if you use it that way, you will have a different experience, that you will be much less likely to have those. This error makes no sense because you're looking at as documentation. And if it's formatted differently, then you don't just get a bunch of green dots with one red dot and a cryptic message. Instead, you get this documentation, and you get the line in the documentation that doesn't work. \n\nAnd you're like, oh, the documentation doesn't apply here, and that gives me something. It may not be perfect. And a lot of times, the errors are just, you know, Ruby errors. So, they're language errors rather than RSpec errors. And then you have to make, like, oh, so, I have to figure out what's going on with my tests. But you at least have something to hang on to. I do think that changing that mindset is a big part of how you make those error messages less cryptic, is you think about the problem differently.\n\nDAVID: Interestingly enough, that is the reason...the thing that we just talked through, the error messages in particular, is the reason that I won't ever use the subject method in RSpec if I can avoid it. And I definitely...if I use it, I will not write it do without text or context do without text. And the reason why is because RSpec will almost obfuscate the error message. Like, you literally will get, example, 3 of 5 of 1 expected 17 got 15. Good luck. \n\nNow, not only do you have to track down where the code went wrong or where the spec went wrong, but you have to start winding up through the top of the file to figure out what did the spec set up before [inaudible 34:26]? Yeah, just type. Type some text on the context and the it. \n\nI realize what I described sounds really hairy. Like, I've shown a couple of people, and they're, like, oh, this is too much of a headache. Context when it does, and run it, and look at it, and make it fail, and read the sentence. It will take you less than half an hour to completely internalize it. 5 or 10 times through the loop, and you'll have it. It's opaque at the beginning, but it's a skill that you can master very, very quickly. It'll click very quickly.\n\nMIKE: And, again, on the branches, what else would you write? If you're describing when some set of conditions apply, well, you probably ought to have some text that says when some set of conditions apply. It's just the natural...RSpec is opinionated without necessarily saying so. Think about your branch of code. What branch of code applies when these conditions apply? Or maybe if or, you know, it's conditional. It begins with a word that suggests conditionality that, again, maps to the way that you're structuring it.\n\nSPEAKER: Speaking to the RSpec, errors aren't top tier; I was working on something the other day. And essentially, some of it just consisted of adding a new field to just a hash that was returned by some function call. And I was looking at the RSpec because it just kept failing. And I was like, what's going on? Like, what is the reason for this? \n\nAnd it said that it failed because all the decimal values that are returned were returned in scientific notation instead of, like, just regular decimal notation. And I was like, why is this happening? This doesn't make any sense. Turns out it was just because the test file wasn't accounting for that added field to the hash. So, it was like, it didn't tell me exactly what was wrong. And it actually told me something wrong that was wrong.\n\nMIKE: But you saw it said, \"These hashes don't match,\" right? And you looked at it and said, over on the left side, these are a fixed number of decimal points. And over on the right side, they're not. And so, they were things that RSpec could say were equal, but when it displayed them out, they weren't quite equal. And so, you were looking, oh, these aren't equal. Where's the problem? Because, you know, it kind of obscured it because you couldn't tell where the mismatch was.\n\nSPEAKER: Exactly, yeah. It was a bit strange at first, but having a very written-out English sentence would have made that about ten times easier to recognize; oh, this is the problem. That's why this is going wrong.\n\nDAVID: There's a subversion or an extension of this. It's interesting because, like, when we talk about RSpec exception errors aren't top tier, I'm having this instinctive reaction. And I'm trying not to, like, am I trying to defend my baby here, you know, out of just loyalty? And I realize, no. No, it's because that context when and the it, you know, describe noun, describe when, you know, it verb, da da da...RSpec, for me, is top shelf. It is the best error message. But I realize now it's because I write them that way. \n\nI've tried to port that to Minitest and Test::Unit, and you can kind of, but it's a lot more work. It doesn't flow as naturally. And that might just be a translation and familiarity thing for me because I'm familiar with RSpec. But I 100% agree that hashes do not match, especially if it says expected, and then you get, like, two and a half lines of text with a dot dot dot in the middle of it because RSpec finally just said, I'm just going to have to give you an ellipsis. But I actually got two and a half lines of text with a dot dot dot in the middle, right? \n\nYou can get RSpec to give you just as much information and not waste as much screen real estate by just typing RSpec or or echo; it didn't work. And that will just suppress all the output from RSpec. And if it fails, there's a mistake in there somewhere. Good luck. Have fun, right? And hashes [inaudible 37:58] math is terrible. It really is terrible.\n\nEDDY: Well, that's why I started to adopt hash including versus double splat, right? \n\nDAVID: Yeah. So, there's a subtle trick also that you can do. You can write this; I say don't. You can say we're going to describe this hash, and all the fields should match. And you can write out; it should match. And then, inside the it block, you write, you know, for key value in expected, actual subkey should equal, you know, or expect the actual key to be the expected key, right? \n\nAnd that's great, except that you're going to end up with an error message that says, hey, on line 27 of this thing, which is inside a for loop, you have no idea which index you were on when the for loop failed. Because that thing did 150 expects, and you have no idea which one failed, right? And you're going to get an error message that said something like, \"Expected blank string, got nil.\" Oh, good luck. Which field out of that was it, right? \n\nIf it was expected, 123 Fake Street got nil; okay, I've got a street address that's missing, right? But it's when you get something that's, like, it could be any of them, right? Expected, you know, AAA got BBB. Oh great, where's my As and Bs? You know, what does that mean, right? If you're going to play that game, take that hack and pull it. \n\nBy the way, this is where the fact that RSpec is compiling classes becomes like black magic awesome. Because you can take that hash outside, you can't use a let, but you actually have to define it right there in the Ruby code of key value, key value, key value. But you do it in the source code outside of the let, or the describe, or outside of the it or the describe, and then you say a key value. And inside that key value, that each loop, you say it, and then in the text you say, should have field, you know, and then the field name key equal to, you know, field value. Or, you know, field key should match, right? \n\nWhat happens when RSpec processes that file it hits the loop, and it generates. If there's 150 key values in that hash, it generates 150 it blocks, expectations. And because you put the variable in the it description text, now when it fails, that is the text that RSpec will give you in the failure message. You'll actually get a thing that kicks out and says, \"Hey, address line two does not match, expected a blank string, got nil.\" Oh yeah, okay, yeah, we weren't reading in the department or the suite number off of the address. Oh yeah, look at that. We don't even have that column on the model. That's why it's nil, right?\n\nYou can make RSpec lead you by the nose and point you, right? You know, hold your nose right up to the air and say, this is it. It's right here, and this is why it happened. But you do have to make RSpec do it. You have to learn, again, like, context when, context when. If you take anything from this, put when whenever you do context, and then describe a condition when on the happy path. It really does help.\n\nMIKE: If I make one other suggestion -- \n\nDAVID: Sure.\n\nMIKE: Take this cave metaphor a little further. I love what you just said about making sure that every single expectation actually, you know, on the it block or on the context block has documentation. And one other place that people tend to struggle with in Rspec is how to do the setup. How do I set up my before or my let? And this is maybe a place where there's less clarity. It doesn't force you as much. \n\nBut I have found...and it sounds like my thinking is similar to yours. You say you put the unhappy branch first. Well, I would say that's correct. If you're exploring a cave and you're looking for the way out of the cave, or you're going through a maze, well, you're definitely going to go through the non-solution first, right? [laughs]\n\nDAVID: Oh, that's interesting. Finish your thought. I do it exactly the opposite. I put the happy path first. But carry on.\n\nMIKE: Well, and I think that there's a very compelling reason, an extremely compelling reason to put the non-happy path first and have the happy path at the bottom, and it's this if you do your setup for the happy path, so your let blocks, you know, your before each, whatever it is to do your setup, your mocking, your stubbing; if you set that up for the happy path and then you begin by testing your unhappy path, then what ends up happening is every branch of your unhappy path you're only saying what's wrong if the authentication fails.\n\nAnd then, you're overriding one piece of your setup. It allows every single context to have just a couple of things that's going to say, \"This is the thing that's wrong.\" And you're going to see an it block that says, \"And it doesn't work.\" And it becomes trivially obvious to read through your spec and say, oh, this is the thing that's wrong here. This is the thing that's wrong here. This is the wrong thing; it's here. Because at every branch, the only thing that you're overriding is the one piece of your setup that is broken at that part of the branch. \n\nAnd then, when you finally get down to the deepest level, you've reached the bottom of the cave. And hey, there's the door out. There's no setup at all because you've exhausted all of the bad conditions, and all that's left is, hey, the setup works.\n\nDAVID: Oh, that's neat. You were halfway through that, and I was making the meme of the stick figure guy who's going \"[vocalization], you know, I've got a reply for you.\" And then, halfway through, he's like, \"Oh,\" just kind of deflates a little bit. And he's like, \"Hmm, yeah, you're right.\"\n\nI'll extend it one more step, which is that if you start with a working thing, you are blacklisting your errors. Instead of whitelisting one functioning thing, it's easy to go through and break one thing, one thing, one thing, one thing. Anything you forget to break will not get tested, and the object will pass. If you start off with a blank object and only populate in every single test, that can get exhausting if you're populating all the fields, you know, unrelated fields each time through. But there's some value in that, right? Sometimes you're like, I want this object to kick and scream and just refuse to be valid until the last possible minute. Yeah, I like that.\n\nMIKE: I imagine you could thread through this in either direction. You know, some people work their mazes backwards.\n\nDAVID: There is a left-hand rule as well as the right-hand. It works exactly how you think. Yep.\n\nMIKE: And the key part there is that this is what's different in this branch. Here is everything. You want to make it really obvious this is the part that's different, and this is what happens. And you want it to be designed such that you have to go through all the branches to get to the end.\n\nDAVID: I kind of like that. From, like, a documentation, like, teaching a maintainer how this works, I kind of like having the happy path be first, from a, you know, like, this is how it's supposed to work. Now, let's talk about all the ways it can go wrong. But I like that idea as well of, like, yeah, this thing is wrong. It will not be right until everything is right. So, I think that's totally valid. It makes sense.\n\nMIKE: Right. I think that either way, starting with the wrong or starting with the right could work that the critical part is that you follow a direction like that, right? And this is another thing that people have problems with with RSpec. You have to go digging around and looking for what the context is [inaudible 44:30]. The only thing that you should see in your context is what's different. You could say that, well, I just can do all of my setup. Here's everything that's right, and here's the one thing that's different. But I think that that can actually be problematic because it's noisy. I want as little noise as possible. \n\nDAVID: Yeah. I had it driven into me recently that there's no such thing as a solution; there's only a trade-off. And you have to decide what side of the trade-off you value. You might come into a thing where you know what? The left-hand rule is actually more important. I want to start with the wrong end of this maze and work backwards. And on another day, you might walk in and go no, no, no, no, we need the happy path. And then, we kind of don't care about the unhappy paths, so they're secondary. Let's just document the right way to do it, right? And so, it can go either way. \n\nI have one last thought on the right-hand versus left-hand hand. If you're listening to this and you don't know who Steve Mould is, M-O-U-L-D, he's a British mathematician, scientist, YouTuber. He's really gotten on this kick lately of building physical models of logical ideas. And what he discovered is that you can use water to solve a maze. By pouring water into a maze, it will always solve the maze, which is really, really neat. \n\nThe reason I think it was lovely—and this is the right hand versus left hand—any system you divide into binary pieces will, when you get to the other side, fall into two separate halves. They might not necessarily be equal halves, but there will always be exactly two halves. And Steve discovered this in his...if you go watch Can Water Solve a Maze, he was laser cutting acrylic mazes, clear plastic so that he could pour colored water for the camera, for YouTube, right? \n\nAnd he said, \"This weird thing started happening. I started cutting out these mazes. And when the laser got to the end of the maze, half of the maze fell off of the cutter. And the other half, it was exactly two pieces, the left-hand side of the maze and the right-hand side of the maze.\" Whichever rule you follow, if you put your hand on the right-hand side of the maze, you will not touch the left-hand side of the maze ever. And vice versa, if you start on the left, you'll never touch the right half of the maze. It will divide into two exactly separate halves. I thought that was super cool. \n\nMIKE: That is cool. \n\nDAVID: Folks, this was lovely. Thank you for coming out on the podcast. Hailey, I appreciate your comments. Dom, Eddy: love having you guys chat on the call. This was a lot of fun.","content_html":"The panelists continue for part two of their discussion on testing code with RSpec!
\n\n\n\nMike kicks things off with a maze metaphor, illustrating the importance of navigating code branches. He emphasizes the branch-focused approach for comprehensive test coverage and cautions against excessive testing of external libraries while highlighting the significance of testing public interfaces.
\n\nThe episode also addresses the hurdles newcomers encounter when venturing into the world of RSpec. Hailey and Eddy share their initial struggles, likening it to learning a new language. They agree that familiarity with RSpec's unique language and structure grows with time.
\n\nIn the latter part of the discussion, Eddy and David share insights on RSpec's error messages. Eddy expresses frustration with cryptic messages, particularly involving hashes and scientific notation. David recommends using the --format documentation option in RSpec to enhance error message clarity and suggests writing descriptive context, and it blocks for improved test readability. Mike highlights the importance of enhancing error messages and proposes an unconventional approach to structuring tests while emphasizing the value of starting with the unhappy path.
All said and done, this episode takes you on a journey through RSpec, covering testing strategies, best practices, newcomer challenges, error message improvement, and intriguing insights into test structuring. It underscores the significance of clear error messages and offers valuable guidance for enhancing test readability and effective debugging.
\n\nTranscript:
\n\nDAVID: Hello and welcome to the Acima Development Podcast. I'm David Brady. I'm hosting today. We've got a really great panel. We've got Ramses, and Jonathan, Freedom, Mike, a couple of people snuck in. I think I see Eddy. Hailey just walked in. This is going to be a good episode. We're going to talk about how to organize RSpec to make it a little more understandable and how to deal with some of the difficulties in it. Mike has a thing to drop on us.
\n\nMIKE: And the way that I'd like to kick this off is to talk about a maze, either a maze or a cave. Visualize your pick. You're either going to walk through a labyrinth above ground, or you're going to walk through a labyrinth below ground. Either way, you're lost in endless passages that branch here and there. You know that you want to find your way out, right? There is a way out, but going into this maze or this cave, you don't know which way that is. And how do you solve that problem?
\n\nI'll make a proposal here of a solution, a straightforward solution. And here's my proposal: Every time you come to a fork in the path, you have the ability to mark it, right? And this is actually a very simple rule. One way you can do this is just to always go right [laughs] first, right? You always turn right when you get to a branch. You explore to the right. And then, once you get to another branch, you go right. You get to another branch; you go right. You get to another branch; you go right. There's even a name for this in the computer science literature of, you know, you're doing a depth-first search.
\n\nYou're going to go down as deep as you can in the cave, right? You're going to go follow that all the way to the end. And when you reach the end, you backtrack to the previous branch. And then, you turn left, and you don't turn left down any branch until you've explored as far as you can to the right. And then, you can go and explore down that branch to the left. And then, again, you have your right rule where you're going on as deep as you can. You come back, and you backtrack. When you finally have to, follow the left. And you keep on doing that, making sure that both sides, both branches, at every point until you've explored the full maze.
\n\nI actually read about this once. I've thought about this since I was, like, a teenager because I read once that they design mazes for which this rule doesn't work. I'm like, wait, what? How? Well, the way that you design mazes doesn't work as you have concentric rings, which means the branches don't quite follow the right rule. Because if you have concentric rings and your solution is at the center, you can have a wall all the way around at the outermost layer. All of the turns are left. And if you turn left, then you're just going to be going around a ring again. So, at every point, the rule doesn't work. But you can make some minor adjustments to it to kind of make it work.
\n\nBut in a traditional maze, like the kind that would be underground in a cave, they can't do that sort of thing generally. You have to follow one branch or the other. And why am I talking about this for RSpec? I say this because our goal when we are testing code is to get coverage. We want to make sure that everything works. And a lot of times, we think, well, my code is really sophisticated. It does really interesting things, which is probably true. When you break down those interesting things, in the end, they tend to be binary decisions. You go right, or you go left. It's a decision tree.
\n\nAs you follow down on your code, at every point in your code, you're either executing something, in which case you're always going through it, or you have some sort of condition. And sometimes, I will say, sometimes those conditions are implicit. It doesn't always include an if clause, for example. A return sends something out or a break. Maybe it's not explicitly doing an if, but there's some implicit types of conditions. Either way, it's a branch.
\n\nAt every point in your code, it's either going to go straightforward, right? It's going to keep on executing through instructions, or it's going to branch somehow. And if that's what your code always is, which it should be, it's either going to progress linearly, go through procedural step by step, or it's going to branch. And so, if you want to have complete coverage of your code, then what you need to do is simply cover every branch.
\n\nI'm going to stop on that for a second because I think it's a critical realization that's really helped me with RSpec. Because if instead of thinking about my code as a set of functions and maybe I've got some anonymous functions, and classes, and objects, which is all true, from a testing perspective, I think that your code is just a set of branches. I don't really care about your objects other than as entry points. What I care about from the testing perspective is coverage. So, I care about the branches.
\n\nAnd thinking about it from that branching perspective changes your mindset. You're exploring the cave, right? And you want to explore every branch. And once you've changed that from thinking about it as this sophisticated, beautiful labyrinth, which it may be, from a testing perspective, you should think about it differently. You should think about it as a bunch of branches. It's a tree with branches. And if you cover all the branches, your testing is complete.
\n\nI'm going to pause there for a second to think about the metaphor. Well, RSpec has tools to do that, but I'd like to talk a little about the metaphor first. That's how I kind of wanted to introduce our discussion. I had that idea in mind before we talked.
\n\nDAVID: Now I'm very excited about this because I'm either going right where you want me to go or I'm hopping into, like, a just a weird hair up my brain spark, which is that when I sit down with a great, big thing to work on, I get daunted. I get blank page syndrome where I'm like, ooh, how am I going to get all this tested?
\n\nIn the maze world, I've heard this called the right-hand rule or the left-hand rule. And it's got an interesting property that if you put your right hand on the wall, then when you get to the branch, you'll go down, like, the right-hand side of the branch. You get to the room at the end of that thing. You walk around the outside of the room...or the inside of the room. You keep your right hand, and now you're leaving the room with your hand on the other wall. When you get back to the branch, you're now touching the wall between the thing you just went down and the next one over. So, you just keep your hand on it, right?
\n\nThe thing that I love about breaking it down this way is that it's very, very clear where you start, which is, to quote Alice in Wonderland, "At the beginning," right? And then, what do I test next? You've always got a next. It's hard to know how am I going to test all of this? I don't know. I don't know. But I know what I need to test first. And what do I test next? Well, when I finish the thing I was on, I'm just going to test the first thing that's left. It's a lovely, little recursive thing. You always know what's next until you run out of next, and that's when you're done.
\n\nMIKE: So well said. I've worked with a lot of people over the years who've looked at their code, like, where do I start this test? Because it is daunting. It doesn't just apply to testing. It applies to a lot of things. But we're talking about the testing problem, in particular, and that's exactly it. Well, what's the entry point of your code? And let's start by creating a context for your first branch. And there is your first step.
\n\nAnd once you've explored that, you know, and maybe you have to do some nested contexts in there because that branch branches. And you keep on exploring those nested branches until you get to the bottom. And you come back out, and you're like, well, okay, what's the next branch? And I maybe need another context [inaudible 07:02] explores the next one. And that's it. And you can run through the test just like that. And there's always a next step. It's really easy to think about. And the only thing you have to think about at every step is, well, what's the other branch?
\n\nEDDY: You know, Mike, I have a question regarding coverage. When writing tests for that file, in particular, should we always be shooting for 100%? And if not, what are the exceptions?
\n\nMIKE: Well, that's a great question. Let me answer it this way. And we're talking about RSpec. RSpec is so named because there's, like, a specification there, right? It's a way of specifying what your code does. And if we have not fully specified what our code does, then it isn't very good documentation, and there's undocumented parts of our code.
\n\nDAVID: I'm going to come at this from a completely different angle. I'm going to say something...here's my hot take: You should never be striving for 100%. You should be striving for what's the most important thing to test. Or like Mike's saying, literally, if you're going through an order, you branch. I like the branch, in my mind, between the most important thing that's in front of me and everything else. So, like, when I'm testing an API call, my first branch is the happy path. I want when I do call the thing; I want it to work.
\n\nThen, what I will do is I will branch into the unhappy stuff. What's the biggest, most important unhappy path? That's my next branch, and the next one, and the next one, and the next one. At some point, I'm going to realize I've tested enough or I'm out of functionality, especially if you're doing RSpec and you go in and you literally spec the code. You've all heard of TDD, Test-Driven Development. You go in, and you say, I'm going to call this API. And when I pass it this user and this status, I'm going to get back a 200 OK, and that user will be updated.
\n\nAnd I love how expressive RSpec is for this because it makes it very, very easy to specify what the code will do, and you haven't even written the code. You reach 100% the same way, which is you're like, what's the next thing I need to work on? Oh, I'm out of functionality to specify.
\n\nMIKE: I was just saying if you have a cave system that has multiple entrances, those should be seen as separate systems. Your code has a public interface, public methods. And those are the entry points, right? That's the entrance to the cave. You should go into every entry point that is public, and that's it. If it's private, well, then it's not effectively part of the code that you're testing because it's unreachable. The goal here is to specify every branch that is reachable through the public interfaces.
\n\nI'll put one other caveat here, which is that we should explore the boundaries of our unit of code because we're talking about unit testing here, not integration testing. We should explore the boundaries of our unit of code, which means that you get something that leaves, say, the class that you're testing. That should be mocked or stubbed, so you don't actually go beyond that point. You don't ever leave your cave.
\n\nMIKE: Mike, I take back every bad thing I've ever said about you. That was beautifully put.
\n\nEDDY: [laughs] I was going to say because then you get in the realm of integration tests, and that's not what you want.
\n\nDAVID: Yeah.
\n\nEDDY: But specifically, I was going to say, what if you have methods that just do trivial logic, but it's still public? At that point, should you be testing something so trivial as to, like, display a text or, like, decorate a text [inaudible 10:08]?
\n\nMIKE: Well, if your code is so trivial that it doesn't need to be tested, then why did you write it?
\n\nDAVID: There's actually a good answer to both of these questions. The testing push came around, like Y2K, late '90s, like with extreme programming. And those folks...and they were coming from Java where you could specify accessors. So, you could very easily say, this is a read accessor on this. It's a public entry point. Therefore, it is behavior; therefore, it should be tested.
\n\nAnd everyone kind of stepped back and said, "Yeah, but this is a language feature. It's never going to have a bug. It's never going to be a problem." And they collectively decided this is the one case when we do not test public behavior because it can't fail. Or if it does, you've got bigger problems, or you've literally misspelled the method name.
\n\nMIKE: You said something that I think was critical, which is related to what I said about not leaving the cave. You don't test outside your cave. That is, if you didn't write the code, you don't test it. If it's the language or the framework that is providing the feature, it's not your code, and you shouldn't test it because then you're testing somebody else's code. You're not testing your unit of code anymore.
\n\nDAVID: Right. 100%, I'm embarrassed to say how late in my career I got before really having this hammered home because it was this morning. I'm writing a thing that talks to an API. And I have always considered the HTTP library, like Ruby's Net::HTTP library, that's framework code. That's core library code. We don't want to test into that. But my application is going to talk to Net::HTTP. I might want to specify that the conversation there is handled correctly.
\n\nI've been on project after project after project where we've said, let's not use Net::HTTP; let's use Faraday. Or let's not use Faraday; let's use HTTParty. Or let's not use HTTParty; let's use Typhoeus. And just on and on and on and on all the way down the road. And I ended up getting to this point where I would walk around the application out the backend, where the cables go off into the internet. I'd use, like, WebMock and intercept calls going out over the wire to HTTP over the wire. It's a little bit of an exaggeration, but you get the idea. I'm all the way at the other end of Ruby catching these things coming out.
\n\nAnd I was talking with my team lead. And he's like, "Why don't you just stub the call to Faraday?" And I'm like, "But...but...but," right? Because if we change that library, it's going to change the conversation on my specs. It's going to break. I actually had to step back and go; I didn't write Faraday. I didn't write HTTP. I am writing the code that has the conversation with whatever web library. And guess what? That is exactly the kind of thing I want to test. I want to assert that I'm having the correct conversation with whatever web library I'm using. And I want to specify that it's having the conversation with that web library. You don't want to send Faraday calls to HTTParty, right? It's not going to make sense.
\n\nSo, yeah, like I said, a lot later in my career. It literally was this morning. I'm not exaggerating. I'm like, oh, oh yeah, I had a heuristic to make that call the other way around. And the trade-off there was that, yeah, sometimes I end up testing library code that I didn't write. And, [vocalization], boy, yeah, sometimes you run into trouble because the library maintainer can change their implementation. And yeah, you see the trade-off there, right? It just spooled out of control. You don't want to do that. Never test a Rails private method.
\n\nMIKE: And, again, let's make sure we're making the distinction between unit tests and integration tests.
\n\nDAVID: Yes.
\n\nMIKE: And I think that's where we get into a lot of trouble. If you want to make sure your system works with another system, you should have a small set, I would argue, because they're really expensive and slow, of tests to make sure that integration works, which is different from your standard test suite that you run over and over and over again because it's fast and effective, and it doesn't break all the time.
\n\nDAVID: Right. Right. I realized the other part of the trade-off is that coming from API land previously in my career; I'm used to being handed a JSON document of post this to our REST server. And we will give you—then they hand me another JSON document—we'll give you this document in return. And having that and being able to specify that exactly I want this many bytes to go out, and I want these exact bytes to come back, then it does make sense.
\n\nAnd, like you said, integration test. Yeah, you don't want to test 401, 403, 405, 422, 404, every single possible 400 error. You don't want to test every one in an integration test. These things take forever, relatively speaking. Maybe I fire you the happy path, and I stub out with a response. And then I fire out one or two unhappy paths, and then we're done. We walk away.
\n\nMIKE: So, I've talked a lot about my idea of how to test branches. For me, it's been kind of an epiphany [laughs] when I saw this, and it's relatively late in my career as well, not quite this morning but not five years in, to realize, oh, well, all I'm doing is testing branches. But, you know, having that different lens with which to see the world has dramatically affected testing.
\n\nAnd I've seen it really work well for other people as well. People who were just banging their heads, like, where do I start? Were able to very quickly progress by thinking about things through that lens of, well, what's just my next branch? And there may be others on this call who've approached things that way, and I'd be interested in hearing other people's experience with that approach.
\n\nEDDY: You know, I'm kind of curious in gauging people's perspectives here. Everyone on this call, I think, to some degree, has touched RSpec for the past couple of months. I'm curious to gauge what other people's perspective was the initial exposure that they had to RSpec. Did it give a facade of difficulty, and if it did, to what degree?
\n\nDAVID: I got into RSpec with version 1.0, which put the should method on every object in Ruby, like, throughout the entire space. Of course, in Ruby, even integers are objects that you can call methods on. And so, you could literally write three dot should equal three. That was the moment that test-driven development really lit up. And I'm like; I can write this before; I mean, there was nothing stopping me from saying assert equal three comma three prior to this. But, for some reason, in my brain, assert equal three; three is something you write after. You know, assert equal, A plus B equals five, right?
\n\nIn my mind, that's something you do after you have written the code, and you're just trying to button things up and prove to the maintainer that it works. But, in my mind, A plus B should equal three. It pushes you to say, hey, write this before you write the code. We're not going to say it does equal three; we're going to say it should equal three.
\n\nAnd I really liked that RSpec, when they got rid of the should monkey patch—which makes me sad, but I understand why people get rid of it—I liked that they kept that future subjunctive tense by saying, we're not going to assert. We're going to expect. And so we say expect A plus B to equal three. It's a little easier for me to write that after the fact and see it kind of in both verb tenses. But it does let me hang on to that bright torch of, I'm going to write this, and then I'm going to go write the code, which I realize is tangent to the topic of today, which is making RSpec easier. But, you know, it's my baby, and I like to show it off.
\n\nHAILEY: I'll speak on my first experience with RSpec. I feel like it was probably just a few months ago. I think as interns joined in on The Skills Clinic, we were working on some advent of code. And we were, like, in the middle of the project. So, we didn't see, like, the spec being created. I just saw, like, a completed spec file, and I think that was really confusing for me. Because, like, I feel Ruby is similar enough to other languages that I was able to understand, okay, this is, like, a loop. This is an if statement. You know, I'm returning this section of code, things like that.
\n\nBut words like describe, and let, and subject, context, before do blocks I hadn't seen those before. And so, that was all really new to me. And to just see, like, 50 lines of code of things that I hadn't seen before that was really confusing. And then, once we ended up breaking it down, and once I was able to write my own spec and see them being written, not just a completed spec, that really helped me understand how RSpec works.
\n\nDAVID: Nice.
\n\nEDDY: That was my same experience when I first picked up on RSpec to [inaudible 18:26] in QA. When I first started, I was like, wow, what is this whole other language, right? Like, how is the structure, and why is every one so opinionated? [laughs] And how this is written. So...
\n\nHAILEY: Right. It seemed like a different language.
\n\nEDDY: Absolutely. You got some overlap here and there, very subtle. But overall, yeah, it can be a bit overwhelming if it's the first experience with it. So, I think that's, like, sort of, like, makes it a little difficult for new developers who are testing in RSpec initially, right? There's, like, some sort of ramp-up to it.
\n\nDAVID: Yeah. And there are some surprising things that come from that, right? If you pick up, like Jasmine, which is a JavaScript testing framework inspired by RSpec, then it has context and describe, and it. It's a function that takes the name of the thing that you want to describe or specify. And then, it takes a Lambda of just the function you want to execute when that happens. And that's kind of what you see in RSpec, right? You see, describe, and then a thing, and then do/end. And the do/end is like that...it's a proc. It's literally a block of code that's going to get executed as, like, an anonymous function.
\n\nBut it's really easy to just go, oh, it's magic, and I don't need to worry about it. And that's absolutely true 99% of the time. But eventually, you start wondering, how does this function ever get called? And that's when you start lifting up the tablecloth and looking underneath RSpec, and you start seeing that, oh, that it do it doesn't define a method. It defines a class. A what? Yeah, it defines an entire class, an anonymous class. Its execute method...I can't remember the name of it. Is it run? It might be a run () method, but it's got a method on it that will, you know, execute the test.
\n\nAnd when you run RSpec over, like, a directory, it picks up every one of these files. And that it do makes a class, it do makes a class; it do makes a class. And then those three classes are inside a context, which makes a class. And the definition of that class is define these three classes that we just talked about. Once they are all defined, and everything is completely loaded, that's when RSpec says, okay, you know, roll call, who all did we get defined? Okay, cool. Start at the beginning and start running your stuff. And it starts executing it through.
\n\nAnd that is why you can end up with, like, this really weird stuff, like, where you have a spec that fails, and instead of giving you, like, the name of the spec, you end up with example three, bracket five, bracket two, and you're like, what...what is this? Well, okay, it's actually you were doing it do context do without a name. You were just doing, like, it do. Like, you used subject instead of saying, you know, describe thing. You're just like, well, describe do. You shouldn't do that, but you can. And there are people that if you can do it, they will.
\n\nAnd [chuckles], Robert, if you're listening to me, I love you. We can still be friends. I had a co-worker named Robert. He could point anywhere in a file, and he could tell you what the bracket offsets, the indexing scheme that RSpec uses under the hood. The point that I'm trying to make...I'm actually not going to talk all the way through to [inaudible 21:14]. I'm just going to assume that we all got lost in that weird classes of definitions because that's the whole point. It's magic, and 99% of the time, you don't need to keep track of it.
\n\nBut the entire point of this is there are people who will defend, like, Test::Unit, which is really, really old, Minitest, which is getting old. Minitest is very, very simple. The entire source code for Minitest used to fit on, like, two printed pages back when printing was a thing that people did in the world. So, it was very easy to understand everything Minitest does under the hood. And RSpec was just this document the size of, you know, the federal tax code. And so, trying to get your head around what it does was very, very hard.
\n\nSo, I 100% agree. Most of the heavy lift that RSpec does is to create this domain-specific language, a DSL for testing. Well, not for testing, for specifying the way code should behave and then making it behave that way. As long as it works the way you want, you don't ever have to open it up. And you're like, oh okay, yeah, once I've learned this language, then I can use it. And it's very fluent, and it's very easy to understand.
\n\nBut, Hailey, you are 100% right that I started that with once you learn that language, and it almost sounds like I said the word just right or easy. Or how hard would it be, right? No, no. I fully admit that that once implies not until, right? You have to learn the DSL before you can leverage it.
\n\nMIKE: But I will say something interesting about this. I'm going to kind of go back to the cave idea, this maze traversal, which is that RSpec is actually kind of opinionated. It lets you do a lot of things. But that syntax that it uses, those contexts, for example, encourage...just like Dave was saying about that should or that, you know, is expected or, you know, expect, there's some suggestion as to which way you should go.
\n\nRSpec doesn't have a lot of top-level methods, but it has describe. It has it, which is where your assertions go, and it has context. The workhorse of RSpec is the context. And a context represents a branch built into the framework. If you think, well, oh, I'm going to set up tests for a branch, and I'm going to give it an anonymous function, and conceptually and in practice, that's what's happening is you're saying this branch is going to get an anonymous function that will run the tests on it. And that's what RSpec is doing.
\n\nIf you want to know what that domain-specific language is doing, it is giving you the ability to set up a test for a branch. And I think seeing that and understanding that's what it's nudging you to do can help overcome a lot of apprehension.
\n\nDAVID: Absolutely.
\n\nEDDY: I do want to say that ever since I started testing with RSpec, I've hated red dots forever.
\n\nDAVID: You absolutely should.
\n\nEDDY: Anytime I see a red dot, I just hate it, period. Number two, I think what makes RSpec really difficult, especially for someone coming in fresh, is the fact that the error messages could be a lot better, right?
\n\nDAVID: Yeah.
\n\nEDDY: Like, some of the messages that you get for errors, you're just like, what are you talking about? Like, what do you mean no_args expected, [laughs] right?
\n\nDAVID: I have a strong opinion about that. Finish your idea, and then ask me about the errors.
\n\nEDDY: I was just going to say, I think what really makes it really difficult to pick up initially is just that the error messages that are spitting out, like, unless you have context on that, like, it makes it extremely difficult to really debug, like, what the actual bug is in your code.
\n\nDAVID: Yeah. So, here's my strong opinion. Please, please, please consider this. If you've never done this, do it as an experiment and, like, do it for a week. Do it every time. And that is, whenever you run RSpec, put dash dash format equals documentation. Or, if you're, you know, quick and in a hurry, dash F Space D. This turns off the dots. You don't get green dots, red Fs, and little yellow asterisks. What you get is this nested tree of text, and it gives you the object you're describing.
\n\nAnd if you've got a context of, like, you know, happy path versus unhappy path, it will put happy path on a line by itself indented underneath the object that you're describing. And then, when you're in the happy path, let's say we're going to describe the initialize merchant, you know, method, so you've got a describe, initialize merchant, well, that shows up as the third line indented twice underneath happy path.
\n\nSo, you get this beautifully indented tree of text, text, text, text, text. And then, you finally get, like, you know, it should create it at timestamp, you know. So, it's like, it sets created at your RSpec declaration, right? You get to that line in the documentation, and that entire line of text turns green if it passes, or the entire line turns red if it fails. So, that's the first half of the experiment.
\n\nThe nuance to this is run it in format documentation and read it as if you had never seen your code before or as if you were sitting down to train another intern on how your code works. And you really, really, really want them to be able to read that stuff on the screen and not have follow-up questions. So, have them just read your documentation and go, hmm, okay, seems legit, I got it.
\n\nEddy, this then circles back to your point. If you take the time to type out correct clauses in your thing...and it's real simple, never type context without typing when after it. So, I don't write context happy path. Instead of saying context user is unauthorized, I will write context when the user is unauthorized or when user is unauthorized. And then we get to the it, which is, you know, it redirects to the login page. It displays a 404 error, you know, a 401 error.
\n\nHere's the thing: when you run this in FD, in format documentation, the last step is force every single spec to fail and watch it in the format documentation. You will end up seeing, describe this API context, you know, on the happy path when the user is authorized. It logs them into the homepage. You get this lovely little documentation thing. And you're like, okay, yeah, logically, that follows all the way down. I got it. Cool, no problem. It's green. Everything is good.
\n\nNow, you make it fail, and then you scroll down to the error message. And RSpec will take all of those nested snippets of text and it will chain them together into complete mishmash gobbledygook that nobody looks at unless you were using the grammar. If you've been writing context when and, you know, describe, you know, da da da, also with, you know, context with this thing going on or with this flag set, all of a sudden, that error message down at the bottom...and these are the ones where you get, like, we're no longer showing the blocks at test. We just got, like, an error and the line of code that it was on.
\n\nYou get this chunk of red text that literally forms a sentence in English. On the happy path, when the user is authorized, and they log in, they get redirected to the homepage. And that whole thing is red, and it fails. Let's say we say the user's password, you know, doesn't match. We're going to assert that the text "Welcome, Eddy"...we're going to set this username with the name of Eddy. The text, "Welcome, Eddy," should be on the page.
\n\nSo, you get this long, red sentence. You know, on the happy path, when the user is authorized, they log in, and they get redirected to home. That's right. It failed. Then the error message on line 273 of your spec file: expected to find welcome, Eddy, but that text was not on the page. Now, without opening the code or the spec, you know what was going on when it failed. And you know what the program did that was wrong.
\n\nAnd I promise you, if you do this, this weird, oddly specific thing will happen, which is four out of five times, you'll go, oh yeah, we commented out the user welcome thing. You haven't even opened the code, and you know where the bug is. You know what happened. And that is this weird, oddly specific, delightfully pleasing thing that happens if you write context when, you know, describe thing context when it does a thing. And then, you run the format documentation and make sure it makes a sentence. It's lovely.
\n\nAnd then, anytime you have an expect, expect 42 to equal 43, and then see what exactly is the error message. Because you'll end up with somebody else's code, and they'll be like, "Uh, yeah, we tried to log in, but we couldn't. Oh, and the error messages on line 229 expected 42, but it wasn't." What? This helps me not at all. Well, it does help you. It's going to give you the line of code in, you know, what file and exactly the line of code. But now you have to open that file, and you have to go to that line of code.
\n\nWhereas if you get the error message expected to find "Welcome, Eddy" on the page but I didn't, you know exactly what's going on. And much of the time, you know exactly what you just did a few minutes ago. Like, oh yeah, we forgot to turn this back on. It's so delightful when that happens when you can literally debug your code without opening it. And a good spec suite will give you that.
\n\nEDDY: Yeah. I just kind of wish, like, the error messaging was a lot better. Like, this is sort of, like, going off the top of my head where it's sort of, like, class double [inaudible 30:10] expected arguments.
\n\nDAVID: Unexpected method, blah, yeah.
\n\nEDDY: Yeah. Blah, blah, blah. I'm like, that doesn't really make sense, right?
\n\nDAVID: Force your expectations to fail and run them and see how they fail, and then reconstruct your context. If it's really oblique...we had a meeting earlier where we were talking about whether or not we should display a link. And the code underneath it was, is this object not invalid? You can infer that we don't want to show this thing if the object is invalid. But I didn't realize in the API that if the object is valid, we absolutely should show it. There's no other conditions to check, right?
\n\nSo, if you get a red dot and it said, "Expected true got false," oh, that doesn't help. Does it? Right? So, if we then turn around and say, when the link is valid, it should show, then when that fails, you can say, hey, I expected the progress bar to show the link, and it didn't. Or the, you know, I expected it to be show link or, you know, to have the show link enabled, and it wasn't. Now, that error message takes you exactly where it was.
\n\nThere was another developer on the call that offhandedly said, "Why don't we just put, you know, not invalid in the code that calls it?" Show link is a conversation I want to have with a progress bar. Invalid or valid is a conversation I want to have with the model underneath it. And I don't want to have to remember that valid invalid implies show link, not show link, and that nothing else is part of that implication, right? I don't want to keep track of that.
\n\nSo, like, what you're saying, Eddy, we don't want to say, on line 73, this code failed, expected false got true. We want to say, on the happy path, when this link is valid, when I ask the progress bar, should I show this link? It should say, "Yeah, yeah, you should show this link." And then, you get the error message: expected false got true, or expected progress bar to be show link, which is a little bit awkward English.
\n\nBut, I mean, we expected that you know, to have the show link status be enabled, but it wasn't. And you're like, oh, okay, yeah, now I know exactly where we are. I know what conversation we're having with what object, and I know what the semantic meaning of that conversation is. Does that make sense, Eddy? I just realized you've now said twice this is hard to understand. And I'm like, oh, no, no, no, [inaudible 32:22]. And I just realized I'm just throwing words at you. Is this helping at all?
\n\nEDDY: Yeah, yeah, yeah.
\n\nDAVID: You can say no. The listeners will laugh.
\n\nEDDY: [laughs]
\n\nMIKE: You know, Dave is saying use RSpec differently, and the errors will make more sense. Distill all that down. And I think that there's a lot of truth to that. It's easy to map, and I think it's kind of instinctive (I think I did it when I first used RSpec.) to map frameworks that are, like, Test::Unit style that are run assertion, run assertion, run assertion to RSpec, which has a different paradigm.
\n\nRSpec is designed to be thought of as a documentation generator as much as a testing framework. It says [inaudible 32:59] the same thing. And if you use it that way, you will have a different experience, that you will be much less likely to have those. This error makes no sense because you're looking at as documentation. And if it's formatted differently, then you don't just get a bunch of green dots with one red dot and a cryptic message. Instead, you get this documentation, and you get the line in the documentation that doesn't work.
\n\nAnd you're like, oh, the documentation doesn't apply here, and that gives me something. It may not be perfect. And a lot of times, the errors are just, you know, Ruby errors. So, they're language errors rather than RSpec errors. And then you have to make, like, oh, so, I have to figure out what's going on with my tests. But you at least have something to hang on to. I do think that changing that mindset is a big part of how you make those error messages less cryptic, is you think about the problem differently.
\n\nDAVID: Interestingly enough, that is the reason...the thing that we just talked through, the error messages in particular, is the reason that I won't ever use the subject method in RSpec if I can avoid it. And I definitely...if I use it, I will not write it do without text or context do without text. And the reason why is because RSpec will almost obfuscate the error message. Like, you literally will get, example, 3 of 5 of 1 expected 17 got 15. Good luck.
\n\nNow, not only do you have to track down where the code went wrong or where the spec went wrong, but you have to start winding up through the top of the file to figure out what did the spec set up before [inaudible 34:26]? Yeah, just type. Type some text on the context and the it.
\n\nI realize what I described sounds really hairy. Like, I've shown a couple of people, and they're, like, oh, this is too much of a headache. Context when it does, and run it, and look at it, and make it fail, and read the sentence. It will take you less than half an hour to completely internalize it. 5 or 10 times through the loop, and you'll have it. It's opaque at the beginning, but it's a skill that you can master very, very quickly. It'll click very quickly.
\n\nMIKE: And, again, on the branches, what else would you write? If you're describing when some set of conditions apply, well, you probably ought to have some text that says when some set of conditions apply. It's just the natural...RSpec is opinionated without necessarily saying so. Think about your branch of code. What branch of code applies when these conditions apply? Or maybe if or, you know, it's conditional. It begins with a word that suggests conditionality that, again, maps to the way that you're structuring it.
\n\nSPEAKER: Speaking to the RSpec, errors aren't top tier; I was working on something the other day. And essentially, some of it just consisted of adding a new field to just a hash that was returned by some function call. And I was looking at the RSpec because it just kept failing. And I was like, what's going on? Like, what is the reason for this?
\n\nAnd it said that it failed because all the decimal values that are returned were returned in scientific notation instead of, like, just regular decimal notation. And I was like, why is this happening? This doesn't make any sense. Turns out it was just because the test file wasn't accounting for that added field to the hash. So, it was like, it didn't tell me exactly what was wrong. And it actually told me something wrong that was wrong.
\n\nMIKE: But you saw it said, "These hashes don't match," right? And you looked at it and said, over on the left side, these are a fixed number of decimal points. And over on the right side, they're not. And so, they were things that RSpec could say were equal, but when it displayed them out, they weren't quite equal. And so, you were looking, oh, these aren't equal. Where's the problem? Because, you know, it kind of obscured it because you couldn't tell where the mismatch was.
\n\nSPEAKER: Exactly, yeah. It was a bit strange at first, but having a very written-out English sentence would have made that about ten times easier to recognize; oh, this is the problem. That's why this is going wrong.
\n\nDAVID: There's a subversion or an extension of this. It's interesting because, like, when we talk about RSpec exception errors aren't top tier, I'm having this instinctive reaction. And I'm trying not to, like, am I trying to defend my baby here, you know, out of just loyalty? And I realize, no. No, it's because that context when and the it, you know, describe noun, describe when, you know, it verb, da da da...RSpec, for me, is top shelf. It is the best error message. But I realize now it's because I write them that way.
\n\nI've tried to port that to Minitest and Test::Unit, and you can kind of, but it's a lot more work. It doesn't flow as naturally. And that might just be a translation and familiarity thing for me because I'm familiar with RSpec. But I 100% agree that hashes do not match, especially if it says expected, and then you get, like, two and a half lines of text with a dot dot dot in the middle of it because RSpec finally just said, I'm just going to have to give you an ellipsis. But I actually got two and a half lines of text with a dot dot dot in the middle, right?
\n\nYou can get RSpec to give you just as much information and not waste as much screen real estate by just typing RSpec or or echo; it didn't work. And that will just suppress all the output from RSpec. And if it fails, there's a mistake in there somewhere. Good luck. Have fun, right? And hashes [inaudible 37:58] math is terrible. It really is terrible.
\n\nEDDY: Well, that's why I started to adopt hash including versus double splat, right?
\n\nDAVID: Yeah. So, there's a subtle trick also that you can do. You can write this; I say don't. You can say we're going to describe this hash, and all the fields should match. And you can write out; it should match. And then, inside the it block, you write, you know, for key value in expected, actual subkey should equal, you know, or expect the actual key to be the expected key, right?
\n\nAnd that's great, except that you're going to end up with an error message that says, hey, on line 27 of this thing, which is inside a for loop, you have no idea which index you were on when the for loop failed. Because that thing did 150 expects, and you have no idea which one failed, right? And you're going to get an error message that said something like, "Expected blank string, got nil." Oh, good luck. Which field out of that was it, right?
\n\nIf it was expected, 123 Fake Street got nil; okay, I've got a street address that's missing, right? But it's when you get something that's, like, it could be any of them, right? Expected, you know, AAA got BBB. Oh great, where's my As and Bs? You know, what does that mean, right? If you're going to play that game, take that hack and pull it.
\n\nBy the way, this is where the fact that RSpec is compiling classes becomes like black magic awesome. Because you can take that hash outside, you can't use a let, but you actually have to define it right there in the Ruby code of key value, key value, key value. But you do it in the source code outside of the let, or the describe, or outside of the it or the describe, and then you say a key value. And inside that key value, that each loop, you say it, and then in the text you say, should have field, you know, and then the field name key equal to, you know, field value. Or, you know, field key should match, right?
\n\nWhat happens when RSpec processes that file it hits the loop, and it generates. If there's 150 key values in that hash, it generates 150 it blocks, expectations. And because you put the variable in the it description text, now when it fails, that is the text that RSpec will give you in the failure message. You'll actually get a thing that kicks out and says, "Hey, address line two does not match, expected a blank string, got nil." Oh yeah, okay, yeah, we weren't reading in the department or the suite number off of the address. Oh yeah, look at that. We don't even have that column on the model. That's why it's nil, right?
\n\nYou can make RSpec lead you by the nose and point you, right? You know, hold your nose right up to the air and say, this is it. It's right here, and this is why it happened. But you do have to make RSpec do it. You have to learn, again, like, context when, context when. If you take anything from this, put when whenever you do context, and then describe a condition when on the happy path. It really does help.
\n\nMIKE: If I make one other suggestion --
\n\nDAVID: Sure.
\n\nMIKE: Take this cave metaphor a little further. I love what you just said about making sure that every single expectation actually, you know, on the it block or on the context block has documentation. And one other place that people tend to struggle with in Rspec is how to do the setup. How do I set up my before or my let? And this is maybe a place where there's less clarity. It doesn't force you as much.
\n\nBut I have found...and it sounds like my thinking is similar to yours. You say you put the unhappy branch first. Well, I would say that's correct. If you're exploring a cave and you're looking for the way out of the cave, or you're going through a maze, well, you're definitely going to go through the non-solution first, right? [laughs]
\n\nDAVID: Oh, that's interesting. Finish your thought. I do it exactly the opposite. I put the happy path first. But carry on.
\n\nMIKE: Well, and I think that there's a very compelling reason, an extremely compelling reason to put the non-happy path first and have the happy path at the bottom, and it's this if you do your setup for the happy path, so your let blocks, you know, your before each, whatever it is to do your setup, your mocking, your stubbing; if you set that up for the happy path and then you begin by testing your unhappy path, then what ends up happening is every branch of your unhappy path you're only saying what's wrong if the authentication fails.
\n\nAnd then, you're overriding one piece of your setup. It allows every single context to have just a couple of things that's going to say, "This is the thing that's wrong." And you're going to see an it block that says, "And it doesn't work." And it becomes trivially obvious to read through your spec and say, oh, this is the thing that's wrong here. This is the thing that's wrong here. This is the wrong thing; it's here. Because at every branch, the only thing that you're overriding is the one piece of your setup that is broken at that part of the branch.
\n\nAnd then, when you finally get down to the deepest level, you've reached the bottom of the cave. And hey, there's the door out. There's no setup at all because you've exhausted all of the bad conditions, and all that's left is, hey, the setup works.
\n\nDAVID: Oh, that's neat. You were halfway through that, and I was making the meme of the stick figure guy who's going "[vocalization], you know, I've got a reply for you." And then, halfway through, he's like, "Oh," just kind of deflates a little bit. And he's like, "Hmm, yeah, you're right."
\n\nI'll extend it one more step, which is that if you start with a working thing, you are blacklisting your errors. Instead of whitelisting one functioning thing, it's easy to go through and break one thing, one thing, one thing, one thing. Anything you forget to break will not get tested, and the object will pass. If you start off with a blank object and only populate in every single test, that can get exhausting if you're populating all the fields, you know, unrelated fields each time through. But there's some value in that, right? Sometimes you're like, I want this object to kick and scream and just refuse to be valid until the last possible minute. Yeah, I like that.
\n\nMIKE: I imagine you could thread through this in either direction. You know, some people work their mazes backwards.
\n\nDAVID: There is a left-hand rule as well as the right-hand. It works exactly how you think. Yep.
\n\nMIKE: And the key part there is that this is what's different in this branch. Here is everything. You want to make it really obvious this is the part that's different, and this is what happens. And you want it to be designed such that you have to go through all the branches to get to the end.
\n\nDAVID: I kind of like that. From, like, a documentation, like, teaching a maintainer how this works, I kind of like having the happy path be first, from a, you know, like, this is how it's supposed to work. Now, let's talk about all the ways it can go wrong. But I like that idea as well of, like, yeah, this thing is wrong. It will not be right until everything is right. So, I think that's totally valid. It makes sense.
\n\nMIKE: Right. I think that either way, starting with the wrong or starting with the right could work that the critical part is that you follow a direction like that, right? And this is another thing that people have problems with with RSpec. You have to go digging around and looking for what the context is [inaudible 44:30]. The only thing that you should see in your context is what's different. You could say that, well, I just can do all of my setup. Here's everything that's right, and here's the one thing that's different. But I think that that can actually be problematic because it's noisy. I want as little noise as possible.
\n\nDAVID: Yeah. I had it driven into me recently that there's no such thing as a solution; there's only a trade-off. And you have to decide what side of the trade-off you value. You might come into a thing where you know what? The left-hand rule is actually more important. I want to start with the wrong end of this maze and work backwards. And on another day, you might walk in and go no, no, no, no, we need the happy path. And then, we kind of don't care about the unhappy paths, so they're secondary. Let's just document the right way to do it, right? And so, it can go either way.
\n\nI have one last thought on the right-hand versus left-hand hand. If you're listening to this and you don't know who Steve Mould is, M-O-U-L-D, he's a British mathematician, scientist, YouTuber. He's really gotten on this kick lately of building physical models of logical ideas. And what he discovered is that you can use water to solve a maze. By pouring water into a maze, it will always solve the maze, which is really, really neat.
\n\nThe reason I think it was lovely—and this is the right hand versus left hand—any system you divide into binary pieces will, when you get to the other side, fall into two separate halves. They might not necessarily be equal halves, but there will always be exactly two halves. And Steve discovered this in his...if you go watch Can Water Solve a Maze, he was laser cutting acrylic mazes, clear plastic so that he could pour colored water for the camera, for YouTube, right?
\n\nAnd he said, "This weird thing started happening. I started cutting out these mazes. And when the laser got to the end of the maze, half of the maze fell off of the cutter. And the other half, it was exactly two pieces, the left-hand side of the maze and the right-hand side of the maze." Whichever rule you follow, if you put your hand on the right-hand side of the maze, you will not touch the left-hand side of the maze ever. And vice versa, if you start on the left, you'll never touch the right half of the maze. It will divide into two exactly separate halves. I thought that was super cool.
\n\nMIKE: That is cool.
\n\nDAVID: Folks, this was lovely. Thank you for coming out on the podcast. Hailey, I appreciate your comments. Dom, Eddy: love having you guys chat on the call. This was a lot of fun.
","summary":"","date_published":"2023-10-25T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/b076c97a-7e6c-4b85-9cf0-40ff5e09ce05.mp3","mime_type":"audio/mpeg","size_in_bytes":46283666,"duration_in_seconds":2826}]},{"id":"d7b98ae3-8ef6-4e5b-b70e-c11a311e3c29","title":"Episode 29: Why Is RSpec So Hard? (Part I)","url":"https://acima-development.fireside.fm/29","content_text":"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.\n\nThe 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.\n\nIn 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!\n\nTranscript:\n\nMIKE: 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. \n\nWe 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.\n\nBut 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. \n\nI'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. \n\nSometimes, 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. \n\nYou 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. \n\nBut 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. \n\nAnd 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. \n\nAnd 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. \n\nHere'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. \n\nAnd 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. \n\nSo, 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. \n\nAnd 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. \n\nOther 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. \n\nAnd 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. \n\nIt 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. \n\nRSpec 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.\n\nIf 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. \n\nI'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? \n\nJUSTIN: 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.\n\nI 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. \n\nAnd 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. \n\nMIKE: 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. \n\nInstead 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. \n\nBut 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.\n\nDAVE: 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. \n\nAnd 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.\n\nAnd 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. \n\nBut 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. \n\nAnother 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. \n\nAnd 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.\n\nAnd 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.\n\nMIKE: 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.\n\nDAVE: 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.\n\nMIKE: 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. \n\nNow, 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. \n\nThere 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. \n\nDAVE: Yes. \n\nMIKE: 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.\n\nIn 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. \n\nAnd 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. \n\nIf 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. \n\nAnd 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. \n\nSo 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. \n\nThe 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.\n\nDAVE: I like all of that.\n\nEDDY: 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?\n\nFor 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.\n\nMIKE: 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.\n\nIf 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.\n\nDAVE: 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.\n\nMIKE: [laughs]\n\nDAVE: 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. \n\nIn 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.\n\nBut 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. \n\nThere'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. \n\nSo, 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. \n\nOh, 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. \n\nBut 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. \n\nIf 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.\"\n\nWhat 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.\n\nMIKE: 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. \n\nFor 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. \n\nAnd 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.\n\nDAVE: 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. \n\nThe 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. \n\nI 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. \n\nAnd 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. \n\nAnd 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. \n\nAnd 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. \n\nSo, 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. \n\nThe 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. \n\nSo, 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. \n\nIf 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. \n\nYou 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. \n\nSo, 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. \n\nIf 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.\n\nYou 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.\n\nMIKE: 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 --\n\nDAVE: At the minimum? Everything would be in the block, in the it block, right?\n\nMIKE: That's interesting. And I think that the answer is no. Because if --\n\nDAVE: Ooh, some things should be far away. Sorry, sorry, I think I just picked up your breadcrumb. Go ahead.\n\nMIKE: 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. \n\nDAVE: Because it has nothing to do with the database login. \n\nMIKE: 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.\n\nIf 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. \n\nBut 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. \n\nAnd 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. \n\nAnd 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. \n\nNow, 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.\n\nDAVE: 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. \n\nMIKE: [laughs]\n\nDAVE: 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. \n\nSo, 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. \n\nAnd 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. \n\nA 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? \n\nI 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. \n\nWhen 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. \n\nBut 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? --\n\nMIKE: 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? \n\nDAVE: Yeah. \n\nMIKE: 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? \n\nDAVE: Mm-hmm.\n\nMIKE: 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. \n\nAnd 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.\n\nDAVE: 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. \n\nThe 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.\n\nMIKE: So then we're in agreement. [laughs]\n\nDAVE: 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. \n\nSo, 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. \n\nIt'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? \n\nAnd 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. \n\nAnd 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. \n\nWhat 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. \n\nSo, 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. \n\nBut 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.\n\nMIKE: Oh, and I would agree with you strongly because they shouldn't have overwritten that unless it was context-specific. \n\nDAVE: Yes. Yes\n\nMIKE: And so, we're in complete agreement because the minimal rule applies.\n\nDAVE: 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. \n\nAnd 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. \n\nI 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. \n\nAnd 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. \n\nI 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? \n\nMIKE: That's another episode, but I agree with you.\n\nDAVE: 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.\n\nMIKE: [laughs]\n\nDAVE: I'm done. I love you guys. Let's do another episode.\n\nMIKE: 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.","content_html":"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.
\n\nThe 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.
\n\nIn 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!
\n\nTranscript:
\n\nMIKE: 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.
\n\nWe 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.
\n\nBut 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.
\n\nI'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.
\n\nSometimes, 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.
\n\nYou 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.
\n\nBut 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nHere'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.
\n\nAnd 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.
\n\nSo, 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.
\n\nAnd 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.
\n\nOther 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.
\n\nAnd 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.
\n\nIt 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.
\n\nRSpec 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.
\n\nIf 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.
\n\nI'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?
\n\nJUSTIN: 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.
\n\nI 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.
\n\nAnd 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.
\n\nMIKE: 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.
\n\nInstead 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.
\n\nBut 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.
\n\nDAVE: 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nBut 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.
\n\nAnother 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nMIKE: 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.
\n\nDAVE: 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.
\n\nMIKE: 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.
\n\nNow, 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.
\n\nThere 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.
\n\nDAVE: Yes.
\n\nMIKE: 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.
\n\nIn 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.
\n\nAnd 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.
\n\nIf 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.
\n\nAnd 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.
\n\nSo 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.
\n\nThe 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.
\n\nDAVE: I like all of that.
\n\nEDDY: 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?
\n\nFor 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.
\n\nMIKE: 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.
\n\nIf 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.
\n\nDAVE: 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.
\n\nMIKE: [laughs]
\n\nDAVE: 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.
\n\nIn 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.
\n\nBut 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.
\n\nThere'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.
\n\nSo, 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.
\n\nOh, 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.
\n\nBut 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.
\n\nIf 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."
\n\nWhat 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.
\n\nMIKE: 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.
\n\nFor 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.
\n\nAnd 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.
\n\nDAVE: 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.
\n\nThe 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.
\n\nI 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nSo, 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.
\n\nThe 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.
\n\nSo, 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.
\n\nIf 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.
\n\nYou 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.
\n\nSo, 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.
\n\nIf 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.
\n\nYou 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.
\n\nMIKE: 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 --
\n\nDAVE: At the minimum? Everything would be in the block, in the it block, right?
\n\nMIKE: That's interesting. And I think that the answer is no. Because if --
\n\nDAVE: Ooh, some things should be far away. Sorry, sorry, I think I just picked up your breadcrumb. Go ahead.
\n\nMIKE: 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.
\n\nDAVE: Because it has nothing to do with the database login.
\n\nMIKE: 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.
\n\nIf 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.
\n\nBut 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nNow, 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.
\n\nDAVE: 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.
\n\nMIKE: [laughs]
\n\nDAVE: 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.
\n\nSo, 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.
\n\nAnd 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.
\n\nA 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?
\n\nI 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.
\n\nWhen 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.
\n\nBut 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? --
\n\nMIKE: 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?
\n\nDAVE: Yeah.
\n\nMIKE: 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?
\n\nDAVE: Mm-hmm.
\n\nMIKE: 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.
\n\nAnd 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.
\n\nDAVE: 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.
\n\nThe 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.
\n\nMIKE: So then we're in agreement. [laughs]
\n\nDAVE: 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.
\n\nSo, 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.
\n\nIt'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?
\n\nAnd 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.
\n\nAnd 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.
\n\nWhat 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.
\n\nSo, 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.
\n\nBut 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.
\n\nMIKE: Oh, and I would agree with you strongly because they shouldn't have overwritten that unless it was context-specific.
\n\nDAVE: Yes. Yes
\n\nMIKE: And so, we're in complete agreement because the minimal rule applies.
\n\nDAVE: 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.
\n\nAnd 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.
\n\nI 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.
\n\nAnd 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.
\n\nI 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?
\n\nMIKE: That's another episode, but I agree with you.
\n\nDAVE: 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.
\n\nMIKE: [laughs]
\n\nDAVE: I'm done. I love you guys. Let's do another episode.
\n\nMIKE: 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.
","summary":"","date_published":"2023-10-11T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/d7b98ae3-8ef6-4e5b-b70e-c11a311e3c29.mp3","mime_type":"audio/mpeg","size_in_bytes":48889271,"duration_in_seconds":2780}]},{"id":"9bdc99f2-e61e-49fe-ae07-ead2ec5b5eb4","title":"Episode 28: Who Are Your Mentors?","url":"https://acima-development.fireside.fm/28","content_text":"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.\n\nMike'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.\n\nKyle 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.\n\nTranscript:\n\nEDDY: 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? \n\nAnd 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. \n\nI'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. \n\nAnd 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. \n\nI 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. \n\nAnd, 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. \n\nSo, 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.\n\nAnd, 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.\n\nKYLE: 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. \n\nBut 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. \n\nAnd, 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. \n\nAnd 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.\n\nAnd 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.\n\nEDDY: 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?\n\nKYLE: 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.\n\nEDDY: 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?\n\nKYLE: 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. \n\nSo, 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.\n\nEDDY: 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.\n\nSERGIO: 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. \n\nSo, 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. \n\nAnd 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. \n\nI 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.\n\nEDDY: 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?\n\nSERGIO: 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. \n\nAnd 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.\n\nEDDY: 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.\n\nSERGIO: 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.\n\nEDDY: I agree. I can attest to that.\n\nRAMSES: 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.\n\nEDDY: Did you have mentors when you first started, and was that integral to your success?\n\nRAMSES: 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.\n\nEDDY: 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. \n\nDominick 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.\n\nDOMINICK: 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. \n\nI 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. \n\nBut 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.\n\nEDDY: 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? \n\nDOMINICK: 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. \n\nEDDY: 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?\n\nDOMINICK: 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.\n\nMy 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.\n\nEDDY: That's awesome. And, I mean, you had a dad as a direct influence who kind of set that path for you, right? \n\nDOMINICK: Absolutely. Yeah. \n\nEDDY: [laughs] So, to some degree, your dad sort of was a mentor.\n\nDOMINICK: 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.\n\nEDDY: Awesome. So, we got Mike Challis, that joined. Mike, you've been mentored, and you are a mentor. Am I right in that assumption?\n\nMIKE: You're correct in both respects.\n\nEDDY: 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.\n\nMIKE: 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. \n\nAnd 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. \n\nJumping 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. \n\nHe 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] \n\nAnd 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. \n\nAnd 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. \n\nAnd 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. \n\nYour 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. \n\nYeah, 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. \n\nBut 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. \n\nYou 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]\n\nEDDY: So, how long would you say that you've been in the role for mentoring?\n\nMIKE: 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.\n\nEDDY: 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.\n\nMIKE: 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. \n\nSomething 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. \n\nAnd 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. \n\nSo, 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. \n\nWell, 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.\n\nSimilarly, 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. \n\nBut 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.\n\nEDDY: 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. \n\nSo, 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.\n\nRAMSES: 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.\n\nMIKE: 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.\n\nRAMSES: Oh yeah, definitely.\n\nEDDY: 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? \n\nLike, 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.\n\nMIKE: 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. \n\nI 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. \n\nIf 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. \n\nSomebody 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.\n\nEDDY: I agree with everything you said, Mike.\n\nKYLE: 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.\n\nEDDY: 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.\n\nKYLE: 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.\n\nEDDY: 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.","content_html":"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.
\n\nMike'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.
\n\nKyle 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.
\n\nTranscript:
\n\nEDDY: 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?
\n\nAnd 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.
\n\nI'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.
\n\nAnd 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.
\n\nI 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.
\n\nAnd, 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.
\n\nSo, 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.
\n\nAnd, 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.
\n\nKYLE: 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.
\n\nBut 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.
\n\nAnd, 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nEDDY: 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?
\n\nKYLE: 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.
\n\nEDDY: 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?
\n\nKYLE: 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.
\n\nSo, 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.
\n\nEDDY: 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.
\n\nSERGIO: 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.
\n\nSo, 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.
\n\nAnd 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.
\n\nI 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.
\n\nEDDY: 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?
\n\nSERGIO: 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.
\n\nAnd 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.
\n\nEDDY: 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.
\n\nSERGIO: 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.
\n\nEDDY: I agree. I can attest to that.
\n\nRAMSES: 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.
\n\nEDDY: Did you have mentors when you first started, and was that integral to your success?
\n\nRAMSES: 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.
\n\nEDDY: 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.
\n\nDominick 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.
\n\nDOMINICK: 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.
\n\nI 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.
\n\nBut 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.
\n\nEDDY: 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?
\n\nDOMINICK: 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.
\n\nEDDY: 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?
\n\nDOMINICK: 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.
\n\nMy 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.
\n\nEDDY: That's awesome. And, I mean, you had a dad as a direct influence who kind of set that path for you, right?
\n\nDOMINICK: Absolutely. Yeah.
\n\nEDDY: [laughs] So, to some degree, your dad sort of was a mentor.
\n\nDOMINICK: 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.
\n\nEDDY: Awesome. So, we got Mike Challis, that joined. Mike, you've been mentored, and you are a mentor. Am I right in that assumption?
\n\nMIKE: You're correct in both respects.
\n\nEDDY: 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.
\n\nMIKE: 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.
\n\nAnd 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.
\n\nJumping 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.
\n\nHe 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]
\n\nAnd 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nYour 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.
\n\nYeah, 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.
\n\nBut 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.
\n\nYou 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]
\n\nEDDY: So, how long would you say that you've been in the role for mentoring?
\n\nMIKE: 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.
\n\nEDDY: 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.
\n\nMIKE: 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.
\n\nSomething 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.
\n\nAnd 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.
\n\nSo, 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.
\n\nWell, 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.
\n\nSimilarly, 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.
\n\nBut 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.
\n\nEDDY: 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.
\n\nSo, 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.
\n\nRAMSES: 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.
\n\nMIKE: 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.
\n\nRAMSES: Oh yeah, definitely.
\n\nEDDY: 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?
\n\nLike, 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.
\n\nMIKE: 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.
\n\nI 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.
\n\nIf 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.
\n\nSomebody 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.
\n\nEDDY: I agree with everything you said, Mike.
\n\nKYLE: 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.
\n\nEDDY: 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.
\n\nKYLE: 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.
\n\nEDDY: 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.
","summary":"","date_published":"2023-09-27T12:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/9bdc99f2-e61e-49fe-ae07-ead2ec5b5eb4.mp3","mime_type":"audio/mpeg","size_in_bytes":36114576,"duration_in_seconds":2098}]},{"id":"b71759eb-60e0-4ebb-b70a-0b91793efd50","title":"Episode 27: How Do You Keep Learning When There Are Endless Things to Do?","url":"https://acima-development.fireside.fm/27","content_text":"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.\n\nThe 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.\n\nTranscript:\n\nMIKE: 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.\n\nWe 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. \n\nI 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. \n\nSo, 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. \n\nAnd 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. \n\nI 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. \n\nMy 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. \n\nIn 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. \n\nThese 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.\n\nBut, 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. \n\nAnd 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. \n\nIf 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. \n\nAnd 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?\n\nDAVE: 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.\" \n\nHe 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. \n\n2% 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. \n\nThere'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. \n\nI 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.\n\nMIKE: 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. \n\nWe'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. \n\nDAVE: 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. \n\nAnd 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.\n\nMIKE: 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] \n\nDAVE: Mm-hmm.\n\nMIKE: 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. \n\nAny 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].\" \n\nDAVE: 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? \n\nAnd 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. \n\nI 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? \n\nThere'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? \n\nThe 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? \n\nMIKE: 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.\n\nDAVE: 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. \n\nAnd, 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. \n\nAnd 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. \n\nI'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. \n\nMIKE: 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?\n\nEDDY: 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.\n\nMIKE: 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?\n\nEDDY: 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.\n\nMIKE: 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. \n\nYou 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. \n\nIf 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.\n\nI 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. \n\nSo, 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. \n\nKyle, where have you found success in growing your skills, even though you've always got an endless pile of work to do?\n\nKYLE: In my endless pile of work? \n\nMIKE: Uh-huh. [laughs]\n\nKYLE: 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. \n\nMIKE: Interesting. So, you're in a position where you're frequently being confronted with new and challenging things.\n\nKYLE: 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.\n\nMIKE: 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.\n\nKYLE: 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. \n\nMIKE: 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. \n\nAnd 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? \n\nYou 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.\n\nDAVE: 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. \n\nAnd 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. \n\nBut 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.\n\nMIKE: Yeah, I think that's well said. And again, this is not a criticism of coding bootcamps.\n\nDAVE: 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. \n\nAnd 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. \n\nMIKE: 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. \n\nI 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. \n\nSometimes, 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. \n\nTake 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. \n\nHas 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?\n\nKYLE: 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. \n\nAnd 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. \n\nBut 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.\n\nMIKE: 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?\n\nSERGIO: 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. \n\nSomething 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. \n\nAlso, 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. \n\nSo, 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.\n\nMIKE: 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. \n\nSo, 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.\n\nSERGIO: 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. \n\nRight 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?\n\nMIKE: 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.\n\nDAVE: 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. \n\nAnd, 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. \n\nIt'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.\"\n\nMIKE: 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. \n\nAnd 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. \n\nIf 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. \n\nHopefully, 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. \n\nSecondly, 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. \n\nFinally, 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.\n\nKYLE: 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.\n\nMIKE: Thank you. Talking about getting yourself in that uncomfortable situation, right? [laughs] Recognize that's okay, and that's how we learn. Thanks, Kyle. \n\nI 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. \n\nWe'll be here next time on the Acima Development podcast. Thanks.","content_html":"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.
\n\nThe 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.
\n\nTranscript:
\n\nMIKE: 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.
\n\nWe 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.
\n\nI 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.
\n\nSo, 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.
\n\nAnd 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.
\n\nI 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.
\n\nMy 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.
\n\nIn 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.
\n\nThese 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.
\n\nBut, 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.
\n\nAnd 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.
\n\nIf 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.
\n\nAnd 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?
\n\nDAVE: 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."
\n\nHe 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.
\n\n2% 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.
\n\nThere'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.
\n\nI 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.
\n\nMIKE: 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.
\n\nWe'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.
\n\nDAVE: 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.
\n\nAnd 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.
\n\nMIKE: 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]
\n\nDAVE: Mm-hmm.
\n\nMIKE: 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.
\n\nAny 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]."
\n\nDAVE: 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?
\n\nAnd 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.
\n\nI 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?
\n\nThere'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?
\n\nThe 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?
\n\nMIKE: 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.
\n\nDAVE: 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.
\n\nAnd, 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.
\n\nAnd 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.
\n\nI'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.
\n\nMIKE: 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?
\n\nEDDY: 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.
\n\nMIKE: 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?
\n\nEDDY: 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.
\n\nMIKE: 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.
\n\nYou 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.
\n\nIf 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.
\n\nI 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.
\n\nSo, 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.
\n\nKyle, where have you found success in growing your skills, even though you've always got an endless pile of work to do?
\n\nKYLE: In my endless pile of work?
\n\nMIKE: Uh-huh. [laughs]
\n\nKYLE: 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.
\n\nMIKE: Interesting. So, you're in a position where you're frequently being confronted with new and challenging things.
\n\nKYLE: 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.
\n\nMIKE: 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.
\n\nKYLE: 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.
\n\nMIKE: 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.
\n\nAnd 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?
\n\nYou 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.
\n\nDAVE: 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.
\n\nAnd 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.
\n\nBut 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.
\n\nMIKE: Yeah, I think that's well said. And again, this is not a criticism of coding bootcamps.
\n\nDAVE: 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.
\n\nAnd 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.
\n\nMIKE: 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.
\n\nI 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.
\n\nSometimes, 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.
\n\nTake 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.
\n\nHas 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?
\n\nKYLE: 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.
\n\nAnd 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.
\n\nBut 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.
\n\nMIKE: 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?
\n\nSERGIO: 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.
\n\nSomething 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.
\n\nAlso, 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.
\n\nSo, 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.
\n\nMIKE: 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.
\n\nSo, 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.
\n\nSERGIO: 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.
\n\nRight 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?
\n\nMIKE: 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.
\n\nDAVE: 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.
\n\nAnd, 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.
\n\nIt'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."
\n\nMIKE: 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.
\n\nAnd 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.
\n\nIf 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.
\n\nHopefully, 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.
\n\nSecondly, 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.
\n\nFinally, 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.
\n\nKYLE: 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.
\n\nMIKE: Thank you. Talking about getting yourself in that uncomfortable situation, right? [laughs] Recognize that's okay, and that's how we learn. Thanks, Kyle.
\n\nI 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.
\n\nWe'll be here next time on the Acima Development podcast. Thanks.
","summary":"","date_published":"2023-09-13T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/b71759eb-60e0-4ebb-b70a-0b91793efd50.mp3","mime_type":"audio/mpeg","size_in_bytes":37827027,"duration_in_seconds":2159}]},{"id":"f40d5e25-ad1a-4a9c-977a-a38cfcb18f1e","title":"Episode 26: Job Satisfaction","url":"https://acima-development.fireside.fm/26","content_text":"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.\n\nThe 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.\n\nTranscript:\n\nDAVID: 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?\n\nEDDY: We mostly try to figure out, like, what makes the job fulfilling for you, or, like, what do you like about the job?\n\nDAVID: 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.\n\nIt 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?\n\nEDDY: 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? \n\nDAVID: Yeah. \n\nEDDY: 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. \n\nA 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.\n\nDAVID: Yeah, no, that totally makes sense. \n\nMARK: 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.\n\nDAVID: 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. \n\nI 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. \n\nAnd 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]\n\nSo, 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. \n\nLike, 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. \n\nAnd 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. \n\nAnd 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. \n\nSo, 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. \n\nI 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. \n\nAnd 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. \n\nI'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. \n\nSo, 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.\" \n\nHe 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? \n\nAnd 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. \n\nAnd 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. \n\nLike, 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.\" \n\nYeah, 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.\n\nAnd 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. \n\nSo, 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]\n\nRAMSES: 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.\n\nDAVID: 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.\n\nEDDY: Yeah, that's me every day.\n\nMARK: That's why we're working here. We're being paid to learn, and we're using our knowledge to build up Acima.\n\nDAVID: Absolutely. \n\nEDDY: 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. \n\nDAVID: 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? \n\nRAMSES: Yeah. \n\nDAVID: Yeah, that's rare. \n\nEDDY: Not quite. [laughs]\n\nDAVID: Not quite?\n\nEDDY: Not quite. I'm almost there, but not quite. \n\nDAVID: You're moving into engineering, correct? \n\nEDDY: Yeah. \n\nDAVID: 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. \n\nI'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? \n\nAnd 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. \n\nAnd 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.\n\n[crosstalk 14:58]\n\nEDDY: 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. \n\nDAVID: Oh, wow.\n\nEDDY: 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. \n\nThanks 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.\n\nDAVID: 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. \n\nAnd 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.\n\nEDDY: Yeah. Yeah. No, I just wanted to make it known in case, you know, I've never expressed that. So, thank you for that.\n\nDAVID: Thank you. I'll give you your 20 bucks after the podcast. Thank you.\n\nEDDY: [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. \n\nDAVID: Yeah. \n\nEDDY: 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? \n\nDAVID: 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. \n\nThe 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. \n\nI 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. \n\nHe 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. \n\nLike, 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. \n\nSo, 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. \n\nAnd 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. \n\nAnd 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.\" \n\nNow, 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. \n\nAnd, 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.\n\nMARK: 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.\n\nDAVID: Yeah. I think we've beaten compensation to death. What's next on the list, Eddy?\n\nEDDY: 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. \n\nDAVID: 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. \n\nAnd 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.\n\nMARK: 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. \n\nDAVID: 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. \n\nI'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.\n\nMARK: Question is, where's the line between you just not being engaged and when you're just being a procrastinator? [laughs]\n\nDAVID: 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? \n\nAnd 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. \n\nBut 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.\n\nMARK: 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. \n\nAnd 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.\n\nDAVID: 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.\" \n\nAnd 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. \n\nAnd 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. \n\nThe 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. \n\nAnd 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. \n\nBut 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 --\n\nEDDY: That's --\n\nDAVID: We laughed, right?\n\nMARK: He played you guys.\n\nDAVID: Yeah.\n\nMARK: He played you guys. [laughs]\n\nDAVID: 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. \n\nEDDY: He found a way to engage you. And I think that's key, right? \n\nDAVID: Yeah. \n\nEDDY: 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? \n\nDAVID: Yeah. \n\nEDDY: 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?\n\nAnd 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?\n\nDAVID: 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? \n\nEDDY: Yeah.\n\nDAVID: 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.\n\nMARK: Now give me the damn pizza. \n\n[laughter]\n\nDAVID: 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]\n\nWe are getting close to the top of the hour. Do you want to just burn through the rest of the list?\n\nEDDY: Sure. The other ones are flexibility, proficiency, security, teamwork, and value. \n\nDAVID: Nice. \n\nEDDY: 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.\n\nDAVID: 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. \n\nIt 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. \n\nI 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...\n\nAnd 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. \n\nWe are out of time. Thank you very much. This has been a lot of fun. And I hope to see you guys next week.","content_html":"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.
\n\nThe 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.
\n\nTranscript:
\n\nDAVID: 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?
\n\nEDDY: We mostly try to figure out, like, what makes the job fulfilling for you, or, like, what do you like about the job?
\n\nDAVID: 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.
\n\nIt 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?
\n\nEDDY: 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?
\n\nDAVID: Yeah.
\n\nEDDY: 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.
\n\nA 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.
\n\nDAVID: Yeah, no, that totally makes sense.
\n\nMARK: 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.
\n\nDAVID: 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.
\n\nI 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.
\n\nAnd 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]
\n\nSo, 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.
\n\nLike, 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nSo, 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.
\n\nI 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.
\n\nAnd 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.
\n\nI'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.
\n\nSo, 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."
\n\nHe 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?
\n\nAnd 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.
\n\nAnd 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.
\n\nLike, 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."
\n\nYeah, 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.
\n\nAnd 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.
\n\nSo, 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]
\n\nRAMSES: 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.
\n\nDAVID: 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.
\n\nEDDY: Yeah, that's me every day.
\n\nMARK: That's why we're working here. We're being paid to learn, and we're using our knowledge to build up Acima.
\n\nDAVID: Absolutely.
\n\nEDDY: 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.
\n\nDAVID: 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?
\n\nRAMSES: Yeah.
\n\nDAVID: Yeah, that's rare.
\n\nEDDY: Not quite. [laughs]
\n\nDAVID: Not quite?
\n\nEDDY: Not quite. I'm almost there, but not quite.
\n\nDAVID: You're moving into engineering, correct?
\n\nEDDY: Yeah.
\n\nDAVID: 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.
\n\nI'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?
\n\nAnd 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.
\n\nAnd 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.
\n\n[crosstalk 14:58]
\n\nEDDY: 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.
\n\nDAVID: Oh, wow.
\n\nEDDY: 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.
\n\nThanks 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.
\n\nDAVID: 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.
\n\nAnd 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.
\n\nEDDY: Yeah. Yeah. No, I just wanted to make it known in case, you know, I've never expressed that. So, thank you for that.
\n\nDAVID: Thank you. I'll give you your 20 bucks after the podcast. Thank you.
\n\nEDDY: [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.
\n\nDAVID: Yeah.
\n\nEDDY: 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?
\n\nDAVID: 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.
\n\nThe 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.
\n\nI 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.
\n\nHe 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.
\n\nLike, 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.
\n\nSo, 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.
\n\nAnd 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.
\n\nAnd 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."
\n\nNow, 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.
\n\nAnd, 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.
\n\nMARK: 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.
\n\nDAVID: Yeah. I think we've beaten compensation to death. What's next on the list, Eddy?
\n\nEDDY: 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.
\n\nDAVID: 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.
\n\nAnd 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.
\n\nMARK: 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.
\n\nDAVID: 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.
\n\nI'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.
\n\nMARK: Question is, where's the line between you just not being engaged and when you're just being a procrastinator? [laughs]
\n\nDAVID: 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?
\n\nAnd 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.
\n\nBut 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.
\n\nMARK: 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.
\n\nAnd 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.
\n\nDAVID: 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."
\n\nAnd 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.
\n\nAnd 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.
\n\nThe 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.
\n\nAnd 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.
\n\nBut 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 --
\n\nEDDY: That's --
\n\nDAVID: We laughed, right?
\n\nMARK: He played you guys.
\n\nDAVID: Yeah.
\n\nMARK: He played you guys. [laughs]
\n\nDAVID: 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.
\n\nEDDY: He found a way to engage you. And I think that's key, right?
\n\nDAVID: Yeah.
\n\nEDDY: 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?
\n\nDAVID: Yeah.
\n\nEDDY: 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?
\n\nAnd 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?
\n\nDAVID: 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?
\n\nEDDY: Yeah.
\n\nDAVID: 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.
\n\nMARK: Now give me the damn pizza.
\n\n[laughter]
\n\nDAVID: 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]
\n\nWe are getting close to the top of the hour. Do you want to just burn through the rest of the list?
\n\nEDDY: Sure. The other ones are flexibility, proficiency, security, teamwork, and value.
\n\nDAVID: Nice.
\n\nEDDY: 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.
\n\nDAVID: 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.
\n\nIt 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.
\n\nI 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...
\n\nAnd 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.
\n\nWe are out of time. Thank you very much. This has been a lot of fun. And I hope to see you guys next week.
","summary":"","date_published":"2023-08-30T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/f40d5e25-ad1a-4a9c-977a-a38cfcb18f1e.mp3","mime_type":"audio/mpeg","size_in_bytes":32715294,"duration_in_seconds":2142}]},{"id":"6681eb68-a182-4c19-99b5-1ec20e54365a","title":"Episode 25: How Do You Get Up to Speed When Starting in a New Codebase?","url":"https://acima-development.fireside.fm/25","content_text":"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.\n\nTranscript:\n\nTAD: 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.\n\nDAVID BRADY: Howdy, howdy.\n\nTAD: David Solano. \n\nDAVID SOLANO: Hello.\n\nTAD: Eddy Lopez. \n\nEDDY: Howdy.\n\nTAD: Matt Hardy. \n\nMATT: Hello there.\n\nTAD: Mike Challis. \n\nMIKE: Hello.\n\nTAD: And Sergio Peralta, who's also new. \n\nSERGIO: Yeah, I am new. Hi, guys. \n\nTAD: 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?\n\nMATT: I'm going to say the gem file. \n\nDAVID SOLANO: Me too.\n\nTAD: Cool. What does the gem file teach you?\n\nMATT: 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? \n\nTAD: Right. I think it's interesting. You can often see, like, Ruby version; sometimes people will put it in a gem file, internal gems.\n\nDAVID 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. \n\nTAD: [laughs]\n\nDAVID 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. \n\nAfter 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?\n\nTAD: Sure. Yeah, [inaudible 02:57], right?\n\nDAVID BRADY: Mm-hmm.\n\nDAVID 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. \n\nTAD: [laughs] Yeah.\n\nDAVID 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?\n\nTAD: 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.\n\nMATT: 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. \n\nAnd 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.\n\nTAD: 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?\n\nMATT: 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.\n\nDAVID 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. \n\nBut 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. \n\nAnd 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. \n\nAnd 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.\n\nTAD: 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.\" \n\nAnd 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?\n\nDAVID 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.\n\nBut 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. \n\nAnd 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.\n\nTAD: To further your point, Dave, you'll know which flags they use when they run their tests even? \n\nDAVID BRADY: Yes, right?\n\nMATT: 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. \n\nIf 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.\n\nDAVID 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. \n\nDevelopers 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. \n\nYou 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.\n\nBut 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. \n\nWe'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. \n\nTAD: 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?\n\nEDDY: 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. \n\nIn 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. \n\nAnd 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. \n\nSo 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?\n\nTAD: Nice.\n\nEDDY: 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.\n\nDAVID 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. \n\nAnd 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.\n\nDAVID 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.\n\nTAD: 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?\n\nSERGIO: 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. \n\nSo 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. \n\nIf 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.\n\nTAD: 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?\n\nEDDY: 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.\n\nDAVID 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. \n\nYeah, 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.\n\nDAVID 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...\n\nI 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.\n\n[crosstalk 19:58] \n\nTAD: It seems like pure programming but just with a bot instead of a person, right? \n\nDAVID BRADY: Yeah, yeah.\n\nEDDY: 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.\n\nDAVID 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. \n\nAnd 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.\" \n\nAnd 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. \n\nTAD: 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.\n\nDAVID 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.\n\nEDDY: Not to mention that ChatGPT is almost always available for you to pair versus asking someone else on the team who might be busy.\n\nTAD: 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?\n\nDAVID BRADY: I think it's inevitable, yeah. \n\nMATT: Yeah, I think -- \n\nDAVID 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. \n\nThe 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.\n\nTAD: 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. \n\nDAVID 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.\n\nTAD: 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?\n\nDAVID 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. \n\nWhere 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. \n\nBut 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. \n\nSo 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. \n\nAnd 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. \n\nEDDY: 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. \n\nI'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?\n\nTAD: I think it's -- \n\nDAVID 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. \n\nIt 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. \n\nLike, 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. \n\nAnd 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.\n\nEDDY: 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.\n\nDAVID 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.\n\nDAVID 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.\n\nDAVID 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?\n\nTAD: Yeah, I think that's great.\n\nDAVID 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. \n\nThere'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. \n\nBut 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.\n\nTAD: Or Stack Overflow, right? That's --\n\nDAVID BRADY: Yeah, Stack Overflow. \n\nTAD: [inaudible 32:48] Stack Overflow exists.\n\nDAVID 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. \n\nAnd 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. \n\nAnd 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. \n\nTad, 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. \n\nThere'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. \n\nAnd 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. \n\nAnd 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.\n\nTAD: 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? \n\nDAVID BRADY: No.\n\nTAD: 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?\n\nDAVID 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. \n\nThere'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. \n\nI 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.\n\nTAD: 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? \n\nDAVID BRADY: Right on.","content_html":"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.
\n\nTranscript:
\n\nTAD: 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.
\n\nDAVID BRADY: Howdy, howdy.
\n\nTAD: David Solano.
\n\nDAVID SOLANO: Hello.
\n\nTAD: Eddy Lopez.
\n\nEDDY: Howdy.
\n\nTAD: Matt Hardy.
\n\nMATT: Hello there.
\n\nTAD: Mike Challis.
\n\nMIKE: Hello.
\n\nTAD: And Sergio Peralta, who's also new.
\n\nSERGIO: Yeah, I am new. Hi, guys.
\n\nTAD: 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?
\n\nMATT: I'm going to say the gem file.
\n\nDAVID SOLANO: Me too.
\n\nTAD: Cool. What does the gem file teach you?
\n\nMATT: 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?
\n\nTAD: Right. I think it's interesting. You can often see, like, Ruby version; sometimes people will put it in a gem file, internal gems.
\n\nDAVID 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.
\n\nTAD: [laughs]
\n\nDAVID 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.
\n\nAfter 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?
\n\nTAD: Sure. Yeah, [inaudible 02:57], right?
\n\nDAVID BRADY: Mm-hmm.
\n\nDAVID 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.
\n\nTAD: [laughs] Yeah.
\n\nDAVID 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?
\n\nTAD: 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.
\n\nMATT: 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.
\n\nAnd 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.
\n\nTAD: 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?
\n\nMATT: 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.
\n\nDAVID 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.
\n\nBut 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nTAD: 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."
\n\nAnd 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?
\n\nDAVID 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.
\n\nBut 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.
\n\nAnd 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.
\n\nTAD: To further your point, Dave, you'll know which flags they use when they run their tests even?
\n\nDAVID BRADY: Yes, right?
\n\nMATT: 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.
\n\nIf 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.
\n\nDAVID 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.
\n\nDevelopers 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.
\n\nYou 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.
\n\nBut 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.
\n\nWe'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.
\n\nTAD: 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?
\n\nEDDY: 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.
\n\nIn 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.
\n\nAnd 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.
\n\nSo 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?
\n\nTAD: Nice.
\n\nEDDY: 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.
\n\nDAVID 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.
\n\nAnd 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.
\n\nDAVID 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.
\n\nTAD: 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?
\n\nSERGIO: 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.
\n\nSo 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.
\n\nIf 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.
\n\nTAD: 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?
\n\nEDDY: 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.
\n\nDAVID 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.
\n\nYeah, 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.
\n\nDAVID 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...
\n\nI 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.
\n\n[crosstalk 19:58]
\n\nTAD: It seems like pure programming but just with a bot instead of a person, right?
\n\nDAVID BRADY: Yeah, yeah.
\n\nEDDY: 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.
\n\nDAVID 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.
\n\nAnd 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."
\n\nAnd 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.
\n\nTAD: 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.
\n\nDAVID 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.
\n\nEDDY: Not to mention that ChatGPT is almost always available for you to pair versus asking someone else on the team who might be busy.
\n\nTAD: 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?
\n\nDAVID BRADY: I think it's inevitable, yeah.
\n\nMATT: Yeah, I think --
\n\nDAVID 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.
\n\nThe 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.
\n\nTAD: 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.
\n\nDAVID 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.
\n\nTAD: 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?
\n\nDAVID 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.
\n\nWhere 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.
\n\nBut 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.
\n\nSo 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.
\n\nAnd 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.
\n\nEDDY: 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.
\n\nI'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?
\n\nTAD: I think it's --
\n\nDAVID 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.
\n\nIt 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.
\n\nLike, 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.
\n\nAnd 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.
\n\nEDDY: 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.
\n\nDAVID 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.
\n\nDAVID 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.
\n\nDAVID 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?
\n\nTAD: Yeah, I think that's great.
\n\nDAVID 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.
\n\nThere'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.
\n\nBut 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.
\n\nTAD: Or Stack Overflow, right? That's --
\n\nDAVID BRADY: Yeah, Stack Overflow.
\n\nTAD: [inaudible 32:48] Stack Overflow exists.
\n\nDAVID 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nTad, 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.
\n\nThere'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.
\n\nAnd 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.
\n\nAnd 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.
\n\nTAD: 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?
\n\nDAVID BRADY: No.
\n\nTAD: 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?
\n\nDAVID 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.
\n\nThere'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.
\n\nI 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.
\n\nTAD: 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?
\n\nDAVID BRADY: Right on.
","summary":"","date_published":"2023-08-16T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/6681eb68-a182-4c19-99b5-1ec20e54365a.mp3","mime_type":"audio/mpeg","size_in_bytes":38214385,"duration_in_seconds":2314}]},{"id":"a0dc89f3-8e92-4d9b-8575-533de652838d","title":"Episode 24: What Project Did You Work on that Really Propelled Your Abilities to the Next Level?","url":"https://acima-development.fireside.fm/24","content_text":"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.\n\nKyle'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.\n\nTranscript:\n\nMIKE: 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?\n\nI'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. \n\nFor 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. \n\nI'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. \n\nWell, 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. \n\nAnd 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. \n\nShortly 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. \n\nSo, 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. \n\nSo, 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. \n\nAnother 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] \n\nIf 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. \n\nThose 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?\n\nMATT: 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. \n\nAnd 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. \n\nSo, 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. \n\nAnd 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. \n\nAnd 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.\n\nMIKE: [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?\n\nMATT: 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. \n\nAnd, 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.\n\nMIKE: We're talking about lessons, not about pointing fingers. You know --\n\nMATT: 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.\n\nMIKE: 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?\n\nMATT: 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.\n\nTAD: 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?\n\nMIKE: 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. \n\nAnd 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. \n\nAnd 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. \n\nThe 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. \n\nThere'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.\n\nMATT: 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. \n\nI 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.\n\nTAD: 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? \n\nMATT: Right.\n\nTAD: You're, like, we needed to scale, and we didn't know how, and we got crushed.\n\nMATT: 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?\n\nMIKE: 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. \n\nFurther, 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.\n\nTAD: 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. \n\nAnd 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.\n\nMIKE: 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. \n\nAnd 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.\n\nMATT: 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.\n\nTAD: 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.\" \n\nHe 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.\"\n\nAnd 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. \n\nAnd 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.\" \n\nAnd 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.\" \n\nI'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.\" \n\nBut 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.\n\nMIKE: 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. \n\nKYLE: 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. \n\nAnd 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. \n\nAnd 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.\n\nBut 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. \n\nWe 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. \n\nAnd 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. \n\nPrometheus 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. \n\nAnd 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. \n\nAnd, 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. \n\nThere'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]\n\nMIKE: 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? \n\nLike, 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. \n\nAnd 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. \n\nAlso, 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. \n\nYou 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.\n\nTAD: 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. \n\nAnd 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. \n\nAnd 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. \n\nMIKE: That's interesting. [laughs] On your own, you just played games. [laughs]\n\nTAD: 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.\n\nMIKE: 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. \n\nWe 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] \n\nAnd 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. \n\nHe 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?\n\nMATT: 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.\n\nMIKE: 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. \n\nBut 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.\n\nKYLE: 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. \n\nThere'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. \n\nEven 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.\n\nYou 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?\n\nMIKE: 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. \n\nThere'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. \n\nTo 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. \n\nAnd 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. \n\nAnd 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.\n\nIf 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. \n\nYou 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. \n\nI 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.\n\nMATT: 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.\n\nMIKE: Great. Thank you. Another great discussion. I look forward to talking with you all next time.","content_html":"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.
\n\nKyle'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.
\n\nTranscript:
\n\nMIKE: 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?
\n\nI'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.
\n\nFor 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.
\n\nI'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.
\n\nWell, 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.
\n\nAnd 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.
\n\nShortly 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.
\n\nSo, 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.
\n\nSo, 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.
\n\nAnother 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]
\n\nIf 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.
\n\nThose 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?
\n\nMATT: 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.
\n\nAnd 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.
\n\nSo, 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nMIKE: [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?
\n\nMATT: 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.
\n\nAnd, 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.
\n\nMIKE: We're talking about lessons, not about pointing fingers. You know --
\n\nMATT: 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.
\n\nMIKE: 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?
\n\nMATT: 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.
\n\nTAD: 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?
\n\nMIKE: 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nThe 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.
\n\nThere'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.
\n\nMATT: 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.
\n\nI 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.
\n\nTAD: 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?
\n\nMATT: Right.
\n\nTAD: You're, like, we needed to scale, and we didn't know how, and we got crushed.
\n\nMATT: 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?
\n\nMIKE: 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.
\n\nFurther, 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.
\n\nTAD: 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.
\n\nAnd 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.
\n\nMIKE: 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.
\n\nAnd 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.
\n\nMATT: 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.
\n\nTAD: 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."
\n\nHe 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."
\n\nAnd 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.
\n\nAnd 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."
\n\nAnd 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."
\n\nI'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."
\n\nBut 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.
\n\nMIKE: 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.
\n\nKYLE: 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nBut 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.
\n\nWe 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.
\n\nAnd 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.
\n\nPrometheus 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.
\n\nAnd 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.
\n\nAnd, 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.
\n\nThere'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]
\n\nMIKE: 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?
\n\nLike, 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.
\n\nAnd 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.
\n\nAlso, 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.
\n\nYou 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.
\n\nTAD: 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nMIKE: That's interesting. [laughs] On your own, you just played games. [laughs]
\n\nTAD: 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.
\n\nMIKE: 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.
\n\nWe 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]
\n\nAnd 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.
\n\nHe 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?
\n\nMATT: 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.
\n\nMIKE: 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.
\n\nBut 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.
\n\nKYLE: 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.
\n\nThere'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.
\n\nEven 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.
\n\nYou 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?
\n\nMIKE: 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.
\n\nThere'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.
\n\nTo 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nIf 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.
\n\nYou 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.
\n\nI 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.
\n\nMATT: 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.
\n\nMIKE: Great. Thank you. Another great discussion. I look forward to talking with you all next time.
","summary":"","date_published":"2023-08-02T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/a0dc89f3-8e92-4d9b-8575-533de652838d.mp3","mime_type":"audio/mpeg","size_in_bytes":42782570,"duration_in_seconds":2292}]},{"id":"de8924eb-7b08-47d7-921a-c9613e4edb90","title":"Episode 23: Javascript vs Server-Side Rendering","url":"https://acima-development.fireside.fm/23","content_text":"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.\n\nAdditionally, 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.\n\nTranscript:\n\nMIKE: 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.\n\nTo 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. \n\nSo 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. \n\nAnd 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.\n\nThey 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. \n\nBut 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. \n\nAnd 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. \n\nAnd 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. \n\nWe'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. \n\nI 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. \n\nAnd 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?\n\nNATHAN: 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.\n\nMIKE: 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. \n\nSo 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.\n\nIn 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.\n\nNATHAN: 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. \n\nAnd 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. \n\nSo 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? \n\nMIKE: 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. \n\nAnd 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.\n\nMATT: Just those old days of building your own libraries for Ajax requests. It's sure come a long way since then. \n\nMIKE: Yeah, it has.\n\nNATHAN: 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. \n\nOn 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. \n\nAnd 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. \n\nSo 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. \n\nMATT: Yeah, it may be worth noting as well that Turbo uses WebSockets, so event-driven.\n\nNATHAN: 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.\n\nMIKE: 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.\n\nMATT: Yeah, you can go 100% the WebSocket route, but it is not required with Turbo.\n\nNATHAN: 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. \n\nAnd 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. \n\nReact 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. \n\nIn 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.\n\nMATT: Being able to debug in your markup is really powerful. \n\nNATHAN: 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.\n\nMIKE: 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.\n\nNATHAN: 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. \n\nThe 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. \n\nAnd 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. \n\nMIKE: To take that a step further, most people don't write JavaScript anymore, right? They write TypeScript.\n\nNATHAN: 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.\n\nMATT: 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.\n\nNATHAN: 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. \n\nVite 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. \n\nSo, 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.\n\nBut 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. \n\nIt'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.\n\nMATT: 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. \n\nAnd 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.\n\nNATHAN: 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.\n\nMIKE: 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] \n\nNATHAN: [laughs]\n\nMIKE: 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.\n\nNATHAN: 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. \n\nI 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.\n\nMATT: 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.\n\nMIKE: 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.\n\nMATT: Yeah, you can find them in almost every language now.\n\nNATHAN: 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. \n\nA 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.\n\nMATT: I find myself doing the very same thing. \n\nMIKE: 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.\n\nNATHAN: 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.\n\nWhat 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. \n\nThere'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. \n\nAnd 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. \n\nMATT: 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. \n\nI 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? \n\nRAMSES: 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. \n\nMATT: Yeah, sometimes picking is the hardest part.\n\nMIKE: 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. \n\nOne 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.\n\nThen 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. \n\nAnd 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. \n\nBut 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.\n\nMATT: 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.\n\nMIKE: You don't write WSDLs for fun? \n\nMATT: Yeah [vocalization]\n\nMIKE: [laughs]\n\nMATT: I [laughs] really do. I have nightmares of having to write SOAP API and WSDLs.\n\nNATHAN: 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. \n\nAnd, 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. \n\nAnd 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. \n\nAnd, 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. \n\nBut 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. \n\nAnd 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. \n\nBut 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. \n\nI'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. \n\nAnd 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. \n\nI 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.\n\nMIKE: 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. \n\nIf 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. \n\nBut 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. \n\nOne 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.\n\nNATHAN: 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. \n\nAnd 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. \n\nAnd 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.\n\nSo, 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. \n\nI'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.\n\nMIKE: 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?\n\nNATHAN: 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. \n\nA 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. \n\nMIKE: 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.\n\nMATT: 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.\n\nNATHAN: 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. \n\nThere 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.\n\nMIKE: 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. \n\nAnd 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.\n\nNATHAN: Agreed. \n\nMIKE: 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.\n\nWe'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.\n\nAnd thank you, and we'll talk to you. You'll hear from us anyway next time.","content_html":"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.
\n\nAdditionally, 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.
\n\nTranscript:
\n\nMIKE: 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.
\n\nTo 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.
\n\nSo 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.
\n\nAnd 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.
\n\nThey 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.
\n\nBut 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nWe'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.
\n\nI 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.
\n\nAnd 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?
\n\nNATHAN: 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.
\n\nMIKE: 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.
\n\nSo 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.
\n\nIn 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.
\n\nNATHAN: 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.
\n\nAnd 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.
\n\nSo 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?
\n\nMIKE: 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.
\n\nAnd 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.
\n\nMATT: Just those old days of building your own libraries for Ajax requests. It's sure come a long way since then.
\n\nMIKE: Yeah, it has.
\n\nNATHAN: 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.
\n\nOn 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.
\n\nAnd 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.
\n\nSo 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.
\n\nMATT: Yeah, it may be worth noting as well that Turbo uses WebSockets, so event-driven.
\n\nNATHAN: 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.
\n\nMIKE: 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.
\n\nMATT: Yeah, you can go 100% the WebSocket route, but it is not required with Turbo.
\n\nNATHAN: 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.
\n\nAnd 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.
\n\nReact 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.
\n\nIn 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.
\n\nMATT: Being able to debug in your markup is really powerful.
\n\nNATHAN: 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.
\n\nMIKE: 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.
\n\nNATHAN: 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.
\n\nThe 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.
\n\nAnd 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.
\n\nMIKE: To take that a step further, most people don't write JavaScript anymore, right? They write TypeScript.
\n\nNATHAN: 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.
\n\nMATT: 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.
\n\nNATHAN: 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.
\n\nVite 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.
\n\nSo, 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.
\n\nBut 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.
\n\nIt'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.
\n\nMATT: 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.
\n\nAnd 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.
\n\nNATHAN: 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.
\n\nMIKE: 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]
\n\nNATHAN: [laughs]
\n\nMIKE: 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.
\n\nNATHAN: 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.
\n\nI 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.
\n\nMATT: 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.
\n\nMIKE: 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.
\n\nMATT: Yeah, you can find them in almost every language now.
\n\nNATHAN: 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.
\n\nA 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.
\n\nMATT: I find myself doing the very same thing.
\n\nMIKE: 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.
\n\nNATHAN: 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.
\n\nWhat 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.
\n\nThere'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.
\n\nAnd 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.
\n\nMATT: 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.
\n\nI 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?
\n\nRAMSES: 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.
\n\nMATT: Yeah, sometimes picking is the hardest part.
\n\nMIKE: 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.
\n\nOne 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
\n\nThen 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.
\n\nAnd 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.
\n\nBut 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.
\n\nMATT: 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.
\n\nMIKE: You don't write WSDLs for fun?
\n\nMATT: Yeah [vocalization]
\n\nMIKE: [laughs]
\n\nMATT: I [laughs] really do. I have nightmares of having to write SOAP API and WSDLs.
\n\nNATHAN: 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.
\n\nAnd, 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.
\n\nAnd 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.
\n\nAnd, 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.
\n\nBut 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.
\n\nAnd 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.
\n\nBut 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.
\n\nI'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.
\n\nAnd 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.
\n\nI 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.
\n\nMIKE: 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.
\n\nIf 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.
\n\nBut 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.
\n\nOne 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.
\n\nNATHAN: 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nSo, 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.
\n\nI'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.
\n\nMIKE: 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?
\n\nNATHAN: 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.
\n\nA 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.
\n\nMIKE: 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.
\n\nMATT: 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.
\n\nNATHAN: 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.
\n\nThere 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.
\n\nMIKE: 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.
\n\nAnd 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.
\n\nNATHAN: Agreed.
\n\nMIKE: 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.
\n\nWe'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.
\n\nAnd thank you, and we'll talk to you. You'll hear from us anyway next time.
","summary":"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.\r\n\r\nAdditionally, 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.","date_published":"2023-07-19T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/de8924eb-7b08-47d7-921a-c9613e4edb90.mp3","mime_type":"audio/mpeg","size_in_bytes":45541490,"duration_in_seconds":2442}]},{"id":"b06e1cfa-8a9c-47e5-8c03-d93628bb6f92","title":"Episode 22: What Challenges Have You Faced on the Journey to Development Success?","url":"https://acima-development.fireside.fm/22","content_text":"Today, we talk about challenges that we went through on our path to building a software career. \n\nTranscript:\n\nMIKE: 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. \n\nI'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.\n\nDuring 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. \n\nIt 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. \n\nI 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. \n\nEventually, 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. \n\nAnd 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?\n\nKYLE: 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. \n\nI 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. \n\nSo 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. \n\nAnd 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.\n\nMIKE: And it's interesting. You weren't even aware that they existed, right? [laughs]\n\nKYLE: 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.\n\nMIKE: 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?\n\nKYLE: 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? \n\nAnd 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. \n\nAnd 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.\n\nMIKE: 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.\n\nKYLE: 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. \n\nAnd 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. \n\nMIKE: 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. \n\nKYLE: 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.\n\nMIKE: 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. \n\nTad, I'm interested in what thoughts you have about the challenges you've gone through in your career.\n\nTAD: 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. \n\nI 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.\n\nAnd 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. \n\nAnd 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. \n\nAnd 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] \n\nYou 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. \n\nLike, 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. \n\nAnd 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. \n\nBut, 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. \n\nAs 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. \n\nAnd 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. \n\nAnd 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. \n\nBut 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.\n\nMIKE: 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? \n\nTAD: Yeah.\n\nMIKE: Dealing with people who are unkind can be really crushing. But you found people who saw your worth. It made a big difference. \n\nThere'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. \n\nYou 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. \n\nThe 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.\n\nTAD: 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.\n\nKYLE: 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.\n\nBut 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. \n\nI'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. \n\nAnd 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.\n\nTAD: 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.\n\nKYLE: 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.\"\n\nTAD: Right. \n\nMIKE: 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.\n\nAnd, 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. \n\nCommunication 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.\n\nKYLE: 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.\n\nMIKE: 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. \n\nWe'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.\n\nTAD: 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.\n\nMIKE: 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] \n\nAnd 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. \n\nAnd, 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.\n\nTAD: 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?\n\nMIKE: 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. \n\nHe'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. \n\nAnd 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.\n\nIf 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. \n\nWhat'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? \n\nGo 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.\n\nKYLE: 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.\n\nIt'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?\n\nIt 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. \n\nBut 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. \n\nSome 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. \n\nAnd 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.\n\nTAD: 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. \n\nSo, 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.\" \n\nAnd 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. \n\nAnd 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.\n\nAnd 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. \n\nAnd 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. \n\nAnd 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.\n\nMIKE: 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. \n\nTAD: Right.\n\nMIKE: 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. \n\nKYLE: 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. \n\nAnd 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. \n\nAnd 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. \n\nAnd 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.\n\nTAD: 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.\n\nKYLE: 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. \n\nIt'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?\n\nTAD: 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?\n\nMIKE: 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.\n\nWhat'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. \n\nTAD: 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?\n\nKYLE: They're high-paying right now, right? Because there are so few of them.\n\nTAD: Yeah.\n\nMIKE: 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.\n\nTalking 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.\n\nKYLE: 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.\n\nMIKE: 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.\n\nEDDY: 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?\n\nI 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.\n\nMIKE: You say you tried it. [laughs] And if you hadn't tried it, you wouldn't have known. \n\nEDDY: Exactly. \n\nMIKE: 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.\n\nEDDY: 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.\n\nMIKE: Definitely. Find people who are good mentors [chuckles], and it will make a huge difference.\n\nKYLE: 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.\n\nEDDY: 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.\n\nMIKE: 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.\n\nEDDY: 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.\n\nMIKE: 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.\n\nKYLE: 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.\n\nEDDY: 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 --\n\nKYLE: 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. \n\nEDDY: That's awesome. \n\nMIKE: 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. \n\nIt's been great talking today. We look forward to next time. And I'll see you next time on the Acima Development Podcast.","content_html":"Today, we talk about challenges that we went through on our path to building a software career.
\n\nTranscript:
\n\nMIKE: 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.
\n\nI'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.
\n\nDuring 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.
\n\nIt 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.
\n\nI 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.
\n\nEventually, 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.
\n\nAnd 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?
\n\nKYLE: 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.
\n\nI 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.
\n\nSo 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.
\n\nAnd 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.
\n\nMIKE: And it's interesting. You weren't even aware that they existed, right? [laughs]
\n\nKYLE: 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.
\n\nMIKE: 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?
\n\nKYLE: 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?
\n\nAnd 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.
\n\nAnd 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.
\n\nMIKE: 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.
\n\nKYLE: 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.
\n\nAnd 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.
\n\nMIKE: 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.
\n\nKYLE: 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.
\n\nMIKE: 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.
\n\nTad, I'm interested in what thoughts you have about the challenges you've gone through in your career.
\n\nTAD: 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.
\n\nI 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nAnd 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]
\n\nYou 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.
\n\nLike, 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.
\n\nAnd 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.
\n\nBut, 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.
\n\nAs 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nBut 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.
\n\nMIKE: 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?
\n\nTAD: Yeah.
\n\nMIKE: Dealing with people who are unkind can be really crushing. But you found people who saw your worth. It made a big difference.
\n\nThere'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.
\n\nYou 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.
\n\nThe 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.
\n\nTAD: 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.
\n\nKYLE: 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.
\n\nBut 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.
\n\nI'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.
\n\nAnd 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.
\n\nTAD: 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.
\n\nKYLE: 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."
\n\nTAD: Right.
\n\nMIKE: 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.
\n\nAnd, 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.
\n\nCommunication 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.
\n\nKYLE: 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.
\n\nMIKE: 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.
\n\nWe'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.
\n\nTAD: 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.
\n\nMIKE: 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]
\n\nAnd 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.
\n\nAnd, 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.
\n\nTAD: 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?
\n\nMIKE: 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.
\n\nHe'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.
\n\nAnd 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.
\n\nIf 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.
\n\nWhat'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?
\n\nGo 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.
\n\nKYLE: 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.
\n\nIt'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?
\n\nIt 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.
\n\nBut 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.
\n\nSome 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.
\n\nAnd 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.
\n\nTAD: 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.
\n\nSo, 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."
\n\nAnd 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nMIKE: 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.
\n\nTAD: Right.
\n\nMIKE: 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.
\n\nKYLE: 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nTAD: 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.
\n\nKYLE: 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.
\n\nIt'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?
\n\nTAD: 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?
\n\nMIKE: 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.
\n\nWhat'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.
\n\nTAD: 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?
\n\nKYLE: They're high-paying right now, right? Because there are so few of them.
\n\nTAD: Yeah.
\n\nMIKE: 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.
\n\nTalking 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.
\n\nKYLE: 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.
\n\nMIKE: 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.
\n\nEDDY: 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?
\n\nI 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.
\n\nMIKE: You say you tried it. [laughs] And if you hadn't tried it, you wouldn't have known.
\n\nEDDY: Exactly.
\n\nMIKE: 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.
\n\nEDDY: 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.
\n\nMIKE: Definitely. Find people who are good mentors [chuckles], and it will make a huge difference.
\n\nKYLE: 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.
\n\nEDDY: 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.
\n\nMIKE: 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.
\n\nEDDY: 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.
\n\nMIKE: 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.
\n\nKYLE: 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.
\n\nEDDY: 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 --
\n\nKYLE: 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.
\n\nEDDY: That's awesome.
\n\nMIKE: 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.
\n\nIt's been great talking today. We look forward to next time. And I'll see you next time on the Acima Development Podcast.
","summary":"","date_published":"2023-07-05T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/b06e1cfa-8a9c-47e5-8c03-d93628bb6f92.mp3","mime_type":"audio/mpeg","size_in_bytes":50537580,"duration_in_seconds":2661}]},{"id":"ef0d9886-f668-46c3-b6cb-7525084b7c23","title":"Episode 21: Frustration Management","url":"https://acima-development.fireside.fm/21","content_text":"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?\n\nTranscript:\n\nMIKE: 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. \n\nWe 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. \n\nI 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]\n\nFirst 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. \n\nSecondly, 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.\n\nAnd 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. \n\nAnd, 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. \n\nAlso, 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. \n\nAnd 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. \n\nEventually, 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.\n\nFinally, 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. \n\nI 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. \n\nSo 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. \n\nFirst, 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.\n\nThe 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. \n\nAnd 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. \n\nI'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?\n\nMATT: 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.\n\nMIKE: But it's sometimes hard to step away, isn't it?\n\nMATT: Oh, absolutely. Because you don't want to feel defeated.\n\nKYLE: 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. \n\nEven 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.\n\nEDDY: 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.\n\nMATT: 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.\n\nMIKE: 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?\n\nMATT: 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.\n\nMIKE: 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?\n\nMATT: 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.\n\nDAVID: 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. \n\nAnd 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.\n\nMIKE: 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.\n\nMATT: 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. \n\nAnd 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.\n\nKYLE: 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?\" \n\nAnd 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.\n\nMIKE: 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. \n\nWhat other things do you all try to deal with your frustration?\n\nKYLE: 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. \n\nDAVID: 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.\"\n\nAnd 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.\n\nMIKE: 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. \n\nDAVID: 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?\"\n\nMIKE: 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.\n\nOne 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. \n\nWell, 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. \n\nWhen 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?\n\nDAVID: When I remember to do it.\n\nKYLE: 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.\n\nMIKE: What tool do you use to write out that mind map?\n\nKYLE: Pen and paper, to be honest with you.\n\nDAVID: 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. \n\nWhen 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.\n\nKYLE: 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.\n\nMATT: 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.\n\nMIKE: So maybe changing your environment from the computer you're working [laughs] on to --\n\nDAVID: It can be.\n\nMIKE: Doing something very tactile follows right along the lines of what we've been talking about?\n\nMATT: I think so.\n\nDAVID: 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. \n\nNow, 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. \n\nAnd 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.\"\n\nThat'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.\n\nMATT: 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]\n\nDAVID: 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. \n\nAll 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. \n\nOh, 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? \n\nFinding 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. \n\nI 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. \n\nMATT: Yeah, freeform, right?\n\nDAVID: Mm-hmm.\n\nMATT: 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.\n\nMIKE: 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. \n\nAnd 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.\n\nEventually, 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. \n\nAnd, 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.\n\nMATT: And I love that.\n\nDAVID: 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.\n\nMIKE: [laughs]\n\nMATT: I have spent so much time playing with those things. \n\nMIKE: [laughs]\n\nMATT: 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.\n\nDAVID: Resignation to your fate. It's a little fatalist, isn't it? But, yeah, accepting what we have in front of us.\n\nMIKE: 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? \n\nSo 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. \n\nLike, 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.\n\nMATT: 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.\n\nDAVID: 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? \n\nThere'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. \n\nBut, 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. \n\nAnd 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. \n\nThe 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.\"\n\nMIKE: 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.\n\nSo 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. \n\nMATT: 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.\n\nDAVID: 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.\n\nMATT: 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.\n\nMIKE: 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.\n\nKYLE: 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. \n\nAnd 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. \n\nThe 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. \n\nAnd 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.\n\nMIKE: Oh, that's great.\n\nDAVID: 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. \n\nLooking 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.\n\nMIKE: 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. \n\nBut 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. \n\nOr 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.\n\nDAVID: 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.\n\nMATT: I love that. \n\nMIKE: 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.","content_html":"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?
\n\nTranscript:
\n\nMIKE: 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.
\n\nWe 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.
\n\nI 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]
\n\nFirst 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.
\n\nSecondly, 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.
\n\nAnd 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.
\n\nAnd, 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.
\n\nAlso, 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.
\n\nAnd 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.
\n\nEventually, 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.
\n\nFinally, 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.
\n\nI 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.
\n\nSo 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.
\n\nFirst, 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.
\n\nThe 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.
\n\nAnd 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.
\n\nI'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?
\n\nMATT: 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.
\n\nMIKE: But it's sometimes hard to step away, isn't it?
\n\nMATT: Oh, absolutely. Because you don't want to feel defeated.
\n\nKYLE: 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.
\n\nEven 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.
\n\nEDDY: 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.
\n\nMATT: 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.
\n\nMIKE: 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?
\n\nMATT: 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.
\n\nMIKE: 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?
\n\nMATT: 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.
\n\nDAVID: 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.
\n\nAnd 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.
\n\nMIKE: 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.
\n\nMATT: 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.
\n\nAnd 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.
\n\nKYLE: 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?"
\n\nAnd 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.
\n\nMIKE: 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.
\n\nWhat other things do you all try to deal with your frustration?
\n\nKYLE: 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.
\n\nDAVID: 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."
\n\nAnd 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.
\n\nMIKE: 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.
\n\nDAVID: 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?"
\n\nMIKE: 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.
\n\nOne 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.
\n\nWell, 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.
\n\nWhen 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?
\n\nDAVID: When I remember to do it.
\n\nKYLE: 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.
\n\nMIKE: What tool do you use to write out that mind map?
\n\nKYLE: Pen and paper, to be honest with you.
\n\nDAVID: 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.
\n\nWhen 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.
\n\nKYLE: 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.
\n\nMATT: 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.
\n\nMIKE: So maybe changing your environment from the computer you're working [laughs] on to --
\n\nDAVID: It can be.
\n\nMIKE: Doing something very tactile follows right along the lines of what we've been talking about?
\n\nMATT: I think so.
\n\nDAVID: 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.
\n\nNow, 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.
\n\nAnd 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."
\n\nThat'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.
\n\nMATT: 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]
\n\nDAVID: 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.
\n\nAll 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.
\n\nOh, 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?
\n\nFinding 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.
\n\nI 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.
\n\nMATT: Yeah, freeform, right?
\n\nDAVID: Mm-hmm.
\n\nMATT: 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.
\n\nMIKE: 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.
\n\nAnd 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.
\n\nEventually, 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.
\n\nAnd, 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.
\n\nMATT: And I love that.
\n\nDAVID: 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.
\n\nMIKE: [laughs]
\n\nMATT: I have spent so much time playing with those things.
\n\nMIKE: [laughs]
\n\nMATT: 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.
\n\nDAVID: Resignation to your fate. It's a little fatalist, isn't it? But, yeah, accepting what we have in front of us.
\n\nMIKE: 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?
\n\nSo 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.
\n\nLike, 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.
\n\nMATT: 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.
\n\nDAVID: 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?
\n\nThere'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.
\n\nBut, 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.
\n\nAnd 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.
\n\nThe 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."
\n\nMIKE: 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.
\n\nSo 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.
\n\nMATT: 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.
\n\nDAVID: 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.
\n\nMATT: 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.
\n\nMIKE: 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.
\n\nKYLE: 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.
\n\nAnd 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.
\n\nThe 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.
\n\nAnd 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.
\n\nMIKE: Oh, that's great.
\n\nDAVID: 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.
\n\nLooking 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.
\n\nMIKE: 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.
\n\nBut 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.
\n\nOr 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.
\n\nDAVID: 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.
\n\nMATT: I love that.
\n\nMIKE: 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.
","summary":"","date_published":"2023-06-21T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/ef0d9886-f668-46c3-b6cb-7525084b7c23.mp3","mime_type":"audio/mpeg","size_in_bytes":45706693,"duration_in_seconds":2372}]},{"id":"2b5488b7-5556-4f79-bf53-626950eabe89","title":"Episode 20: How Do We Effectively Work with Product People?","url":"https://acima-development.fireside.fm/20","content_text":"How do we work effectively with product people?\n\nTranscript:\n\nDAVID: 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. \n\nAnd 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?\n\nMIKE: 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. \n\nAnd 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] \n\nDAVID: And if you have any questions, read the document harder.\n\nMIKE: 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.\n\nJEFF: 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. \n\nSo, 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. \n\nAnd 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? \n\nMIKE: [laughs] Changing priorities? \n\nJEFF: [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? \n\nTYSON: 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. \n\nBut 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.\n\nMIKE: 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. \n\nThat 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. \n\nI 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.\n\nJEFF: 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. \n\nAnd 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. \n\nAnd 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.\" \n\nSo 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. \n\nOr 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.\" \n\nSo 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.\n\nDAVID: 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.\"\n\nMIKE: [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. \n\nI 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. \n\nProduct 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.\n\nJEFF: 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? \n\nThey'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. \n\nThe 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.\n\nMike, 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? \n\nAnd 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. \n\nI 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?\n\nMIKE: 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. \n\nYou 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. \n\nI 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. \n\nSo 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. \n\nThey 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.\n\nJEFF: 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]\n\nDAVID: 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?\n\nMIKE: I think that's right. Yeah.\n\nJEFF: 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? \n\nAnd 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. \n\nAnd 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. \n\nMIKE: And you talked a lot about priority, Jeff. Are you saying that we should always be working on the most important thing? [laughs]\n\nJEFF: Oh, if only that were true, Mike. [laughs] If only we could live in a world where that was the ability, right?\n\nMIKE: 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.\n\nJEFF: 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. \n\nAnd 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. \n\nAnd 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. \n\nLike, 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. \n\nMaking 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. \n\nAnd 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.\"\n\nMIKE: 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.\n\nJEFF: And, ideally, more than the minimum, right? Like -- [laughs]\n\nMIKE: Yes, exactly.\n\nJEFF: [laughs] Yes, yeah.\n\nDAVID: 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.\" \n\nAnd 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. \n\nAnd 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?\n\nJEFF: 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. \n\nOne 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. \n\nAnd 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. \n\nAnd 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. \n\nAnd 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? \n\nSo 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? \n\nAnd 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. \n\nAnd 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?\" \n\nAnd 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?\n\nAnd 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. \n\nAnd 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. \n\nAnd 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.\n\nDAVID: 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?\n\nJEFF: 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. \n\nGoing 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. \n\nMaybe 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.\n\nMIKE: 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?\n\nJEFF: 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? \n\nThey'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. \n\nAnd 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. \n\nAnd, 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. \n\nI 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. \n\nBecause 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. \n\nAnd 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.\n\nMIKE: 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]\n\nJEFF: Yeah, I think that's Reid Hoffman in LinkedIn, actually.\n\nMIKE: 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. \n\nAnd 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.\n\nAnd 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.\n\nJEFF: 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. \n\nI 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. \n\nThat 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. \n\nSo 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.\n\nDAVID: 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. \n\nThere'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.\" \n\nAnd 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. \n\nBut 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.\"\n\nJEFF: Yeah. Find your friends, your friendly customers. \n\nDAVID: [laughs] I like it.\n\nJEFF: Yeah.\n\nDAVID: It's like Airbnb but for beta testers. \n\nJEFF: [laughs]\n\nDAVID: 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.\n\nJEFF: 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.","content_html":"How do we work effectively with product people?
\n\nTranscript:
\n\nDAVID: 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.
\n\nAnd 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?
\n\nMIKE: 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.
\n\nAnd 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]
\n\nDAVID: And if you have any questions, read the document harder.
\n\nMIKE: 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.
\n\nJEFF: 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.
\n\nSo, 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.
\n\nAnd 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?
\n\nMIKE: [laughs] Changing priorities?
\n\nJEFF: [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?
\n\nTYSON: 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.
\n\nBut 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.
\n\nMIKE: 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.
\n\nThat 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.
\n\nI 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.
\n\nJEFF: 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.
\n\nAnd 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.
\n\nAnd 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."
\n\nSo 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.
\n\nOr 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."
\n\nSo 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.
\n\nDAVID: 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."
\n\nMIKE: [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.
\n\nI 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.
\n\nProduct 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.
\n\nJEFF: 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?
\n\nThey'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.
\n\nThe 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.
\n\nMike, 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?
\n\nAnd 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.
\n\nI 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?
\n\nMIKE: 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.
\n\nYou 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.
\n\nI 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.
\n\nSo 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.
\n\nThey 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.
\n\nJEFF: 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]
\n\nDAVID: 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?
\n\nMIKE: I think that's right. Yeah.
\n\nJEFF: 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?
\n\nAnd 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.
\n\nAnd 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.
\n\nMIKE: And you talked a lot about priority, Jeff. Are you saying that we should always be working on the most important thing? [laughs]
\n\nJEFF: Oh, if only that were true, Mike. [laughs] If only we could live in a world where that was the ability, right?
\n\nMIKE: 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.
\n\nJEFF: 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nLike, 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.
\n\nMaking 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.
\n\nAnd 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."
\n\nMIKE: 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.
\n\nJEFF: And, ideally, more than the minimum, right? Like -- [laughs]
\n\nMIKE: Yes, exactly.
\n\nJEFF: [laughs] Yes, yeah.
\n\nDAVID: 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."
\n\nAnd 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.
\n\nAnd 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?
\n\nJEFF: 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.
\n\nOne 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nAnd 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?
\n\nSo 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?
\n\nAnd 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.
\n\nAnd 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?"
\n\nAnd 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?
\n\nAnd 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nDAVID: 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?
\n\nJEFF: 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.
\n\nGoing 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.
\n\nMaybe 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.
\n\nMIKE: 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?
\n\nJEFF: 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?
\n\nThey'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.
\n\nAnd 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.
\n\nAnd, 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.
\n\nI 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.
\n\nBecause 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.
\n\nAnd 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.
\n\nMIKE: 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]
\n\nJEFF: Yeah, I think that's Reid Hoffman in LinkedIn, actually.
\n\nMIKE: 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.
\n\nAnd 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.
\n\nAnd 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.
\n\nJEFF: 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.
\n\nI 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.
\n\nThat 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.
\n\nSo 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.
\n\nDAVID: 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.
\n\nThere'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."
\n\nAnd 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.
\n\nBut 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."
\n\nJEFF: Yeah. Find your friends, your friendly customers.
\n\nDAVID: [laughs] I like it.
\n\nJEFF: Yeah.
\n\nDAVID: It's like Airbnb but for beta testers.
\n\nJEFF: [laughs]
\n\nDAVID: 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.
\n\nJEFF: 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.
","summary":"","date_published":"2023-06-14T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/2b5488b7-5556-4f79-bf53-626950eabe89.mp3","mime_type":"audio/mpeg","size_in_bytes":38103428,"duration_in_seconds":2295}]},{"id":"c39e19f1-4852-4875-953c-281bbb0686e5","title":"Episode 19: Why or Why Not Use Ruby?","url":"https://acima-development.fireside.fm/19","content_text":"Why do you use or why do you not use Ruby? \n\nTranscript:\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'll be hosting again this week. We have with us: Matt, Eddy, Kyle, and Ramses. And I hope to hear lots from them today.\n\nOur topic is going to be about the Ruby programming language and, specifically, why or why you might not want to use Ruby. This is maybe an interesting time to be talking about that. To give a little bit of history of the Ruby programming language, it's been around since 1995 or so. The creator goes by Matz. He's from Japan. And Ruby was very popular originally in Japan. It was one of the few languages that was documented well in Japanese and became extremely popular in Japan. It wasn't so very popular outside of Japan. I'll get to the moment that changed in a moment. \n\nRuby is an interesting language. It was inspired by a couple of languages, in particular, maybe most pointedly Perl and Smalltalk. Perl being a scripting language primarily used in shell scripts but also used a lot in the early web, and that is wildly flexible. If anybody has ever used Perl, reading Perl code is not for the faint of heart, but it's exceptionally powerful. And the people who use it tend to love it. And that was a lot of the inspiration for Ruby. So Ruby is very good at text parsing and doing the kinds of things you'd want to run scripts in the shell for. \n\nRuby was also heavily inspired by object-oriented languages, not necessarily the ones you might think of like Java, but Smalltalk, which is deeply, deeply object-oriented. Ruby is more object-oriented [laughs] than most object-oriented things in that it doesn't even have what you typically think of as primitives. You can call methods on integers. You can call methods on strings, their objects, just like anything else is an object. Really, anything is an object you can call. You can call methods on methods. [chuckles] It's deeply object-oriented. \n\nBut, on the flip side, it's also a deeply functional language in that every line is an expression. And it borrows a lot from functional languages as well. You don't ever see for loops in Ruby because idiomatic Ruby doesn't use that kind of approach, that kind of procedural approach. We use iteration and pass anonymous functions. It's got a special syntax for anonymous functions. So it's both deeply functional and deeply object-oriented and very good at text parsing. It's kind of an interesting language that allows you to do a lot of different things rather than necessarily having one way to do everything. \n\nSo that was around 1995, Ruby was created. About ten years later, in 2005, there was a big change in web development. There was a new framework that came out called Ruby on Rails. And, at the time, in web development (I was out there at the time. [chuckles]), web development was pretty clunky. There was a lot of boilerplate you had to set up. There was vast amounts of configuration files. \n\nIn the Java world, you'd set up a lot of configuration in, like, XML files before you could do anything. In the other interpreted languages like PHP, there was...really kind of fast and loose. People would do a lot of things without much protection, and there were a lot of security problems. By default, there were a lot of problems with unsanitized database access. And as a result, there were a lot of security breaches. So over on the scripting side, a lot of mess, over on the kind of big enterprise side, very difficult to use. \n\nAnd Ruby on Rails came out, kind of bridging the world between those two. And it was written in a scripting language, giving you the ease of use of a scripting language and the quickness. Using an interpreted language, you tend to go faster with some of the structure that you'd get in the big enterprisey sort of frameworks. And it followed a lot of best practices, such as convention over configuration, so a lot of that boilerplate just went away. And it had a huge impact. Most of the web frameworks today are heavily inspired by Rails, even if they don't exactly follow what Rails did at the time. \n\nNow, we are getting close to 20 years after that, and, you know, the world has moved on. Ruby on Rails is still around, but it's no longer the, you know, the top dog. I did a little research this morning, and JavaScript frameworks have absolutely taken over both on the client side and on the server side. We've got a world where there are client-side frameworks like React that dominate. And on the server side, JavaScript has largely stepped up as well. The most popular server-side frameworks are also written in JavaScript, well, with Node.js. \n\nPython, which is a similar kind of language to Ruby, is also quite popular on the server side, and PHP is still kicking around too. You got frameworks like Laravel. The world has changed. Ruby on Rails inspired a lot of other frameworks, but itself has continued to evolve or maybe hasn't evolved as much as some of the others, which brings us to today. Our question is, why might you or might you not use Ruby today? \n\nI want to share one anecdote of when I started using Rails myself. I started using Rails in 2005, the year it came out in beta. I was a Java developer at the time. And I first saw a presentation at a Java users group about Ruby on Rails. And I thought, ah-ah, I could do any of that in Java. [laughs] I honestly wasn't very impressed when I first heard about it. \n\nAnd then, I got pressured by the company I was working at at the time to switch over to a scripting language. They were pushing for PHP. And I'd seen the kind of lack of structure at the time, and I was very resistant to kind of going into that Wild West that was out there at the time. But I thought, you know what? I'm going to try this new framework I heard about, Ruby on Rails. I learned the language and wrote a prototype over a weekend. I kind of devoted my weekend to it, which says something. \n\nI was able to learn the framework and write a prototype of the app we were in over the weekend. We built out that app. And within a few months, we had rewritten our primary app in 1/10th the lines of code. There was literally 1/10th of the lines of code, even as we'd continued to add features. So the application could do more with a tenth lines of code as we had in Java because it's so much terser, and so much boilerplate was removed. I was impressed and kind of in love, [laughs] to be honest. It was so nice. \n\nAnd I've been doing mostly Rails in the years since, and I've seen some good and bad. I can speak a lot to that. As to whether I'd start a new project in Rails today, I very well might. It'd depend on what I would do. If I wanted to do a very traditional web application, maybe with fast prototyping, I'd almost certainly go with Rails. If I wanted to do something new that had a heavy front end, I might use Rails on the back end because it's still a fantastic back end. But it's a good chance I'd use a JavaScript front end and not use what Rails provides for the front end. \n\nSo if I were to share my opinion at a really high level of some things I might do, that's what I'd share. For anybody who's considering using Ruby, it's nice to know some of the history. I'm interested in what other people think about where Ruby and Rails are today (Rails has really dominated Ruby development since it came out) and whether or not you'd use it in a new project. Any thoughts, anyone?\n\nEDDY: I went ahead and looked up at the top languages or stack of 2022. This one's particularly the most popular programming, scripting, and markup languages found from Stack Overflow. And to kind of reinforce what you were saying, JavaScript came in at 65%.\n\nMIKE: Wow.\n\nEDDY: Which is a huge chunk, right? And then dwindling down from that, you have HTML, CSS, SQL, Python, TypeScript, and all the way in the bottom 6% of those were Ruby. So it kind of just gives me the impression, you know, that the hype train for Ruby has dwindled quite a bit over the years. And this is just judging off of the 2022 statistics. It begs the question, I guess, the context being why or why not Ruby? Well, I guess you could debate, based off this chart, that for job security potential or stuff like that, maybe Ruby was not a bad choice. But, again, I guess it just depends on what you're really aiming for.\n\nMIKE: Yeah, popularity is an interesting metric because if it's highly popular, there's probably a lot of jobs available. That doesn't necessarily mean those are the best-paying jobs. [laughs] Ruby developers have generally been relatively well paid, I think because they tend to be able to do more with less. You get a lot done; it makes you more valuable. But if you can't find any developers, well, then the company is not going to hire Ruby developers, and the market collapses, and then your value as a Ruby developer just disappears anyway. \n\nAnd there's a balance there, you know, 6% is still some. There's still a decent Ruby market out there. I mean, there's millions of websites out there. There are still large enterprise-y applications out there on Ruby on Rails, such as Shopify or GitHub. So, you know, there's still a vibrant Ruby ecosystem out there. But, to your point, 6% is not 60%. It's ten times smaller than the JavaScript world out there.\n\nEDDY: I'm hoping you can kind of elaborate on that a little bit on why it's gone down. Is it just because it's an old language and, you know, loud voices get more attention? You know, so, like, JavaScript will get more popularity since you have different frameworks. Python and TypeScript is the new thing. So I'm just curious on, like, what has attributed to the popularity? \n\nMATT: Like Mike, you and I have a very similar past in our career path and the languages that we've written in. Engineers, in general, have a tendency to jump on the hype trains, and we see things that are new and shiny. And because of the way our minds work, we're very curious, so we like to try new things. That's one of the reasons I think that JavaScript has taken so much traction because, you know, we spent all of these years only using it on the front end. And now that we can use it on the back end, it's like, oh my gosh, I can use everything in my application in one language.\n\nBut, you know, you'll find that front end and back end are very different, especially if you're using TypeScript and things like that. I personally am not ready for the JavaScript back-end world. I don't feel like there's enough structure yet. There are a few frameworks, things like NestJs, that help with that. But just coming from someone who was strictly JavaScript, it makes codebases extremely hard to work in when people don't establish consistent patterns. And that's something that I really love about Rails.\n\nYou know, there are definitely different ways of doing things with Rails. However, I think, for the most part, you're going to find a handful of patterns that get followed. I don't mean structurally as far as your code organization and things like that, but I mean the way your code is written. Ruby and Rails are very, very easy to follow and, like Mike said, very fast, and you can get a lot done with very little. And for that reason, I absolutely would use Rails for a back-end system today. \n\nAnd again, like Mike said, I would use a JavaScript framework for the front end because you can definitely get more done that way. But that's kind of my opinion, you know, coming from, historically, I started out writing conversion code, converting COBOL scripts to Perl and PHP. Talk about a nightmare. And you really quickly see how loose and fast PHP could be as well. But, again, it was loose, and back then, everything was procedural. I think we yearn for some structure and some organization in our code.\n\nMIKE: You know, you asked, Eddy, why people might be jumping on the new thing. I think that there is, you know, that hype that draws people. I think that's part of why people got on the Rails bandwagon in the first place as well, you know because you get some hype. People want to kind of be with the popular thing. And that's something hard to escape in human nature. But I think it's a bit more than that as well. \n\nBut somewhat related, if you're going to be writing a big JavaScript front end, you're spending day in day out in JavaScript, and then you have to write a different language on the back end. That's a little challenging that you have to think in two different ways. If you can write in the same language on the front and the back end, you avoid some of that. \n\nNow, I agree with Matt that they're pretty different between the front and the back end. And the back-end frameworks are not the same as the front-end frameworks. My experience thus far has been, yeah, they don't provide as much structure as I would like to have. And they tend to degrade into a mess without a lot of diligence and care from the developers, which sometimes is hard to maintain over a large group of developers in the company. There's some risk there. \n\nBut not having to change languages is a real bonus. And a lot of people have gone with that since JavaScript is the only option on the front end, and you're having to do JavaScript. People think, well, why not just also do JavaScript on the back end? You know, that's kind of a compelling argument, especially for a smaller application, a smaller back end. It's convincing to a lot of people.\n\nThere's also been the rise of Python, which is a similar language to Ruby. I'm not going to say they're identical. They have somewhat different takes on things, but they kind of fall into the same space. And Python has gotten very popular in the machine learning community, and where machine learning has been under such a big boom in the last few years. Now you have another language that a lot of people are using, and they don't necessarily want to learn something else to go into web development. \n\nSo, if you're already doing a lot of machine learning, you're likely going to be using Python and using a Python framework, again, just so you don't have to have two different things that you're doing. And I think that there's a lot of that as well; people just want to use the same tool that they've been using. So, if you're doing a lot of heavy JavaScript front end, it's likely you're going to do some on the back end. If you're going to be doing a lot of heavy machine learning-type work, you're probably going to use Python because that's what you're already familiar with. \n\nKyle, I'm interested from your perspective because you're over on the DevOps side, and you use a lot of different kinds of tools. And you've probably seen some of this, like, oh, I've gotten used to this tool, so I'm going to use more of it for this, or [chuckles] maybe you use so many tools that you're just, like, whatever fits in the moment.\n\nKYLE: We're kind of a bit of a mix. We kind of started out as the team was growing. And I came with more of a Python background. My manager came with a Ruby background. And then my team lead; he had more of a Bash background for all the scripting that, you know, that we're doing. And that has kind of mixed as we've done things. And so when I've written monitoring tools, that's been in Python just because it's been familiar to me. And when backup jobs and stuff like that have been written, those have been in Bash because that's what was familiar to my team lead. \n\nHowever, a lot of the other stuff was by our manager, and he was familiar with Ruby. So him and I go back and forth on that because there is a little bit of a competition between Python and Ruby, just at least in our team and, you know, which one's the better language. It's mostly a joke than anything anymore because, well, I do like Python. And I could do the same things that I do in Ruby in Python. \n\nI've actually adopted and started writing a lot of our Terraform generators, is what we call them, using ERB just because the ERB option with Ruby is just so friendly to me, at least, to where I can just put a little bit of Ruby code into the ERB to help with the generation. And when I'm saying generation, we're creating little Ruby apps to generate our HCL code for our Terraform. We have quite a bit of that just to get our automation done. And that's just been easier to do than deviating to Python or something, as well as when we have been working with services in the teams because we do have Ruby developers here.\n\nIt's really nice in our environment because we do work cross-services; not all the services are on the same version. And it's RVM, I believe, just feels so fleshed out to me. It's just really easy to set up those virtual environments. And maybe it's just the way I use it, but I haven't had that ease of a virtual environment. With Python, I tend to have issues here and there. Whereas RVM, I've hardly ever had any issues. So that's been really nice on the Ruby perspective.\n\nIt's also been good...we have a tool called [inaudible 16:45], which is an internal tool which does wrap a lot of the more common CLIs like the AWS CLI and stuff. A proof of concept for that just to see how it'd work out that was written in Ruby, just because it was easier and faster to get it done. To solidify it to where it was, you know, cross-platform that ended up being written in Golang. But to get a proof of concept going Ruby is just really easy to kind of get those things done. It's really easy to get scripting, really easy to get templates going.\n\nMIKE: And there are quite a few systems, DevOps tools that are written in Ruby. Are there not? You mentioned the ability to do ERB scripts with Terraform. And I haven't been much on the DevOps side for a long time. But I know that I will occasionally see this tool, like, oh, that's written in Ruby.\n\nKYLE: You know, you say that, and nothing's coming to mind right now. I'm only thinking of the Python ones, but yeah, there are definitely some Ruby ones. I just have to think a bit harder.\n\nMIKE: Yeah, I know that there are a few of them. And maybe they fall out of, again, with the hype cycle. Puppet is written in Chef or written in Ruby; it looks like. And it may have been slipping somewhat out of popularity. I'd have to go dig because I don't have a lot of expertise in there.\n\nKYLE: Yeah. Puppet they have competition from other ones like Ansible, and Ansible is what we use.\n\nMIKE: So that, yeah, that's interesting. So you end up using a lot of tools. You like Ruby, but there's other tools that can also get the job done. [laughs] And the best tool for the job, it sounds like.\n\nMATT: I firmly believe that teams should use the best tool for the job. One of the things I forgot to mention, though, with Ruby and Rails is you can really ramp up new engineers very quickly with Ruby, and I found probably more quickly than with most other languages. If they have any experience in other languages and understand basic programming principles, Ruby is really easy to pick up.\n\nMIKE: I think there's a lot of truth to that. I might ask Ramses. You've been doing software development for a few years now. [laughs] What are your thoughts about learning Ruby as a primary language? \n\nRAMSES: Yeah, I've been doing it full-time for almost a year. But then, outside of it, I guess, for almost two years now. Yeah, Ruby was mostly my first language. I've delved into some others, like JavaScript, of course, and Lua, and a few others. But, yeah, Ruby was...it's just easy to ramp up pretty quickly and cling on to, I think. It's easy to read, you know, which really helps in learning the language if you can understand it quickly, and you don't have to think about it too hard. \n\nMIKE: You say Ruby is easy to read. I think it's shockingly easy to read if you've been maybe working with another language for a while [chuckles]. Ruby lends itself to very friendly, almost human language-looking code, not in, like, a forced way. But it just...the idioms naturally flow such that it reads similar to human languages. And that means that your code ends up looking almost like documentation. And I think that has tremendous value.\n\nMATT: It's the old joke that good code documents itself, right?\n\nMIKE: Right. [laughs] And you say it's a joke, and it is a joke. Like, I don't need any comments. I don't need documentation. My code is great. Those are separate concerns. But the truth is, if you have code that is really easy to read, that has a huge influence on the ability of new developers to get up to speed. If you have very obscure code, you may end up having developers scrap it and start over again, even if the code was perfectly good, just because they can't understand it. \n\nAnd if you can't understand something, you can't adequately maintain it, or you're taking so much time understanding it that you might as well have rewritten it, to begin with, and no amount of documentation can really fix that. So using a language and even just paradigms—this applies beyond Ruby—writing in a style that lends itself to ease of reading is a big deal, in my opinion.\n\nMATT: I 100% agree with that statement.\n\nEDDY: The toughest part about being a new developer or your aspirations is, like, shifting your brain to think in a certain way. And if you pick up a language that has a daunting syntax, it's just really hard to wrap your head around everything else. So, if you pick up Ruby as an introduction to the language or to programming, I feel like it starts cultivating your brain in such a way that it gets easier to pivot to other languages once you get your thought process and your brain thinking that way, or at least it was for me anyways.\n\nMIKE: I've actually read, not for programming languages but for natural languages, that there's been some research that says that learning a language that's easy for you it sometimes...and there's even, like, artificial language like Esperanto, which is sort of this made up language that's the generalized European language that's meant to be easy to pick up, easy to speak, and follow some loosely Latin roots to make it familiar to people with some European background. \n\nPeople who learn that language can then much more easily pick up their next natural language. So, if you are somebody who comes from a European language background, or Western language background, say English, and you want to learn something like Chinese, it can actually be faster to learn another European language like, say, Esperanto or Spanish, or French, you name it, first, and then learn Chinese. And you will actually learn, you know, you can go study Mandarin. \n\nYou'll actually learn that second language faster than if you started with the second language to begin with. [laughs] That stepping stone actually does train your mind. And there's research behind it. You can look it up. I don't have the reference right in front of me, but I've absolutely seen that. I think that that's strongly backed up. That's a really interesting point.\n\nEDDY: So, yes, so I would argue, yes, Ruby, for new developers. So for people who are aspiring but have no prior experience.\n\nMIKE: And it's also interesting because Ruby will encourage you to kind of go functional light, [laughs] to start thinking about things in some at least moderately functional way, as well as learning object-oriented, kind of an object-oriented paradigm at the same time. So if you're going to move on and go into functional languages, or if you're going to go on and do object-oriented programming, you've already had a taste of it and will be well prepared and have your mind thinking about how to think about problems in that way. I don't know that I thought about that as an advantage of Ruby before. I'm glad you brought that up, Eddy. \n\nSo we've talked a lot about kind of the utility of Ruby and where it's been good for us. Where are some places that you might not want to use Ruby? If you're going to take on a project, where would you say, no, I'm not going to use Ruby?\n\nMATT: Personally, anything with machine learning, I would definitely go with Python, anything with a heavy CPU and, you know, file processing, things like that. And, historically, you know, I came from the healthcare world, and we used to have to process these enormous EDI files. And I did a test because, initially, we wrote these converters in Ruby. One of the files may take an hour to process in Ruby. I converted one of them to Python, and it took, I think, three minutes. So definitely anything that has to do a lot of heavy lifting and file parsing I would not use Ruby for.\n\nMIKE: That's interesting. Were you using raw Ruby, or were you using some libraries? In particular, were you touching ActiveRecord at all?\n\nMATT: No ActiveRecord. We did use some libraries that were a clone of some C libraries, but it just couldn't do the lifting like Python could. And, I mean, ultimately, C is probably the best answer. But there were very few people in the company who knew C. So we ended up converting to Python because some of us knew Python.\n\nMIKE: Well, the interesting thing is that Python has a reputation as a slow language. And in some cases, Ruby is faster than Python. But, and here's the big caveat there, is there are libraries written in Ruby and in Python that are written in C. And so if you can exploit one of those libraries, you're just using a thin front end and a convenient language to use that really fast one. And it sounds to me like you were probably using some C code under the hood that was given to you by Python and --\n\nMATT: Yes, yes. \n\nMIKE: So you really were using C, right? [laughs]\n\nMATT: Yeah, but we just didn't have to write it in C.\n\nMIKE: Yeah, exactly. [laughs] I used a library quite a few years ago, in Ruby, that was a clone of the searching library from Java, Lucene, that underlies, like, whatever everybody uses for search. I say everybody, but that's not quite true, but it's largely true. Lucene is used by Elasticsearch and Solr. And pretty much every search solution I've seen uses Lucene under the hood. Somebody cloned it in C and made it into a plugin that you could use in Ruby. \n\nAnd I used that in a tool that was called Ferret, I think. I used it a number of years ago. And it was so fast. It was so blindingly fast. It was wonderful and buggy. [laughs] And when we got some scale, it would just crash. So we had multiple parallel instances of it running, and the company I was working for was using it heavily. And we were growing really fast. \n\nAnd over the course of a couple of months, it went from failing, like, once a day to failing, like, once a minute, [laughs] and that was clearly unacceptable. So there are some downsides to having that C behind the scenes if you don't have very well-written C that is heavily exercised by a lot of people and well-tested.\n\nEDDY: So I read a while back, and I don't know how true this is because I haven't had time to back-check. But, at one point, I believe Ruby on Rails was accused of being difficult to upscale. And I think that's part of the reason why Twitter moved away from that to Scala, I believe. And I think that's what the initial conversation that sparked the debate around Ruby on Rails scalability issues. So I'm just curious if anyone has any experience.\n\nMIKE: I have been in multiple startups that have grown tremendously, you know, that same company I was telling about that grew. We were serving about half a billion requests per month for a while. There's certainly bigger, but we had a lot of traffic. I read some articles about this. But I don't think that that was really what Twitter's problem was. \n\nThe problem was that they were using MySQL as a router, [laughs] and that aspect of the architecture was the key problem. And the language was largely irrelevant. And it was some fundamental architectural shifts, I think, that made the difference for them. I don't think that Scala is a bad choice. And I think that it probably made them somewhat faster in some regard. But I don't think that that was fundamental to their scalability issues. I think that it was something more fundamental architecturally.\n\nBecause, in modern web development, the way that you scale is you go out horizontally. And if you're using a somewhat slower tool, you can usually just scale out a little bit more and balance development costs versus server costs. And, oftentimes, the development costs are higher. So if you can make the development costs lower, you scale better, which is why people don't write all of their web code in C even though, technically, they could make it faster. \n\nYou know, most of it's done in interpreted languages [laughs] because the developer cost is higher, and it works. It works just fine. They can scale out. I really think that that is a false argument, from my perspective, because it suggests that it's crashing to use an interpreted language. And if that was so, then why is 65% of the web development being done in JavaScript? It doesn't seem like it holds water to me. That's my opinion.\n\nMATT: I think you hit the nail on the head. \n\nMIKE: To take that a little bit further, if the top languages are JavaScript, and Python, and PHP, [laughs] and that's what the modern web runs on, yeah, it blows that argument completely out of the water. Because, you know, Rails is a similar language, you know, it's an interpreted language. And they're all going to be, you know, approximately similar in performance. And you might get one that's twice as fast, maybe. But, in the end, that's just not going to make that much difference. \n\nAgain, the development costs are going to dominate over your server costs unless you're, you know, Facebook or Google, in which case, yeah, you should be using some really powerful low-level tools. And that's really not...well, maybe that's another place you wouldn't want to start with, Ruby. But the truth is, yes, you would because if you're going to be starting your startup, you're not Google. You're not Twitter. You're not a huge company X. You're some much smaller company. \n\nAnd you want to be able to prototype and get to market quickly and be able to keep your development costs low. So you're not going to want to build all of the heavy web infrastructure to launch your tiny little site that supports one client to begin with. That would be a foolhardy way to approach your company.\n\nMATT: I think that's a great point because when you are prototyping and trying to get to market quickly, you add a lot of tech debt, generally, right? Most initial applications are full of tech debt. And I think one of the nice things about Ruby and Rails is that refactors can go a lot more quickly than other languages. Extractions are pretty straightforward, for the most part. I think you're creating something that's going to be easier to manage and maintain until the necessity for something more powerful arises.\n\nMIKE: Yeah. I think that's really well said. You're not going to scale to the size of the internet giants on your first platform. To your point about tech debt, what you build your first platform to do is not what your final platform is going to need to do. It's going to evolve over time. And I think you need to go in recognizing that that's the case. And maybe you'll be able to scale enough. And a tool like Rails or some of the other tools we've mentioned will scale enough. \n\nFacebook has managed to do with PHP, and it's pretty much worked for them. Certainly, it's not going to be PHP all the way down, but you can make those work for quite a long ways. And then, for the time when you get big enough, we'll then use the right tool for the job.\n\nKYLE: From a performance perspective, having supported different languages, different applications written in different languages in a production environment, moreso thinking about in a Kubernetes environment, because that's what we use here, I would say that there was a bias, at least in my mind, around some of these languages, Ruby included, where it was one of those one to two ratios, meaning one CPU to two gigs of RAM to run any of these things in a stable manner. \n\nI wouldn't necessarily say that Ruby is the most lightweight. However, in the options that we've used here at this company, it does perform quite well. And scaling a Ruby application out with Kubernetes, meaning scaling it out with multiple pods, has been quite successful for us. So, like Mike was saying, maybe in a larger corporation where there is massive amount of traffic, Ruby wouldn't be the solution. However, from what I've seen with the traffic that we get, the Ruby apps do scale quite well, in my opinion.\n\nMIKE: Spoken from a DevOps engineer there. [laughs] That's really interesting. Thanks, Kyle.\n\nEDDY: Assuming that you do, in fact, decide, hey, I do want to build my website in the Ruby language, I was just curious to get the perspective of the group here on, like, why Rails is the top dollar when it comes to the framework. Because I know there's alternatives like Hanami, and Django, and stuff. But, like, what has set apart Rails that makes it that more important to use Ruby?\n\nMIKE: There's always some advantage in numbers. So if you go with the more popular one, you're going to get all of the libraries available to use. You search on Stack Overflow, you're going to get your answers more easily than if you go out in another direction. On the flip side, if you have some strong architectural opinion, if you really disagree with some things that Rails is doing, then there are some alternative platforms out there.\n\nAnd, a lot of times, you can even use some of the Rails stack. You can use ActiveRecord today, which is a powerful part of Rails, maybe the reason that they got adopted. And then you can still use that useful tool and put another stack on top of it. It may be more power to you, you know if that's something you really care about. It's going to be harder to find developers. It's going to be harder to find answers. You're kind of venturing off on your own. You're going off-road there, right? [laughs] But if that's something that you're comfortable with, then you can kind of become the vanguard, maybe even develop a following. It's a little riskier way to go. \n\nI might also say that Rails has some opinions that differ from the majority, particularly some of the decisions they've made recently around JavaScript. If you disagree with those opinions, then you might want to use something else so you have a tool that better aligns with the way you see the world.\n\nMATT: I think that's a fair statement. We need to use the right tools for the job, and there are, I mean, there are so many options out there.\n\nMIKE: There are. Rails still is the heavyweight in the Ruby community. If you want to stay in a language that's similar, you can always go with one of the Python frameworks. And they range from heavier like Django to some lighter-weight frameworks, Flask. Ruby has the same things as well. There's a popular lightweight framework called Sinatra, as well as some others. \n\nAnd I've written a Sinatra app before. And it was extremely successful. It was also an extremely small application, something that would work out well, probably in a lot of frameworks, something that might actually be a good fit for the JavaScript server-side, if that's the way you'd want to go.\n\nMATT: Yeah. And there's been...Padrino is another option. And I think we've been talking a lot about Python. But things like Elixir, I think, are an easy transition as well if you want to go the functional route.\n\nMIKE: Right. A lot of people get sold on the functional route. [laughs] \n\nMATT: It's true. \n\nMIKE: So, we've talked a bit about some good things about Ruby, some of the history, some reasons you might want to use it, as well as some places you might not want to use it. You might not want to use it [laughs] for doing any real heavy lifting on, you know, with file system or heavy CPU. You might not want to use it if that's not what the other people in your company are using. \n\nBut if you want to get up a quick prototype, I think it's really hard to beat Ruby as a language and Rails as a stack or one of its competitors because it's just so easy to get started. And I'm happy to still be using it, although I do use other tools as well.\n\nKYLE: One thing that I got thinking about was the community around Ruby, or maybe just the atmosphere. And I'm speaking to this from having worked with different languages different developers as well. And both points of view, I have to say that I don't know if it's just a mentality in the community or what it happens to be. But some of the more friendly, easy-going folks that I've ever worked with have been Ruby devs, as well having to dabble in and troubleshoot Ruby issues.\n\nThe extended community, be it on Stack Overflow or other forums and stuff like that...not that other languages don't have this too, but whenever there's assistance needed in the Ruby community, it seems to be very respectful and very helpful, which I don't always see in other languages.\n\nMATT: That's a really great point. I didn't even think about that, but I agree. The culture is a bit different for Ruby shops than, you know, some of the others, say, here's the extreme, say, like, a .NET shop, right? It just feels like Ruby shops have a tendency to keep that startup mentality, even as they scale. And Acima is a great example of that. We have such a great culture at this company, and you just don't find that so much in some of the more structured Microsoft-type companies. So that was a very, very good point.\n\nMIKE: There's an acronym that's used in the Ruby community we were talking about a little bit before we started our recording (MINASWAN); Matz is nice, so we are nice. Matz is the creator of Ruby. I don't know if it's a mantra, but it certainly is saying in a community that we should be nice like Ruby's creator. And I've definitely found that to be a case, in general, and found a very welcoming, caring community among Rubyists, which is great. And that's maybe a great place to close our session. Hopefully, this is useful to you if you're considering [laughs] whether to use Ruby for your next project. \n\nThank you everybody who's been participating today: Matt, Eddy, Kyle, and Ramses. And thank you for listening to our session of the Acima Development Podcast. I'll catch you next time.","content_html":"Why do you use or why do you not use Ruby?
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'll be hosting again this week. We have with us: Matt, Eddy, Kyle, and Ramses. And I hope to hear lots from them today.
\n\nOur topic is going to be about the Ruby programming language and, specifically, why or why you might not want to use Ruby. This is maybe an interesting time to be talking about that. To give a little bit of history of the Ruby programming language, it's been around since 1995 or so. The creator goes by Matz. He's from Japan. And Ruby was very popular originally in Japan. It was one of the few languages that was documented well in Japanese and became extremely popular in Japan. It wasn't so very popular outside of Japan. I'll get to the moment that changed in a moment.
\n\nRuby is an interesting language. It was inspired by a couple of languages, in particular, maybe most pointedly Perl and Smalltalk. Perl being a scripting language primarily used in shell scripts but also used a lot in the early web, and that is wildly flexible. If anybody has ever used Perl, reading Perl code is not for the faint of heart, but it's exceptionally powerful. And the people who use it tend to love it. And that was a lot of the inspiration for Ruby. So Ruby is very good at text parsing and doing the kinds of things you'd want to run scripts in the shell for.
\n\nRuby was also heavily inspired by object-oriented languages, not necessarily the ones you might think of like Java, but Smalltalk, which is deeply, deeply object-oriented. Ruby is more object-oriented [laughs] than most object-oriented things in that it doesn't even have what you typically think of as primitives. You can call methods on integers. You can call methods on strings, their objects, just like anything else is an object. Really, anything is an object you can call. You can call methods on methods. [chuckles] It's deeply object-oriented.
\n\nBut, on the flip side, it's also a deeply functional language in that every line is an expression. And it borrows a lot from functional languages as well. You don't ever see for loops in Ruby because idiomatic Ruby doesn't use that kind of approach, that kind of procedural approach. We use iteration and pass anonymous functions. It's got a special syntax for anonymous functions. So it's both deeply functional and deeply object-oriented and very good at text parsing. It's kind of an interesting language that allows you to do a lot of different things rather than necessarily having one way to do everything.
\n\nSo that was around 1995, Ruby was created. About ten years later, in 2005, there was a big change in web development. There was a new framework that came out called Ruby on Rails. And, at the time, in web development (I was out there at the time. [chuckles]), web development was pretty clunky. There was a lot of boilerplate you had to set up. There was vast amounts of configuration files.
\n\nIn the Java world, you'd set up a lot of configuration in, like, XML files before you could do anything. In the other interpreted languages like PHP, there was...really kind of fast and loose. People would do a lot of things without much protection, and there were a lot of security problems. By default, there were a lot of problems with unsanitized database access. And as a result, there were a lot of security breaches. So over on the scripting side, a lot of mess, over on the kind of big enterprise side, very difficult to use.
\n\nAnd Ruby on Rails came out, kind of bridging the world between those two. And it was written in a scripting language, giving you the ease of use of a scripting language and the quickness. Using an interpreted language, you tend to go faster with some of the structure that you'd get in the big enterprisey sort of frameworks. And it followed a lot of best practices, such as convention over configuration, so a lot of that boilerplate just went away. And it had a huge impact. Most of the web frameworks today are heavily inspired by Rails, even if they don't exactly follow what Rails did at the time.
\n\nNow, we are getting close to 20 years after that, and, you know, the world has moved on. Ruby on Rails is still around, but it's no longer the, you know, the top dog. I did a little research this morning, and JavaScript frameworks have absolutely taken over both on the client side and on the server side. We've got a world where there are client-side frameworks like React that dominate. And on the server side, JavaScript has largely stepped up as well. The most popular server-side frameworks are also written in JavaScript, well, with Node.js.
\n\nPython, which is a similar kind of language to Ruby, is also quite popular on the server side, and PHP is still kicking around too. You got frameworks like Laravel. The world has changed. Ruby on Rails inspired a lot of other frameworks, but itself has continued to evolve or maybe hasn't evolved as much as some of the others, which brings us to today. Our question is, why might you or might you not use Ruby today?
\n\nI want to share one anecdote of when I started using Rails myself. I started using Rails in 2005, the year it came out in beta. I was a Java developer at the time. And I first saw a presentation at a Java users group about Ruby on Rails. And I thought, ah-ah, I could do any of that in Java. [laughs] I honestly wasn't very impressed when I first heard about it.
\n\nAnd then, I got pressured by the company I was working at at the time to switch over to a scripting language. They were pushing for PHP. And I'd seen the kind of lack of structure at the time, and I was very resistant to kind of going into that Wild West that was out there at the time. But I thought, you know what? I'm going to try this new framework I heard about, Ruby on Rails. I learned the language and wrote a prototype over a weekend. I kind of devoted my weekend to it, which says something.
\n\nI was able to learn the framework and write a prototype of the app we were in over the weekend. We built out that app. And within a few months, we had rewritten our primary app in 1/10th the lines of code. There was literally 1/10th of the lines of code, even as we'd continued to add features. So the application could do more with a tenth lines of code as we had in Java because it's so much terser, and so much boilerplate was removed. I was impressed and kind of in love, [laughs] to be honest. It was so nice.
\n\nAnd I've been doing mostly Rails in the years since, and I've seen some good and bad. I can speak a lot to that. As to whether I'd start a new project in Rails today, I very well might. It'd depend on what I would do. If I wanted to do a very traditional web application, maybe with fast prototyping, I'd almost certainly go with Rails. If I wanted to do something new that had a heavy front end, I might use Rails on the back end because it's still a fantastic back end. But it's a good chance I'd use a JavaScript front end and not use what Rails provides for the front end.
\n\nSo if I were to share my opinion at a really high level of some things I might do, that's what I'd share. For anybody who's considering using Ruby, it's nice to know some of the history. I'm interested in what other people think about where Ruby and Rails are today (Rails has really dominated Ruby development since it came out) and whether or not you'd use it in a new project. Any thoughts, anyone?
\n\nEDDY: I went ahead and looked up at the top languages or stack of 2022. This one's particularly the most popular programming, scripting, and markup languages found from Stack Overflow. And to kind of reinforce what you were saying, JavaScript came in at 65%.
\n\nMIKE: Wow.
\n\nEDDY: Which is a huge chunk, right? And then dwindling down from that, you have HTML, CSS, SQL, Python, TypeScript, and all the way in the bottom 6% of those were Ruby. So it kind of just gives me the impression, you know, that the hype train for Ruby has dwindled quite a bit over the years. And this is just judging off of the 2022 statistics. It begs the question, I guess, the context being why or why not Ruby? Well, I guess you could debate, based off this chart, that for job security potential or stuff like that, maybe Ruby was not a bad choice. But, again, I guess it just depends on what you're really aiming for.
\n\nMIKE: Yeah, popularity is an interesting metric because if it's highly popular, there's probably a lot of jobs available. That doesn't necessarily mean those are the best-paying jobs. [laughs] Ruby developers have generally been relatively well paid, I think because they tend to be able to do more with less. You get a lot done; it makes you more valuable. But if you can't find any developers, well, then the company is not going to hire Ruby developers, and the market collapses, and then your value as a Ruby developer just disappears anyway.
\n\nAnd there's a balance there, you know, 6% is still some. There's still a decent Ruby market out there. I mean, there's millions of websites out there. There are still large enterprise-y applications out there on Ruby on Rails, such as Shopify or GitHub. So, you know, there's still a vibrant Ruby ecosystem out there. But, to your point, 6% is not 60%. It's ten times smaller than the JavaScript world out there.
\n\nEDDY: I'm hoping you can kind of elaborate on that a little bit on why it's gone down. Is it just because it's an old language and, you know, loud voices get more attention? You know, so, like, JavaScript will get more popularity since you have different frameworks. Python and TypeScript is the new thing. So I'm just curious on, like, what has attributed to the popularity?
\n\nMATT: Like Mike, you and I have a very similar past in our career path and the languages that we've written in. Engineers, in general, have a tendency to jump on the hype trains, and we see things that are new and shiny. And because of the way our minds work, we're very curious, so we like to try new things. That's one of the reasons I think that JavaScript has taken so much traction because, you know, we spent all of these years only using it on the front end. And now that we can use it on the back end, it's like, oh my gosh, I can use everything in my application in one language.
\n\nBut, you know, you'll find that front end and back end are very different, especially if you're using TypeScript and things like that. I personally am not ready for the JavaScript back-end world. I don't feel like there's enough structure yet. There are a few frameworks, things like NestJs, that help with that. But just coming from someone who was strictly JavaScript, it makes codebases extremely hard to work in when people don't establish consistent patterns. And that's something that I really love about Rails.
\n\nYou know, there are definitely different ways of doing things with Rails. However, I think, for the most part, you're going to find a handful of patterns that get followed. I don't mean structurally as far as your code organization and things like that, but I mean the way your code is written. Ruby and Rails are very, very easy to follow and, like Mike said, very fast, and you can get a lot done with very little. And for that reason, I absolutely would use Rails for a back-end system today.
\n\nAnd again, like Mike said, I would use a JavaScript framework for the front end because you can definitely get more done that way. But that's kind of my opinion, you know, coming from, historically, I started out writing conversion code, converting COBOL scripts to Perl and PHP. Talk about a nightmare. And you really quickly see how loose and fast PHP could be as well. But, again, it was loose, and back then, everything was procedural. I think we yearn for some structure and some organization in our code.
\n\nMIKE: You know, you asked, Eddy, why people might be jumping on the new thing. I think that there is, you know, that hype that draws people. I think that's part of why people got on the Rails bandwagon in the first place as well, you know because you get some hype. People want to kind of be with the popular thing. And that's something hard to escape in human nature. But I think it's a bit more than that as well.
\n\nBut somewhat related, if you're going to be writing a big JavaScript front end, you're spending day in day out in JavaScript, and then you have to write a different language on the back end. That's a little challenging that you have to think in two different ways. If you can write in the same language on the front and the back end, you avoid some of that.
\n\nNow, I agree with Matt that they're pretty different between the front and the back end. And the back-end frameworks are not the same as the front-end frameworks. My experience thus far has been, yeah, they don't provide as much structure as I would like to have. And they tend to degrade into a mess without a lot of diligence and care from the developers, which sometimes is hard to maintain over a large group of developers in the company. There's some risk there.
\n\nBut not having to change languages is a real bonus. And a lot of people have gone with that since JavaScript is the only option on the front end, and you're having to do JavaScript. People think, well, why not just also do JavaScript on the back end? You know, that's kind of a compelling argument, especially for a smaller application, a smaller back end. It's convincing to a lot of people.
\n\nThere's also been the rise of Python, which is a similar language to Ruby. I'm not going to say they're identical. They have somewhat different takes on things, but they kind of fall into the same space. And Python has gotten very popular in the machine learning community, and where machine learning has been under such a big boom in the last few years. Now you have another language that a lot of people are using, and they don't necessarily want to learn something else to go into web development.
\n\nSo, if you're already doing a lot of machine learning, you're likely going to be using Python and using a Python framework, again, just so you don't have to have two different things that you're doing. And I think that there's a lot of that as well; people just want to use the same tool that they've been using. So, if you're doing a lot of heavy JavaScript front end, it's likely you're going to do some on the back end. If you're going to be doing a lot of heavy machine learning-type work, you're probably going to use Python because that's what you're already familiar with.
\n\nKyle, I'm interested from your perspective because you're over on the DevOps side, and you use a lot of different kinds of tools. And you've probably seen some of this, like, oh, I've gotten used to this tool, so I'm going to use more of it for this, or [chuckles] maybe you use so many tools that you're just, like, whatever fits in the moment.
\n\nKYLE: We're kind of a bit of a mix. We kind of started out as the team was growing. And I came with more of a Python background. My manager came with a Ruby background. And then my team lead; he had more of a Bash background for all the scripting that, you know, that we're doing. And that has kind of mixed as we've done things. And so when I've written monitoring tools, that's been in Python just because it's been familiar to me. And when backup jobs and stuff like that have been written, those have been in Bash because that's what was familiar to my team lead.
\n\nHowever, a lot of the other stuff was by our manager, and he was familiar with Ruby. So him and I go back and forth on that because there is a little bit of a competition between Python and Ruby, just at least in our team and, you know, which one's the better language. It's mostly a joke than anything anymore because, well, I do like Python. And I could do the same things that I do in Ruby in Python.
\n\nI've actually adopted and started writing a lot of our Terraform generators, is what we call them, using ERB just because the ERB option with Ruby is just so friendly to me, at least, to where I can just put a little bit of Ruby code into the ERB to help with the generation. And when I'm saying generation, we're creating little Ruby apps to generate our HCL code for our Terraform. We have quite a bit of that just to get our automation done. And that's just been easier to do than deviating to Python or something, as well as when we have been working with services in the teams because we do have Ruby developers here.
\n\nIt's really nice in our environment because we do work cross-services; not all the services are on the same version. And it's RVM, I believe, just feels so fleshed out to me. It's just really easy to set up those virtual environments. And maybe it's just the way I use it, but I haven't had that ease of a virtual environment. With Python, I tend to have issues here and there. Whereas RVM, I've hardly ever had any issues. So that's been really nice on the Ruby perspective.
\n\nIt's also been good...we have a tool called [inaudible 16:45], which is an internal tool which does wrap a lot of the more common CLIs like the AWS CLI and stuff. A proof of concept for that just to see how it'd work out that was written in Ruby, just because it was easier and faster to get it done. To solidify it to where it was, you know, cross-platform that ended up being written in Golang. But to get a proof of concept going Ruby is just really easy to kind of get those things done. It's really easy to get scripting, really easy to get templates going.
\n\nMIKE: And there are quite a few systems, DevOps tools that are written in Ruby. Are there not? You mentioned the ability to do ERB scripts with Terraform. And I haven't been much on the DevOps side for a long time. But I know that I will occasionally see this tool, like, oh, that's written in Ruby.
\n\nKYLE: You know, you say that, and nothing's coming to mind right now. I'm only thinking of the Python ones, but yeah, there are definitely some Ruby ones. I just have to think a bit harder.
\n\nMIKE: Yeah, I know that there are a few of them. And maybe they fall out of, again, with the hype cycle. Puppet is written in Chef or written in Ruby; it looks like. And it may have been slipping somewhat out of popularity. I'd have to go dig because I don't have a lot of expertise in there.
\n\nKYLE: Yeah. Puppet they have competition from other ones like Ansible, and Ansible is what we use.
\n\nMIKE: So that, yeah, that's interesting. So you end up using a lot of tools. You like Ruby, but there's other tools that can also get the job done. [laughs] And the best tool for the job, it sounds like.
\n\nMATT: I firmly believe that teams should use the best tool for the job. One of the things I forgot to mention, though, with Ruby and Rails is you can really ramp up new engineers very quickly with Ruby, and I found probably more quickly than with most other languages. If they have any experience in other languages and understand basic programming principles, Ruby is really easy to pick up.
\n\nMIKE: I think there's a lot of truth to that. I might ask Ramses. You've been doing software development for a few years now. [laughs] What are your thoughts about learning Ruby as a primary language?
\n\nRAMSES: Yeah, I've been doing it full-time for almost a year. But then, outside of it, I guess, for almost two years now. Yeah, Ruby was mostly my first language. I've delved into some others, like JavaScript, of course, and Lua, and a few others. But, yeah, Ruby was...it's just easy to ramp up pretty quickly and cling on to, I think. It's easy to read, you know, which really helps in learning the language if you can understand it quickly, and you don't have to think about it too hard.
\n\nMIKE: You say Ruby is easy to read. I think it's shockingly easy to read if you've been maybe working with another language for a while [chuckles]. Ruby lends itself to very friendly, almost human language-looking code, not in, like, a forced way. But it just...the idioms naturally flow such that it reads similar to human languages. And that means that your code ends up looking almost like documentation. And I think that has tremendous value.
\n\nMATT: It's the old joke that good code documents itself, right?
\n\nMIKE: Right. [laughs] And you say it's a joke, and it is a joke. Like, I don't need any comments. I don't need documentation. My code is great. Those are separate concerns. But the truth is, if you have code that is really easy to read, that has a huge influence on the ability of new developers to get up to speed. If you have very obscure code, you may end up having developers scrap it and start over again, even if the code was perfectly good, just because they can't understand it.
\n\nAnd if you can't understand something, you can't adequately maintain it, or you're taking so much time understanding it that you might as well have rewritten it, to begin with, and no amount of documentation can really fix that. So using a language and even just paradigms—this applies beyond Ruby—writing in a style that lends itself to ease of reading is a big deal, in my opinion.
\n\nMATT: I 100% agree with that statement.
\n\nEDDY: The toughest part about being a new developer or your aspirations is, like, shifting your brain to think in a certain way. And if you pick up a language that has a daunting syntax, it's just really hard to wrap your head around everything else. So, if you pick up Ruby as an introduction to the language or to programming, I feel like it starts cultivating your brain in such a way that it gets easier to pivot to other languages once you get your thought process and your brain thinking that way, or at least it was for me anyways.
\n\nMIKE: I've actually read, not for programming languages but for natural languages, that there's been some research that says that learning a language that's easy for you it sometimes...and there's even, like, artificial language like Esperanto, which is sort of this made up language that's the generalized European language that's meant to be easy to pick up, easy to speak, and follow some loosely Latin roots to make it familiar to people with some European background.
\n\nPeople who learn that language can then much more easily pick up their next natural language. So, if you are somebody who comes from a European language background, or Western language background, say English, and you want to learn something like Chinese, it can actually be faster to learn another European language like, say, Esperanto or Spanish, or French, you name it, first, and then learn Chinese. And you will actually learn, you know, you can go study Mandarin.
\n\nYou'll actually learn that second language faster than if you started with the second language to begin with. [laughs] That stepping stone actually does train your mind. And there's research behind it. You can look it up. I don't have the reference right in front of me, but I've absolutely seen that. I think that that's strongly backed up. That's a really interesting point.
\n\nEDDY: So, yes, so I would argue, yes, Ruby, for new developers. So for people who are aspiring but have no prior experience.
\n\nMIKE: And it's also interesting because Ruby will encourage you to kind of go functional light, [laughs] to start thinking about things in some at least moderately functional way, as well as learning object-oriented, kind of an object-oriented paradigm at the same time. So if you're going to move on and go into functional languages, or if you're going to go on and do object-oriented programming, you've already had a taste of it and will be well prepared and have your mind thinking about how to think about problems in that way. I don't know that I thought about that as an advantage of Ruby before. I'm glad you brought that up, Eddy.
\n\nSo we've talked a lot about kind of the utility of Ruby and where it's been good for us. Where are some places that you might not want to use Ruby? If you're going to take on a project, where would you say, no, I'm not going to use Ruby?
\n\nMATT: Personally, anything with machine learning, I would definitely go with Python, anything with a heavy CPU and, you know, file processing, things like that. And, historically, you know, I came from the healthcare world, and we used to have to process these enormous EDI files. And I did a test because, initially, we wrote these converters in Ruby. One of the files may take an hour to process in Ruby. I converted one of them to Python, and it took, I think, three minutes. So definitely anything that has to do a lot of heavy lifting and file parsing I would not use Ruby for.
\n\nMIKE: That's interesting. Were you using raw Ruby, or were you using some libraries? In particular, were you touching ActiveRecord at all?
\n\nMATT: No ActiveRecord. We did use some libraries that were a clone of some C libraries, but it just couldn't do the lifting like Python could. And, I mean, ultimately, C is probably the best answer. But there were very few people in the company who knew C. So we ended up converting to Python because some of us knew Python.
\n\nMIKE: Well, the interesting thing is that Python has a reputation as a slow language. And in some cases, Ruby is faster than Python. But, and here's the big caveat there, is there are libraries written in Ruby and in Python that are written in C. And so if you can exploit one of those libraries, you're just using a thin front end and a convenient language to use that really fast one. And it sounds to me like you were probably using some C code under the hood that was given to you by Python and --
\n\nMATT: Yes, yes.
\n\nMIKE: So you really were using C, right? [laughs]
\n\nMATT: Yeah, but we just didn't have to write it in C.
\n\nMIKE: Yeah, exactly. [laughs] I used a library quite a few years ago, in Ruby, that was a clone of the searching library from Java, Lucene, that underlies, like, whatever everybody uses for search. I say everybody, but that's not quite true, but it's largely true. Lucene is used by Elasticsearch and Solr. And pretty much every search solution I've seen uses Lucene under the hood. Somebody cloned it in C and made it into a plugin that you could use in Ruby.
\n\nAnd I used that in a tool that was called Ferret, I think. I used it a number of years ago. And it was so fast. It was so blindingly fast. It was wonderful and buggy. [laughs] And when we got some scale, it would just crash. So we had multiple parallel instances of it running, and the company I was working for was using it heavily. And we were growing really fast.
\n\nAnd over the course of a couple of months, it went from failing, like, once a day to failing, like, once a minute, [laughs] and that was clearly unacceptable. So there are some downsides to having that C behind the scenes if you don't have very well-written C that is heavily exercised by a lot of people and well-tested.
\n\nEDDY: So I read a while back, and I don't know how true this is because I haven't had time to back-check. But, at one point, I believe Ruby on Rails was accused of being difficult to upscale. And I think that's part of the reason why Twitter moved away from that to Scala, I believe. And I think that's what the initial conversation that sparked the debate around Ruby on Rails scalability issues. So I'm just curious if anyone has any experience.
\n\nMIKE: I have been in multiple startups that have grown tremendously, you know, that same company I was telling about that grew. We were serving about half a billion requests per month for a while. There's certainly bigger, but we had a lot of traffic. I read some articles about this. But I don't think that that was really what Twitter's problem was.
\n\nThe problem was that they were using MySQL as a router, [laughs] and that aspect of the architecture was the key problem. And the language was largely irrelevant. And it was some fundamental architectural shifts, I think, that made the difference for them. I don't think that Scala is a bad choice. And I think that it probably made them somewhat faster in some regard. But I don't think that that was fundamental to their scalability issues. I think that it was something more fundamental architecturally.
\n\nBecause, in modern web development, the way that you scale is you go out horizontally. And if you're using a somewhat slower tool, you can usually just scale out a little bit more and balance development costs versus server costs. And, oftentimes, the development costs are higher. So if you can make the development costs lower, you scale better, which is why people don't write all of their web code in C even though, technically, they could make it faster.
\n\nYou know, most of it's done in interpreted languages [laughs] because the developer cost is higher, and it works. It works just fine. They can scale out. I really think that that is a false argument, from my perspective, because it suggests that it's crashing to use an interpreted language. And if that was so, then why is 65% of the web development being done in JavaScript? It doesn't seem like it holds water to me. That's my opinion.
\n\nMATT: I think you hit the nail on the head.
\n\nMIKE: To take that a little bit further, if the top languages are JavaScript, and Python, and PHP, [laughs] and that's what the modern web runs on, yeah, it blows that argument completely out of the water. Because, you know, Rails is a similar language, you know, it's an interpreted language. And they're all going to be, you know, approximately similar in performance. And you might get one that's twice as fast, maybe. But, in the end, that's just not going to make that much difference.
\n\nAgain, the development costs are going to dominate over your server costs unless you're, you know, Facebook or Google, in which case, yeah, you should be using some really powerful low-level tools. And that's really not...well, maybe that's another place you wouldn't want to start with, Ruby. But the truth is, yes, you would because if you're going to be starting your startup, you're not Google. You're not Twitter. You're not a huge company X. You're some much smaller company.
\n\nAnd you want to be able to prototype and get to market quickly and be able to keep your development costs low. So you're not going to want to build all of the heavy web infrastructure to launch your tiny little site that supports one client to begin with. That would be a foolhardy way to approach your company.
\n\nMATT: I think that's a great point because when you are prototyping and trying to get to market quickly, you add a lot of tech debt, generally, right? Most initial applications are full of tech debt. And I think one of the nice things about Ruby and Rails is that refactors can go a lot more quickly than other languages. Extractions are pretty straightforward, for the most part. I think you're creating something that's going to be easier to manage and maintain until the necessity for something more powerful arises.
\n\nMIKE: Yeah. I think that's really well said. You're not going to scale to the size of the internet giants on your first platform. To your point about tech debt, what you build your first platform to do is not what your final platform is going to need to do. It's going to evolve over time. And I think you need to go in recognizing that that's the case. And maybe you'll be able to scale enough. And a tool like Rails or some of the other tools we've mentioned will scale enough.
\n\nFacebook has managed to do with PHP, and it's pretty much worked for them. Certainly, it's not going to be PHP all the way down, but you can make those work for quite a long ways. And then, for the time when you get big enough, we'll then use the right tool for the job.
\n\nKYLE: From a performance perspective, having supported different languages, different applications written in different languages in a production environment, moreso thinking about in a Kubernetes environment, because that's what we use here, I would say that there was a bias, at least in my mind, around some of these languages, Ruby included, where it was one of those one to two ratios, meaning one CPU to two gigs of RAM to run any of these things in a stable manner.
\n\nI wouldn't necessarily say that Ruby is the most lightweight. However, in the options that we've used here at this company, it does perform quite well. And scaling a Ruby application out with Kubernetes, meaning scaling it out with multiple pods, has been quite successful for us. So, like Mike was saying, maybe in a larger corporation where there is massive amount of traffic, Ruby wouldn't be the solution. However, from what I've seen with the traffic that we get, the Ruby apps do scale quite well, in my opinion.
\n\nMIKE: Spoken from a DevOps engineer there. [laughs] That's really interesting. Thanks, Kyle.
\n\nEDDY: Assuming that you do, in fact, decide, hey, I do want to build my website in the Ruby language, I was just curious to get the perspective of the group here on, like, why Rails is the top dollar when it comes to the framework. Because I know there's alternatives like Hanami, and Django, and stuff. But, like, what has set apart Rails that makes it that more important to use Ruby?
\n\nMIKE: There's always some advantage in numbers. So if you go with the more popular one, you're going to get all of the libraries available to use. You search on Stack Overflow, you're going to get your answers more easily than if you go out in another direction. On the flip side, if you have some strong architectural opinion, if you really disagree with some things that Rails is doing, then there are some alternative platforms out there.
\n\nAnd, a lot of times, you can even use some of the Rails stack. You can use ActiveRecord today, which is a powerful part of Rails, maybe the reason that they got adopted. And then you can still use that useful tool and put another stack on top of it. It may be more power to you, you know if that's something you really care about. It's going to be harder to find developers. It's going to be harder to find answers. You're kind of venturing off on your own. You're going off-road there, right? [laughs] But if that's something that you're comfortable with, then you can kind of become the vanguard, maybe even develop a following. It's a little riskier way to go.
\n\nI might also say that Rails has some opinions that differ from the majority, particularly some of the decisions they've made recently around JavaScript. If you disagree with those opinions, then you might want to use something else so you have a tool that better aligns with the way you see the world.
\n\nMATT: I think that's a fair statement. We need to use the right tools for the job, and there are, I mean, there are so many options out there.
\n\nMIKE: There are. Rails still is the heavyweight in the Ruby community. If you want to stay in a language that's similar, you can always go with one of the Python frameworks. And they range from heavier like Django to some lighter-weight frameworks, Flask. Ruby has the same things as well. There's a popular lightweight framework called Sinatra, as well as some others.
\n\nAnd I've written a Sinatra app before. And it was extremely successful. It was also an extremely small application, something that would work out well, probably in a lot of frameworks, something that might actually be a good fit for the JavaScript server-side, if that's the way you'd want to go.
\n\nMATT: Yeah. And there's been...Padrino is another option. And I think we've been talking a lot about Python. But things like Elixir, I think, are an easy transition as well if you want to go the functional route.
\n\nMIKE: Right. A lot of people get sold on the functional route. [laughs]
\n\nMATT: It's true.
\n\nMIKE: So, we've talked a bit about some good things about Ruby, some of the history, some reasons you might want to use it, as well as some places you might not want to use it. You might not want to use it [laughs] for doing any real heavy lifting on, you know, with file system or heavy CPU. You might not want to use it if that's not what the other people in your company are using.
\n\nBut if you want to get up a quick prototype, I think it's really hard to beat Ruby as a language and Rails as a stack or one of its competitors because it's just so easy to get started. And I'm happy to still be using it, although I do use other tools as well.
\n\nKYLE: One thing that I got thinking about was the community around Ruby, or maybe just the atmosphere. And I'm speaking to this from having worked with different languages different developers as well. And both points of view, I have to say that I don't know if it's just a mentality in the community or what it happens to be. But some of the more friendly, easy-going folks that I've ever worked with have been Ruby devs, as well having to dabble in and troubleshoot Ruby issues.
\n\nThe extended community, be it on Stack Overflow or other forums and stuff like that...not that other languages don't have this too, but whenever there's assistance needed in the Ruby community, it seems to be very respectful and very helpful, which I don't always see in other languages.
\n\nMATT: That's a really great point. I didn't even think about that, but I agree. The culture is a bit different for Ruby shops than, you know, some of the others, say, here's the extreme, say, like, a .NET shop, right? It just feels like Ruby shops have a tendency to keep that startup mentality, even as they scale. And Acima is a great example of that. We have such a great culture at this company, and you just don't find that so much in some of the more structured Microsoft-type companies. So that was a very, very good point.
\n\nMIKE: There's an acronym that's used in the Ruby community we were talking about a little bit before we started our recording (MINASWAN); Matz is nice, so we are nice. Matz is the creator of Ruby. I don't know if it's a mantra, but it certainly is saying in a community that we should be nice like Ruby's creator. And I've definitely found that to be a case, in general, and found a very welcoming, caring community among Rubyists, which is great. And that's maybe a great place to close our session. Hopefully, this is useful to you if you're considering [laughs] whether to use Ruby for your next project.
\n\nThank you everybody who's been participating today: Matt, Eddy, Kyle, and Ramses. And thank you for listening to our session of the Acima Development Podcast. I'll catch you next time.
","summary":"","date_published":"2023-06-07T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/c39e19f1-4852-4875-953c-281bbb0686e5.mp3","mime_type":"audio/mpeg","size_in_bytes":43107807,"duration_in_seconds":2288}]},{"id":"6bae38e6-0441-4f13-ba41-a600023d33ec","title":"Episode 18: What Inspired You to Want to Become a Developer?","url":"https://acima-development.fireside.fm/18","content_text":"Today we talking about what inspired us to get into software development and become developers.\n\nTranscript:\n\nMIKE: Welcome to another episode of the Acima Development Podcast. I'm Mike. I will be hosting today. We've got a panel here today of Afton, Diane, Eddy, Ramses, and Tad with me. And today, we're going to be talking about what inspired us to get into software development, what inspired us to become a developer. I have the luxury as the host [laughs] of being able to share my story first. \n\nI've been thinking about, as we've been preparing for this, what I might share, and I'm going to start back in childhood. And I may have shared this before, but I will share it again. When I was in elementary school, I don't remember quite what grade it was, like, second or third grade; our school got a computer. And this was a long time ago [laughs], back where the school would have a computer. And that was a big deal. We didn't have one at home. I'd seen computers at places of work but had not had a chance to play with one. \n\nAnd our school got a computer, and I got to use Logo, which is a language, if anybody has used, that lets you move a little turtle around the screen and draw lines behind it. And I thought it was just the coolest thing to be able to talk to this computer and have it do something. And what I particularly remember is that there was some sort of key sequence or something you could do to go to a back channel where it wouldn't show you the turtle, but you could write a little script. And then you could execute the script, and you could watch the turtle do a few things. I remember you could make spirals, and I thought that was the coolest thing ever. \n\nAnd you'd have the turtle go forward and then turn and then go forward again if you did it with the right angles. You could do it in a loop. There was some sort of looping construct. I don't remember what the looping constructs were. But I just thought it was like the coolest thing, and I wished I could do it all the time. \n\nThere was another kid at the school who was really good at doing this. I remember he used BASIC. And he inspired me. That's kind of a tragic story because he went on to be criminally prosecuted for a murder related to a drug transaction. But maybe that kind of pushed me away from it for a while. But there were other people around me who got computers, and kind of inspired me as well. \n\nLater when I was a few years older in junior high, my family got a computer which was, wow, it's a big deal. [laughs] And it was, I think, an i386. It came with a book for GW-BASIC, so it comes with BASIC, which is a simple programming language. And there was a manual along with guides on how to do a bunch of things. And I read through the manual cover to cover and did some of these example programs, and I had a great time. I would spend hours working on that. \n\nI had this from my childhood, and then I didn't really work on it for a few years. Again, as I mentioned, [laughs] my friend who had some interest in it went down a dark path. I kind of got away from it. And then, when I was in college, I was originally pursuing botany and genetics, molecular biology, and I got kind of scared off by that field because I didn't feel very comfortable with the lack of ethical constraints, what was going on. I'm kind of glad I got out of that industry because there are some ethical conundrums there that are challenging, but they are in every field, so I don't think it's escapable. \n\nBut then, in college, I was looking for what I wanted to do instead, and I took a coding class kind of on a whim. And I was like, oh, that's right, I loved this. [laughs] And I thought I could make a career out of this, and this would be a great career. And I never really looked back. I've been doing it ever since. And I've been coding full-time for over 20 years now. I've really enjoyed it. \n\nThere is a joy and a thrill in being able to solve problems and get this computer to do something productive and useful that is hard to explain to people who haven't done it. If you haven't done it, I recommend you try. Have that experience for yourself. That's kind of my background, what inspired me to become a developer. I could talk about more, but that's kind of the big picture of my progress. What are your stories?\n\nTAD: I started out back in the early '80s. Texas Instruments decided that they wanted to get into this new home PC thing. And they came out with a computer called the TI-99/4A, and my parents got one for our family for Christmas. And it was just fascinating to me. There were these clunky things where everything was kind of contained in this keyboard that you plugged into your TV and that you use as your monitor. And then you got games or other things that came on cartridges that you'd slide in the slot in the front. And it booted up, and you'd play the games and do whatever. \n\nBut when you first started it up, it gave you an option screen; number one was basically programming BASIC, and number two was the option to boot up whatever cartridge you had put in. And for a while, I just kind of ignored option one. But then I was kind of like, well, what is this thing, you know, programming BASIC? [laughs] So I started choosing option one, and I'm like, oh, I could do line numbers in a loop because it came with a little manual you could read and figure it out. \n\nAnd so I started out with the really simple stuff like the guess the number games or doing a loop like you are awesome and just prints it over and over again, whatever. And I did that for a while. Probably the height was I came up with a song, and I programmed the computer to play the song in a very electronic way. And I recorded it, and I submitted that for the Reflections contest. And everyone thought that was so novel. I made it up to region or something. And I'm like, yeah, computers and computer music and stuff. \n\nBut I think I kind of followed your path, Mike, where that was really cool when I was younger, and then I kind of fell away from it because there were other things to do. And I didn't get into computers again until probably high school because I had a lot of friends in the computer club. My computer science teacher in high school was kind of a visionary, I think, because she...this was back in '93, '92. And she was connected to this...the computers at the college were connected to this new thing called the World Wide Web.\n\nThis new thing like FTP [laughs] would be able to connect to that, and from there, we were connecting to the world, and this was back in '92. And we're like, whoa, what is this? And she was doing things like video conferencing. And it was like grainy, little black and white things. And we used HyperCard to control the LaserDisc player that she had. And it was pretty crazy. And that, I think, really reignited my interest in computers and computer science. And I was the vice president of the computer science club and getting into that. \n\nBut my real passion in high school was chemistry. And I got like a five on the AP chemistry test. I was just doing awesome things with chemistry. I got a scholarship in chemistry and got into the University of Utah. And I was sure that that was my path; that was what I was going to do. But once I got into college, I realized I really enjoyed learning chemistry. And I really enjoyed the fun things like blowing things up or making soap or whatever little projects that you do. But I really didn't enjoy the long-term labs. I didn't enjoy the reports. I didn't enjoy sticking samples in machines and writing reports, that kind of thing. \n\nBut I had all this chemistry, and I'm like, well, I don't want to lose the credit for that. Maybe if I switch over to something kind of parallel, I'll find my passion; I'll find what I want to do. So I switched over to materials engineering and was doing that. I wasn't loving it, but they promised us the third quarter is when they get into the real stuff, like the real stuff that you're going to learn about and do in materials engineering. \n\nSo I stuck it out. I took the third-quarter class, and I hated it. I don't know, like, it was so boring to me because a lot of it was stick a sample in the machine, collect the data, write a 20-page report, literally 20 pages. And we were doing that every week. I'm like, ah, this isn't what I want to do. And I kind of got bummed out and decided to just drop out for a while because my reasoning was, why pay money to do something that I don't enjoy? \n\nAnd so I took a bit of time off to just go home, get a job, figure it out. And it was interesting because I was out mowing my parents' front yard, and one of my old high school teachers came by, and she actually mentioned she's like, \"Oh, I thought you were going to go into computer science. That was what you really seemed to be passionate about back when I was teaching that stuff.\" And I'm like, oh yeah, [laughs] I kind of was. And I had been doing a computer science minor the whole time. \n\nAnd it just dawned on me; I'm like, those were the classes I really liked. Those are the things I really enjoyed doing. Why don't I just make up my mind on my major and go back to college? And being able to take your thoughts and make them into something and just be able to create anything you want, just the variety and the things you get to learn and the things you get to do with computers turned out to really appeal to me. And so that's how I kind of switched paths. I went back, got my CS degree, and I've been doing this for, gosh, somewhere about 16, 17 years, I think. \n\nMIKE: Nice.\n\nAFTON: I'm really eager to kind of talk about my story now because it's quite a different path. I grew up with zero interest in computer [laughs] programs and, in fact, being very intimidated when I had to interact with computers. Occasionally, I was shown how to play a game on there. And in school, I knew how to get to my Word documents to type my papers, but that was it. I did not do any more than was absolutely necessary involving computers. And I knew nothing about programming and just had very limited exposure to anything of that sort. \n\nAnd my passions were nature and dancing, and I was highly involved in music and theater. And I ended up...in school, I started out as a math major because I really had always loved math, and then switched to music and got my degree in music. And my favorite part about my music experience was the music theory, which was very mathematical, very exacting. I loved learning about how notes related to each other and the different sounds you can make by tweaking. And if you followed certain patterns and certain rules, you could create something beautiful. I loved that exactness and learning those little tools and the rules for creating something. \n\nAfter I graduated, I started a family and stayed at home raising and homeschooling my kids and almost never interacted with computers except online, whatever. But there came a time where I needed to start a career. And I was looking for a way to gain some independence and support myself and something that would give me some flexibility because I had young kids and wanted something that could work with my life in some way. I had some people really close to me who had gone through QA and were then web developers and software developers, and them knowing me, they were like, \"You should try development, writing code. I think you would like it. I think it's up your alley.\" \n\nAnd I really resisted that idea. I was just like, no way. Computers, programs, I mean, I know nothing about that world. And so for at least two years, I was just like, no, that's not my thing. And I thought about going back to school to become a dance teacher or maybe going back to school to pursue biology more, which had been my minor.\n\nBut when it came down to it, I was thinking about, well, if I go back to school and invest a ton of money and a ton of time, that's one path to finding a way into a career. Or is there something I could do from home while I'm homeschooling my kids that I have time and maybe not as much money resources to pour into? Is there something I could do that I can give it time and less money? [laughs] \n\nAnd so finally, in 2015, when I was in my mid-30s, I decided to find a free coding course online and take my first coding course. It was on Codecademy, and I took HTML and CSS. And it was so much fun seeing how I could type something, and then it did something on this screen visually, and I could play with it. It blew my mind how much fun it was. [laughs] \n\nOver a couple of years, I dabbled with some various basically free courses that I could find online. There were so many resources. It was really incredible what I was able to find and do. And also my local library...I went to the library, and I browsed the software books, and I found one on Ruby on Rails by Head First. And so I checked out that book, and I went through it like I was doing school like a textbook, and I built my first Ruby (It wasn't Ruby on Rails; it was just Ruby.) application. \n\nSo about two, two and a half years in, I put my children into public school so that I could spend full-time basically schooling myself and learning how to write code and solve problems. I just thought it was really intriguing and super fun to have a problem I had to solve and to just have to chase it down, and search, and Google, and read documentation, and try to figure out how to build an app. And I found the problem-solving and the investigation just really thrilling. And it was just like a treasure hunt every day with a new problem I had to solve. [laughs]\n\nSo I guess I just found a lot of joy and intrigue in the problem-solving and thought; I do love this, and I seem to have skills that help me be successful. I'm persistent, and I love the nitty-gritty details of everything and finding out what I do can impact various things, and just really enjoyed it. So I jumped into the world as a summer intern for my first job, and that's still what I'm doing. \n\nSo largely, my motivators were finding something I could do that could help me to gain some independence financially. It's something that can support life, a well-paying job, and something that was intriguing and interesting that I could love. It was a surprise to me. And I was encouraged to try out this world, but it surprised me. And it's been a fun journey. I'm still learning every day what skills I can bring and learning as I go.\n\nMIKE: There was something I was noticing, Afton. You said that your background was a lot different. But you notice that nobody who's spoken thus far started their career saying, \"Yes, I'm going to go and build software.\" [laughs]\n\nAFTON: [laughs]\n\nMIKE: None of us. We started in something else, and for whatever reason, that wasn't the end of our journey. And then we went to coding either for the first time or went back to it and, like, wait, this is great. That moment of discovery when you can work with the computer and it does things that you say sparked something. It's interesting to me how much commonality there is between all of our stories so far. The specific year we happened to start, I'm going to argue, is not that relevant, [laughs] rather that we weren't there, and then we got into it. That's cool.\n\nEDDY: I'd be lying if I didn't admit that a huge contributing factor for choosing this was the salary ceiling is much higher than most after a few years. That was a huge factor. I remember I took a small typing class in junior high which, by the way, in hindsight, [laughs] has paid huge dividends with programming, like, holy cow. I can be much more efficient typing what I want and stuff. So I don't know if knowing how to type is essential or if people require that as a skill, but it was fantastic. \n\nBut that class that I took, the teacher implemented a small HTML course to kind of fill in time gaps throughout our typing sessions. And we were able to change the color of text on the screen from black to red. I still remember I was like, what the heck? I got filled with joy, and I was like, dang, I was able to tell the browser what to do with a few lines of code. I was like, this is insane. I remember feeling super joyful in that, and I was like, dang, this is really cool. \n\nBut it ultimately was a hobby for a while, and even after high school, I didn't have much direction for what I wanted my career to be. And then, it wasn't until the pandemic hit pretty hard in 2020 and I realized that I have a small family that relies on my income. And I was mortified that I was going to lose my job; fortunately, I didn't. But that was a huge epiphany for me that I needed a specific skill that will prove to be more flexible and provide better job security. \n\nThen I remembered that I found coding pretty fun and entertaining. So I spent most of my time at my job at the time during lunch...I boot up my computer, and I just downloaded an IDE, and I just began self-learning with videos and stuff. And I delved into the React framework I remember. I looked up what are the most high-demand languages, and React was pretty popular. And I'm like, sure, I'll pick it up. There were even times where I was on the clock, and I whipped out my phone and I watched videos. And I hit a point where I dreaded the job that I had. And I really decided to take it seriously. \n\nI remember I tried going back to college. But first of all, I'm not very academic, and I ended up dropping out after the first semester. But I remember I spoke with someone there, and they told me, \"Yo, you don't need a college degree. Going the academic route isn't really for everyone. You don't necessarily need to.\" And I was like, wait, you can be a developer without a degree? That's insane. That made me wonder, like, what? \n\nBut I joined Reddit forums and a lot of blogs and watched a lot of videos. And a lot of people were like, \"Oh yeah, you can totally penetrate the industry,\" so that's what I did. And after three months of really, really being heads down with learning and being motivated, I shot a Hail Mary, and I applied at Acima for the QA position. Matt Rampey was the team lead at the time, so if he happens to hear this, hello. And I guess he really liked the motivation and hunger to really penetrate the industry and really aspire to self-learn. \n\nSo now I've been employed for about a year and a half. And I've been striving to push myself to get out of my comfort zone and, pick up backlog tickets, reach out to developers. [laughs] I was like, hey, like, help me out. And I attribute a lot of my success thus far because I've paired with most of you with tickets, and I attribute a lot of my success to you guys because of all the patience that you've demonstrated up till now.\n\nMIKE: That's great. [laughs] And we love having you working with us too. I'm going to point out to our listeners again the commonality here. [laughs] Notice that nobody really knew they were going to do this right at the beginning, and then they discovered it and noticed how much joy it brought them. Thanks, Eddy.\n\nDIANE: I guess what sparked my interest and my curiosity was a class I took in high school, I believe. It was computer science one. And I took it because it was just a class to fill in. And the teacher introduced us to Scratch just to make your own little game on it, and we did that for the whole entire year. We just mainly focused on that. And if I'm being honest, at first, it didn't really catch my attention or anything like that. I wasn't very interested. \n\nAnd so as the course went on, it was really fascinating and really cool to create your own games, seeing how all the motions and the integrations that they had within Scratch. You could just make the game on there. After taking that class, I believe it was my senior year; I totally forgot about it, scratched it out, literally. [chuckles] And I went to school for marketing initially. And I went for about three years, so I almost graduated, but then I realized it wasn't something I wanted to do. \n\nSo I took a long break and I started working at Acima as a processing agent. And after being in the processing department for a bit, I decided I wanted to go to a coding bootcamp. And from that, I got inspiration from someone who I look up to, and she's more of a big sister to me. So she went to a coding bootcamp, and seeing her go through that and excel in that coding bootcamp and excel in her career after really inspired me to go. \n\nSo I went through the coding bootcamp and actually reached out to Afton after I had finished the coding bootcamp. And we did some pairing after work hours, and it was really great. And I was able to learn a lot. And then she let me know that there was a QA position opening up, so I decided to take the chance and reached out to Ryan, who then interviewed me. And that's where I am now. I didn't think I was going to really excel in the career, but yeah, here we are.\n\nMIKE: One thing I noticed is you mentioned there was somebody who was like a big sister to you who inspired you to go forward. Afton, you've mentioned that you had a couple of friends who said, \"Hey, you should try this.\" Tad, you said you had a teacher, a former [laughs] teacher who remembered you and inspired you, and I probably have overlooked. There's a pattern here of people being inspired by somebody. Am I picking up on this accurately that there was a mentor who made a real difference to you?\n\nDIANE: Yeah, she actually also worked here for a bit. So she actually got me the processing role and then pushed me to pair with Afton. [laughs] So yeah, she is the one who really pushed me to do the stuff that I am right now.\n\nMIKE: Oh, that's great. I know I've worked with a number of people who are just starting their careers. I'm thinking of somebody...I don't want to name somebody who can't be here and speak for themselves, but there was somebody who was just working at a front desk. I say just working, but it was kind of a demanding position because she was the executive assistant and did all of the [laughs] coordination of the company, but she was not doing a technical role. \n\nAnd she came and joined me and some other developers for a mentoring session during lunches, kind of like what Eddy was saying. She just came and joined us during lunches, and we took our time during lunch to start teaching her what we were doing and let her pair with us and review our code. And she ended up some years later working here at Acima and has gone on, and she's leading a department at another company. Seeing that is immensely gratifying as a mentor. \n\nActually, one of my really good friends in high school went into civil engineering. And he had kind of gotten stagnant in his career and asked if I would take a few days and teach him and some of his co-workers a class on coding and kind of get them started into it, not as much as a bootcamp. Imagine a really compressed bootcamp; learn how to code in a week kind of thing. It's not enough to completely launch your career but enough to spark their interest. And my friend is now working at a software company and has been for a number of years. That changed his career. \n\nJust a couple of examples of the little things you can do, just taking some time during lunch or taking a week to teach a class ended up changing the trajectory of somebody else's career. So we're talking a lot now about our time as the mentees, the people who were inspired. But the work that we do, even if it's just a little bit to help somebody else in their career, can make a huge difference.\n\nTAD: I think it's interesting. I had to write a paper in college, and so I chose to write about why and how people get into development and things like that, and often, it's two things, someone has to have access to a computer and be able to interact in some way that sparks their interest. And then they also need someone to mentor them, or push them, or notice them, and put them on the path. Those are two things that people usually point to as what set them on the path.\n\nAs you were talking, I was thinking I know this person who used to be an accountant, so they used Excel all the time. And they're like, \"Oh, man, I wish I could make this easier on myself.\" And so they started learning formulas, and they started learning macros, and they started learning these things. And they're like, \"Oh, man, [laughs] I like this better than accounting. How do I do this?\" And happened to have lots of friends that were all devs, and they were like, \"Oh, you probably would like this.\" And suddenly, they're a developer now. \n\nMIKE: That's really cool. \n\nRAMSES: Funny enough, Tad, that's not exactly how I started, but before being a full-time developer and before I was in technical support, I was in more of an auditing position where I used spreadsheets quite a bit. And filling out spreadsheets manually it's really, really tedious, or processing information on a spreadsheet can be really tedious. So I spent a lot of time researching and learning how to automate some of the really repetitive tasks that I was doing, and that kind of got me interested. \n\nI've always been kind of around computers because I was first exposed to computers when I was in elementary school, probably. And I played a lot of games, video games growing up. So I was always solving puzzles or doing quests in games. It sparked my interest in problem-solving. But once I joined a technical support role, I think that kind of drove my interest into development quite a bit because in my technical support role here at Acima, I would often do QA tasks, or I was starting to do more development work because I was always just around code. \n\nSo it was a good opportunity for me to just learn what was happening. And I was really curious in obtaining that knowledge, and I still am today. I spend a lot of my time learning new things and trying to be more efficient, trying to just push myself. That's what inspires me today is just getting better.\n\nMIKE: That's cool that you were in Excel also. I remember thinking it was cool to write formulas in a spreadsheet, [laughs] the spreadsheet software I was using. This was before there was...so this was...a little hard to think about this way, but there used to be command-line spreadsheets, terminal-type spreadsheets. It would fill your screen, but it was very different than the graphical environment we have today, but it worked just the same. [laughs] They'd have keyboard shortcuts that you'd tend to use more rather than using your mouse, but otherwise, the experience really hasn't changed that much. [laughs] And I loved that. I really liked writing the formulas. \n\nI also remember doing some computer-aided drafting in AutoCAD, and there's some scripting you can do there as well that I didn't do a lot of, but I guess it was quite sophisticated. And it was also interesting and fun. I guess I didn't really perceive that as coding. I think a lot of people have that same experience. \n\nWe thought, oh yeah, coding, that's just kind of something you do for fun. It's kind of an enjoyable part of the job. This isn't something you can make a career of. It turns out, yes, it is, and it's in high demand. We need people [laughs] who can do that. Anybody else have those experiences doing bits of code in places that you wouldn't necessarily think of as coding at the time?\n\nTAD: I think it's interesting. I believe this is true that pretty much all Adobe products now let you do script stuff with JavaScript. And I know some designers who started off just, oh, gosh, I need to automate these tasks. These things I'm doing in Photoshop or Illustrator, whatever, are really repetitive. [laughs] I wish I could automate this stuff, or I wish I could figure out a way to save this file in three different formats so I can give it to whoever and didn't have to do that manually. \n\nAnd they don't necessarily become full-on developers, but they start writing their own scripts. And they start sharing their scripts or downloading scripts that other people have written and modifying them and stuff. And so it's interesting to me to see that even things that aren't full on I'm a developer, they are...like when I'm helping a designer debug his script, and he's like figuring things out, and like, \"Oh, I got the variable wrong,\" and all the tweaking and stuff. I'm just like, oh my gosh, this is ubiquitous. This stuff is everywhere, and a lot of people are doing a bit of development as part of their jobs, even though they're not technically full-on developing.\n\nAFTON: This kind of reminded me because I was thinking, I don't think I ever did anything like that. But then I remembered before I ever took my first coding class, I had a blog that I spent a lot of time on, and it was around having premature babies because two of my children were born prematurely. So I had started a blog that I spent a lot of time writing for, and I had some management UI that I could tweak things, and schedule, and make changes, and change colors or fonts. There was a little bit of customization I could do. \n\nBut my husband at the time was a web developer, and he would be like, \"Oh, look, you can go to this place, and you can see the code that's producing [laughs] your page. And you can actually mess with it.\" And so there were a few things I wanted to change that he got in and changed. And I remember being really excited that that capability was right there. But it was like a foreign world, and I didn't know how to interact with it. But now that you're mentioning it, that did spark this intriguing like, oh, that's cool. So there was a little bit of that for me.\n\nEDDY: I have a generic question for everyone here. Knowing what you know now, what personality traits should a person have in order for you to recommend them to programming? Like, oh, yeah, you're this kind of person. I think you'd be a really good fit for programming. \n\nRAMSES: Curious, probably. \n\nMIKE: I was thinking the exact same way, curiosity, and tenacity.\n\nRAMSES: Yeah, that's a good one.\n\nAFTON: I was going to say they like paying attention to details or organizing. [laughs] Those are skills I find helpful. And also don't easily get frustrated; someone who's willing to push through, even when something is difficult, willing to keep digging and persisting on a problem until they find a way to make things work.\n\nMIKE: Absolutely. That's what I was trying to aim for with tenacity.\n\nAFTON: Okay. [laughs]\n\nMIKE: Maybe it didn't land. [laughs] I couldn't agree with you more. I've said to people before that software development is mostly about frustration management. And I'm really not trying to be snarky. I mean that fully because you're solving problems. And frustration, by definition, is getting blocked when you're trying to solve a problem or you're trying to do something. If you're trying to work through and solve some things, of course, you're going to run into roadblocks. If there weren't any roadblocks, the problem would already be solved, and you wouldn't be solving it in the first place. \n\nSo being willing to keep digging, even when it's frustrating, you know, manage the frustration and say, \"Yep. I'm frustrated, and I'm going to keep looking because I'm frustrated,\" rather than being dissuaded, and that also connects to the curiosity that Ramses was saying. If you feed that curiosity, that gives you the emotional strength to keep digging, even though you're frustrated. Is that consistent with the experience of you all?\n\nTAD: Yeah, I'd maybe even add creativity, maybe orthogonal thinking, meaning you have to generate like a whole bunch of different possible ways that you solve a problem. And then you try one, and you're like, oh man, that's not going to work. Okay, I've got to back up and take a different approach at this. Oh, that solution doesn't work either. And being able to think of a few different ways that you could solve the problem, which is really hard to get, and they don't really teach in school very well, I think.\n\nIt's funny to me that when I talk to people, they'll make excuses like, oh, I wasn't really that great at math in high school, or something like that. And the general perception of what you need to have to be a developer is different than what I think you actually need. I've heard a lot of excuses. [laughs] Like, wait, no, if you want to run an atom collider, then you probably do need to be really good at math. You have to have a really deep physics background. But if you want to tweak your blog, do you really need that math? Probably not, right? [laughs]\n\nEDDY: I feel like there's a stigma from everyone from outside the scope where they're like, \"Oh, every programmer and computer scientist needs to have huge mathematical comprehension.\" And like, [laughs] it could just be that I've only picked up semi-easy tickets, but to this day, I have yet to really hit a block because I'm not able to understand a math formula, and that's something. It could be different for senior developers.\n\nMIKE: Has anybody here read a \"Mathematician's Lament,\" also sometimes called \"Lockhart's Lament?\" It's written by a professional mathematician, and his lament is that mathematics teaching drives mathematics out of everybody. [laughs] And I laugh a little bit, but it's a tragic take on how that curiosity and creativity that you're talking about, Tad, ends up getting lost from rote teaching and learning to memorize the ways of doing things. \n\nBut what professional mathematicians do is nothing like memorizing formulas; rather, it is exactly what you described of coming up with a bunch of different possible ideas and creatively trying to find other ways to approach a problem and then trying out and see if they work, which is play. And play has evolutionary purpose. It's what we do to learn about the world, but it's fun. The fact that it's useful doesn't change the fact that it is fun, [laughs] and it is rewarding, that it is a joyful thing to do.\nThis is about mathematics. But if we treat anything, be it music, or writing, you name it, any human endeavor, if we make it something that's about memorization and regurgitation, we take that joy away rather than letting it be play, and computer science or mathematics, in general, is no different. A lot of people who think that they are not a math person really don't like being bored and genuinely have the ability to find creativity and pleasure in building things and just haven't been given the opportunity. I'd like to throw that out there.\n\nAFTON: Mike, you mentioned learning through playing, and that reminded me that Ramses had mentioned that he loves learning every day and continuing to learn. I was thinking of that as another big drive to go into this field was that it would require constant and continual learning forever, and the challenges would always be new. And there would be new tools you could learn about to implement. And so I imagine this would not be a job that I could get bored at but that it would be constantly challenging and rewarding and always push lifelong learning, which really, really, I loved that idea. That was something I wanted.\n\nMIKE: Yeah, it's true, isn't it? Not only is it something that will happen, but it has to happen. You can't have a career [laughs] in this field without the daily learning.\n\nTAD: And it's not learning, just development. I've worked in the oil and gas industry. I've written software for the veterinary industry. I've worked at a marketing agency. So I've also had to learn those domains. I know a lot about how veterinarians track their medications and treat their animals and things like that. And I know a lot about a bunch of regulations about the oil and gas industry now and how they figure out mapping stuff. And it's everything, like, software is everywhere. And so you're learning development, but you're learning a little bit of possibly anything else.\n\nMIKE: Maybe to take that a little bit further, none of us started a career in software, but we ended up there. And there's, I'm sure, need in whatever industry you're in, if you're in retail, if you're in oil and gas [laughs] industry, if you're a barista. You shouldn't necessarily think that software is somewhere else. There's probably a surprising amount of need for software right where you're at. And you might be able to pivot more easily than you think if you're not a software developer yet. Take that as a challenge. We need more developers. You shouldn't feel daunted by the fact that you haven't gotten there yet.\n\nEDDY: Mike, I just want to point out that when you and Afton mentioned managing anger or pushing past those blockers, you know, frustration, I've hit that point with RSpec. I just want to say that. [laughs] But I'm pushing still, but it's a beast in itself.\n\nMIKE: Take some time to talk to me for a few minutes. I'll give you some ideas that I think will help. Probably a good thing for a future podcast. That's a tool worth talking about. This was great. I loved hearing everybody's stories. I hope that it's inspiring to our listeners. Thank you for listening, and we'll see you next time.","content_html":"Today we talking about what inspired us to get into software development and become developers.
\n\nTranscript:
\n\nMIKE: Welcome to another episode of the Acima Development Podcast. I'm Mike. I will be hosting today. We've got a panel here today of Afton, Diane, Eddy, Ramses, and Tad with me. And today, we're going to be talking about what inspired us to get into software development, what inspired us to become a developer. I have the luxury as the host [laughs] of being able to share my story first.
\n\nI've been thinking about, as we've been preparing for this, what I might share, and I'm going to start back in childhood. And I may have shared this before, but I will share it again. When I was in elementary school, I don't remember quite what grade it was, like, second or third grade; our school got a computer. And this was a long time ago [laughs], back where the school would have a computer. And that was a big deal. We didn't have one at home. I'd seen computers at places of work but had not had a chance to play with one.
\n\nAnd our school got a computer, and I got to use Logo, which is a language, if anybody has used, that lets you move a little turtle around the screen and draw lines behind it. And I thought it was just the coolest thing to be able to talk to this computer and have it do something. And what I particularly remember is that there was some sort of key sequence or something you could do to go to a back channel where it wouldn't show you the turtle, but you could write a little script. And then you could execute the script, and you could watch the turtle do a few things. I remember you could make spirals, and I thought that was the coolest thing ever.
\n\nAnd you'd have the turtle go forward and then turn and then go forward again if you did it with the right angles. You could do it in a loop. There was some sort of looping construct. I don't remember what the looping constructs were. But I just thought it was like the coolest thing, and I wished I could do it all the time.
\n\nThere was another kid at the school who was really good at doing this. I remember he used BASIC. And he inspired me. That's kind of a tragic story because he went on to be criminally prosecuted for a murder related to a drug transaction. But maybe that kind of pushed me away from it for a while. But there were other people around me who got computers, and kind of inspired me as well.
\n\nLater when I was a few years older in junior high, my family got a computer which was, wow, it's a big deal. [laughs] And it was, I think, an i386. It came with a book for GW-BASIC, so it comes with BASIC, which is a simple programming language. And there was a manual along with guides on how to do a bunch of things. And I read through the manual cover to cover and did some of these example programs, and I had a great time. I would spend hours working on that.
\n\nI had this from my childhood, and then I didn't really work on it for a few years. Again, as I mentioned, [laughs] my friend who had some interest in it went down a dark path. I kind of got away from it. And then, when I was in college, I was originally pursuing botany and genetics, molecular biology, and I got kind of scared off by that field because I didn't feel very comfortable with the lack of ethical constraints, what was going on. I'm kind of glad I got out of that industry because there are some ethical conundrums there that are challenging, but they are in every field, so I don't think it's escapable.
\n\nBut then, in college, I was looking for what I wanted to do instead, and I took a coding class kind of on a whim. And I was like, oh, that's right, I loved this. [laughs] And I thought I could make a career out of this, and this would be a great career. And I never really looked back. I've been doing it ever since. And I've been coding full-time for over 20 years now. I've really enjoyed it.
\n\nThere is a joy and a thrill in being able to solve problems and get this computer to do something productive and useful that is hard to explain to people who haven't done it. If you haven't done it, I recommend you try. Have that experience for yourself. That's kind of my background, what inspired me to become a developer. I could talk about more, but that's kind of the big picture of my progress. What are your stories?
\n\nTAD: I started out back in the early '80s. Texas Instruments decided that they wanted to get into this new home PC thing. And they came out with a computer called the TI-99/4A, and my parents got one for our family for Christmas. And it was just fascinating to me. There were these clunky things where everything was kind of contained in this keyboard that you plugged into your TV and that you use as your monitor. And then you got games or other things that came on cartridges that you'd slide in the slot in the front. And it booted up, and you'd play the games and do whatever.
\n\nBut when you first started it up, it gave you an option screen; number one was basically programming BASIC, and number two was the option to boot up whatever cartridge you had put in. And for a while, I just kind of ignored option one. But then I was kind of like, well, what is this thing, you know, programming BASIC? [laughs] So I started choosing option one, and I'm like, oh, I could do line numbers in a loop because it came with a little manual you could read and figure it out.
\n\nAnd so I started out with the really simple stuff like the guess the number games or doing a loop like you are awesome and just prints it over and over again, whatever. And I did that for a while. Probably the height was I came up with a song, and I programmed the computer to play the song in a very electronic way. And I recorded it, and I submitted that for the Reflections contest. And everyone thought that was so novel. I made it up to region or something. And I'm like, yeah, computers and computer music and stuff.
\n\nBut I think I kind of followed your path, Mike, where that was really cool when I was younger, and then I kind of fell away from it because there were other things to do. And I didn't get into computers again until probably high school because I had a lot of friends in the computer club. My computer science teacher in high school was kind of a visionary, I think, because she...this was back in '93, '92. And she was connected to this...the computers at the college were connected to this new thing called the World Wide Web.
\n\nThis new thing like FTP [laughs] would be able to connect to that, and from there, we were connecting to the world, and this was back in '92. And we're like, whoa, what is this? And she was doing things like video conferencing. And it was like grainy, little black and white things. And we used HyperCard to control the LaserDisc player that she had. And it was pretty crazy. And that, I think, really reignited my interest in computers and computer science. And I was the vice president of the computer science club and getting into that.
\n\nBut my real passion in high school was chemistry. And I got like a five on the AP chemistry test. I was just doing awesome things with chemistry. I got a scholarship in chemistry and got into the University of Utah. And I was sure that that was my path; that was what I was going to do. But once I got into college, I realized I really enjoyed learning chemistry. And I really enjoyed the fun things like blowing things up or making soap or whatever little projects that you do. But I really didn't enjoy the long-term labs. I didn't enjoy the reports. I didn't enjoy sticking samples in machines and writing reports, that kind of thing.
\n\nBut I had all this chemistry, and I'm like, well, I don't want to lose the credit for that. Maybe if I switch over to something kind of parallel, I'll find my passion; I'll find what I want to do. So I switched over to materials engineering and was doing that. I wasn't loving it, but they promised us the third quarter is when they get into the real stuff, like the real stuff that you're going to learn about and do in materials engineering.
\n\nSo I stuck it out. I took the third-quarter class, and I hated it. I don't know, like, it was so boring to me because a lot of it was stick a sample in the machine, collect the data, write a 20-page report, literally 20 pages. And we were doing that every week. I'm like, ah, this isn't what I want to do. And I kind of got bummed out and decided to just drop out for a while because my reasoning was, why pay money to do something that I don't enjoy?
\n\nAnd so I took a bit of time off to just go home, get a job, figure it out. And it was interesting because I was out mowing my parents' front yard, and one of my old high school teachers came by, and she actually mentioned she's like, "Oh, I thought you were going to go into computer science. That was what you really seemed to be passionate about back when I was teaching that stuff." And I'm like, oh yeah, [laughs] I kind of was. And I had been doing a computer science minor the whole time.
\n\nAnd it just dawned on me; I'm like, those were the classes I really liked. Those are the things I really enjoyed doing. Why don't I just make up my mind on my major and go back to college? And being able to take your thoughts and make them into something and just be able to create anything you want, just the variety and the things you get to learn and the things you get to do with computers turned out to really appeal to me. And so that's how I kind of switched paths. I went back, got my CS degree, and I've been doing this for, gosh, somewhere about 16, 17 years, I think.
\n\nMIKE: Nice.
\n\nAFTON: I'm really eager to kind of talk about my story now because it's quite a different path. I grew up with zero interest in computer [laughs] programs and, in fact, being very intimidated when I had to interact with computers. Occasionally, I was shown how to play a game on there. And in school, I knew how to get to my Word documents to type my papers, but that was it. I did not do any more than was absolutely necessary involving computers. And I knew nothing about programming and just had very limited exposure to anything of that sort.
\n\nAnd my passions were nature and dancing, and I was highly involved in music and theater. And I ended up...in school, I started out as a math major because I really had always loved math, and then switched to music and got my degree in music. And my favorite part about my music experience was the music theory, which was very mathematical, very exacting. I loved learning about how notes related to each other and the different sounds you can make by tweaking. And if you followed certain patterns and certain rules, you could create something beautiful. I loved that exactness and learning those little tools and the rules for creating something.
\n\nAfter I graduated, I started a family and stayed at home raising and homeschooling my kids and almost never interacted with computers except online, whatever. But there came a time where I needed to start a career. And I was looking for a way to gain some independence and support myself and something that would give me some flexibility because I had young kids and wanted something that could work with my life in some way. I had some people really close to me who had gone through QA and were then web developers and software developers, and them knowing me, they were like, "You should try development, writing code. I think you would like it. I think it's up your alley."
\n\nAnd I really resisted that idea. I was just like, no way. Computers, programs, I mean, I know nothing about that world. And so for at least two years, I was just like, no, that's not my thing. And I thought about going back to school to become a dance teacher or maybe going back to school to pursue biology more, which had been my minor.
\n\nBut when it came down to it, I was thinking about, well, if I go back to school and invest a ton of money and a ton of time, that's one path to finding a way into a career. Or is there something I could do from home while I'm homeschooling my kids that I have time and maybe not as much money resources to pour into? Is there something I could do that I can give it time and less money? [laughs]
\n\nAnd so finally, in 2015, when I was in my mid-30s, I decided to find a free coding course online and take my first coding course. It was on Codecademy, and I took HTML and CSS. And it was so much fun seeing how I could type something, and then it did something on this screen visually, and I could play with it. It blew my mind how much fun it was. [laughs]
\n\nOver a couple of years, I dabbled with some various basically free courses that I could find online. There were so many resources. It was really incredible what I was able to find and do. And also my local library...I went to the library, and I browsed the software books, and I found one on Ruby on Rails by Head First. And so I checked out that book, and I went through it like I was doing school like a textbook, and I built my first Ruby (It wasn't Ruby on Rails; it was just Ruby.) application.
\n\nSo about two, two and a half years in, I put my children into public school so that I could spend full-time basically schooling myself and learning how to write code and solve problems. I just thought it was really intriguing and super fun to have a problem I had to solve and to just have to chase it down, and search, and Google, and read documentation, and try to figure out how to build an app. And I found the problem-solving and the investigation just really thrilling. And it was just like a treasure hunt every day with a new problem I had to solve. [laughs]
\n\nSo I guess I just found a lot of joy and intrigue in the problem-solving and thought; I do love this, and I seem to have skills that help me be successful. I'm persistent, and I love the nitty-gritty details of everything and finding out what I do can impact various things, and just really enjoyed it. So I jumped into the world as a summer intern for my first job, and that's still what I'm doing.
\n\nSo largely, my motivators were finding something I could do that could help me to gain some independence financially. It's something that can support life, a well-paying job, and something that was intriguing and interesting that I could love. It was a surprise to me. And I was encouraged to try out this world, but it surprised me. And it's been a fun journey. I'm still learning every day what skills I can bring and learning as I go.
\n\nMIKE: There was something I was noticing, Afton. You said that your background was a lot different. But you notice that nobody who's spoken thus far started their career saying, "Yes, I'm going to go and build software." [laughs]
\n\nAFTON: [laughs]
\n\nMIKE: None of us. We started in something else, and for whatever reason, that wasn't the end of our journey. And then we went to coding either for the first time or went back to it and, like, wait, this is great. That moment of discovery when you can work with the computer and it does things that you say sparked something. It's interesting to me how much commonality there is between all of our stories so far. The specific year we happened to start, I'm going to argue, is not that relevant, [laughs] rather that we weren't there, and then we got into it. That's cool.
\n\nEDDY: I'd be lying if I didn't admit that a huge contributing factor for choosing this was the salary ceiling is much higher than most after a few years. That was a huge factor. I remember I took a small typing class in junior high which, by the way, in hindsight, [laughs] has paid huge dividends with programming, like, holy cow. I can be much more efficient typing what I want and stuff. So I don't know if knowing how to type is essential or if people require that as a skill, but it was fantastic.
\n\nBut that class that I took, the teacher implemented a small HTML course to kind of fill in time gaps throughout our typing sessions. And we were able to change the color of text on the screen from black to red. I still remember I was like, what the heck? I got filled with joy, and I was like, dang, I was able to tell the browser what to do with a few lines of code. I was like, this is insane. I remember feeling super joyful in that, and I was like, dang, this is really cool.
\n\nBut it ultimately was a hobby for a while, and even after high school, I didn't have much direction for what I wanted my career to be. And then, it wasn't until the pandemic hit pretty hard in 2020 and I realized that I have a small family that relies on my income. And I was mortified that I was going to lose my job; fortunately, I didn't. But that was a huge epiphany for me that I needed a specific skill that will prove to be more flexible and provide better job security.
\n\nThen I remembered that I found coding pretty fun and entertaining. So I spent most of my time at my job at the time during lunch...I boot up my computer, and I just downloaded an IDE, and I just began self-learning with videos and stuff. And I delved into the React framework I remember. I looked up what are the most high-demand languages, and React was pretty popular. And I'm like, sure, I'll pick it up. There were even times where I was on the clock, and I whipped out my phone and I watched videos. And I hit a point where I dreaded the job that I had. And I really decided to take it seriously.
\n\nI remember I tried going back to college. But first of all, I'm not very academic, and I ended up dropping out after the first semester. But I remember I spoke with someone there, and they told me, "Yo, you don't need a college degree. Going the academic route isn't really for everyone. You don't necessarily need to." And I was like, wait, you can be a developer without a degree? That's insane. That made me wonder, like, what?
\n\nBut I joined Reddit forums and a lot of blogs and watched a lot of videos. And a lot of people were like, "Oh yeah, you can totally penetrate the industry," so that's what I did. And after three months of really, really being heads down with learning and being motivated, I shot a Hail Mary, and I applied at Acima for the QA position. Matt Rampey was the team lead at the time, so if he happens to hear this, hello. And I guess he really liked the motivation and hunger to really penetrate the industry and really aspire to self-learn.
\n\nSo now I've been employed for about a year and a half. And I've been striving to push myself to get out of my comfort zone and, pick up backlog tickets, reach out to developers. [laughs] I was like, hey, like, help me out. And I attribute a lot of my success thus far because I've paired with most of you with tickets, and I attribute a lot of my success to you guys because of all the patience that you've demonstrated up till now.
\n\nMIKE: That's great. [laughs] And we love having you working with us too. I'm going to point out to our listeners again the commonality here. [laughs] Notice that nobody really knew they were going to do this right at the beginning, and then they discovered it and noticed how much joy it brought them. Thanks, Eddy.
\n\nDIANE: I guess what sparked my interest and my curiosity was a class I took in high school, I believe. It was computer science one. And I took it because it was just a class to fill in. And the teacher introduced us to Scratch just to make your own little game on it, and we did that for the whole entire year. We just mainly focused on that. And if I'm being honest, at first, it didn't really catch my attention or anything like that. I wasn't very interested.
\n\nAnd so as the course went on, it was really fascinating and really cool to create your own games, seeing how all the motions and the integrations that they had within Scratch. You could just make the game on there. After taking that class, I believe it was my senior year; I totally forgot about it, scratched it out, literally. [chuckles] And I went to school for marketing initially. And I went for about three years, so I almost graduated, but then I realized it wasn't something I wanted to do.
\n\nSo I took a long break and I started working at Acima as a processing agent. And after being in the processing department for a bit, I decided I wanted to go to a coding bootcamp. And from that, I got inspiration from someone who I look up to, and she's more of a big sister to me. So she went to a coding bootcamp, and seeing her go through that and excel in that coding bootcamp and excel in her career after really inspired me to go.
\n\nSo I went through the coding bootcamp and actually reached out to Afton after I had finished the coding bootcamp. And we did some pairing after work hours, and it was really great. And I was able to learn a lot. And then she let me know that there was a QA position opening up, so I decided to take the chance and reached out to Ryan, who then interviewed me. And that's where I am now. I didn't think I was going to really excel in the career, but yeah, here we are.
\n\nMIKE: One thing I noticed is you mentioned there was somebody who was like a big sister to you who inspired you to go forward. Afton, you've mentioned that you had a couple of friends who said, "Hey, you should try this." Tad, you said you had a teacher, a former [laughs] teacher who remembered you and inspired you, and I probably have overlooked. There's a pattern here of people being inspired by somebody. Am I picking up on this accurately that there was a mentor who made a real difference to you?
\n\nDIANE: Yeah, she actually also worked here for a bit. So she actually got me the processing role and then pushed me to pair with Afton. [laughs] So yeah, she is the one who really pushed me to do the stuff that I am right now.
\n\nMIKE: Oh, that's great. I know I've worked with a number of people who are just starting their careers. I'm thinking of somebody...I don't want to name somebody who can't be here and speak for themselves, but there was somebody who was just working at a front desk. I say just working, but it was kind of a demanding position because she was the executive assistant and did all of the [laughs] coordination of the company, but she was not doing a technical role.
\n\nAnd she came and joined me and some other developers for a mentoring session during lunches, kind of like what Eddy was saying. She just came and joined us during lunches, and we took our time during lunch to start teaching her what we were doing and let her pair with us and review our code. And she ended up some years later working here at Acima and has gone on, and she's leading a department at another company. Seeing that is immensely gratifying as a mentor.
\n\nActually, one of my really good friends in high school went into civil engineering. And he had kind of gotten stagnant in his career and asked if I would take a few days and teach him and some of his co-workers a class on coding and kind of get them started into it, not as much as a bootcamp. Imagine a really compressed bootcamp; learn how to code in a week kind of thing. It's not enough to completely launch your career but enough to spark their interest. And my friend is now working at a software company and has been for a number of years. That changed his career.
\n\nJust a couple of examples of the little things you can do, just taking some time during lunch or taking a week to teach a class ended up changing the trajectory of somebody else's career. So we're talking a lot now about our time as the mentees, the people who were inspired. But the work that we do, even if it's just a little bit to help somebody else in their career, can make a huge difference.
\n\nTAD: I think it's interesting. I had to write a paper in college, and so I chose to write about why and how people get into development and things like that, and often, it's two things, someone has to have access to a computer and be able to interact in some way that sparks their interest. And then they also need someone to mentor them, or push them, or notice them, and put them on the path. Those are two things that people usually point to as what set them on the path.
\n\nAs you were talking, I was thinking I know this person who used to be an accountant, so they used Excel all the time. And they're like, "Oh, man, I wish I could make this easier on myself." And so they started learning formulas, and they started learning macros, and they started learning these things. And they're like, "Oh, man, [laughs] I like this better than accounting. How do I do this?" And happened to have lots of friends that were all devs, and they were like, "Oh, you probably would like this." And suddenly, they're a developer now.
\n\nMIKE: That's really cool.
\n\nRAMSES: Funny enough, Tad, that's not exactly how I started, but before being a full-time developer and before I was in technical support, I was in more of an auditing position where I used spreadsheets quite a bit. And filling out spreadsheets manually it's really, really tedious, or processing information on a spreadsheet can be really tedious. So I spent a lot of time researching and learning how to automate some of the really repetitive tasks that I was doing, and that kind of got me interested.
\n\nI've always been kind of around computers because I was first exposed to computers when I was in elementary school, probably. And I played a lot of games, video games growing up. So I was always solving puzzles or doing quests in games. It sparked my interest in problem-solving. But once I joined a technical support role, I think that kind of drove my interest into development quite a bit because in my technical support role here at Acima, I would often do QA tasks, or I was starting to do more development work because I was always just around code.
\n\nSo it was a good opportunity for me to just learn what was happening. And I was really curious in obtaining that knowledge, and I still am today. I spend a lot of my time learning new things and trying to be more efficient, trying to just push myself. That's what inspires me today is just getting better.
\n\nMIKE: That's cool that you were in Excel also. I remember thinking it was cool to write formulas in a spreadsheet, [laughs] the spreadsheet software I was using. This was before there was...so this was...a little hard to think about this way, but there used to be command-line spreadsheets, terminal-type spreadsheets. It would fill your screen, but it was very different than the graphical environment we have today, but it worked just the same. [laughs] They'd have keyboard shortcuts that you'd tend to use more rather than using your mouse, but otherwise, the experience really hasn't changed that much. [laughs] And I loved that. I really liked writing the formulas.
\n\nI also remember doing some computer-aided drafting in AutoCAD, and there's some scripting you can do there as well that I didn't do a lot of, but I guess it was quite sophisticated. And it was also interesting and fun. I guess I didn't really perceive that as coding. I think a lot of people have that same experience.
\n\nWe thought, oh yeah, coding, that's just kind of something you do for fun. It's kind of an enjoyable part of the job. This isn't something you can make a career of. It turns out, yes, it is, and it's in high demand. We need people [laughs] who can do that. Anybody else have those experiences doing bits of code in places that you wouldn't necessarily think of as coding at the time?
\n\nTAD: I think it's interesting. I believe this is true that pretty much all Adobe products now let you do script stuff with JavaScript. And I know some designers who started off just, oh, gosh, I need to automate these tasks. These things I'm doing in Photoshop or Illustrator, whatever, are really repetitive. [laughs] I wish I could automate this stuff, or I wish I could figure out a way to save this file in three different formats so I can give it to whoever and didn't have to do that manually.
\n\nAnd they don't necessarily become full-on developers, but they start writing their own scripts. And they start sharing their scripts or downloading scripts that other people have written and modifying them and stuff. And so it's interesting to me to see that even things that aren't full on I'm a developer, they are...like when I'm helping a designer debug his script, and he's like figuring things out, and like, "Oh, I got the variable wrong," and all the tweaking and stuff. I'm just like, oh my gosh, this is ubiquitous. This stuff is everywhere, and a lot of people are doing a bit of development as part of their jobs, even though they're not technically full-on developing.
\n\nAFTON: This kind of reminded me because I was thinking, I don't think I ever did anything like that. But then I remembered before I ever took my first coding class, I had a blog that I spent a lot of time on, and it was around having premature babies because two of my children were born prematurely. So I had started a blog that I spent a lot of time writing for, and I had some management UI that I could tweak things, and schedule, and make changes, and change colors or fonts. There was a little bit of customization I could do.
\n\nBut my husband at the time was a web developer, and he would be like, "Oh, look, you can go to this place, and you can see the code that's producing [laughs] your page. And you can actually mess with it." And so there were a few things I wanted to change that he got in and changed. And I remember being really excited that that capability was right there. But it was like a foreign world, and I didn't know how to interact with it. But now that you're mentioning it, that did spark this intriguing like, oh, that's cool. So there was a little bit of that for me.
\n\nEDDY: I have a generic question for everyone here. Knowing what you know now, what personality traits should a person have in order for you to recommend them to programming? Like, oh, yeah, you're this kind of person. I think you'd be a really good fit for programming.
\n\nRAMSES: Curious, probably.
\n\nMIKE: I was thinking the exact same way, curiosity, and tenacity.
\n\nRAMSES: Yeah, that's a good one.
\n\nAFTON: I was going to say they like paying attention to details or organizing. [laughs] Those are skills I find helpful. And also don't easily get frustrated; someone who's willing to push through, even when something is difficult, willing to keep digging and persisting on a problem until they find a way to make things work.
\n\nMIKE: Absolutely. That's what I was trying to aim for with tenacity.
\n\nAFTON: Okay. [laughs]
\n\nMIKE: Maybe it didn't land. [laughs] I couldn't agree with you more. I've said to people before that software development is mostly about frustration management. And I'm really not trying to be snarky. I mean that fully because you're solving problems. And frustration, by definition, is getting blocked when you're trying to solve a problem or you're trying to do something. If you're trying to work through and solve some things, of course, you're going to run into roadblocks. If there weren't any roadblocks, the problem would already be solved, and you wouldn't be solving it in the first place.
\n\nSo being willing to keep digging, even when it's frustrating, you know, manage the frustration and say, "Yep. I'm frustrated, and I'm going to keep looking because I'm frustrated," rather than being dissuaded, and that also connects to the curiosity that Ramses was saying. If you feed that curiosity, that gives you the emotional strength to keep digging, even though you're frustrated. Is that consistent with the experience of you all?
\n\nTAD: Yeah, I'd maybe even add creativity, maybe orthogonal thinking, meaning you have to generate like a whole bunch of different possible ways that you solve a problem. And then you try one, and you're like, oh man, that's not going to work. Okay, I've got to back up and take a different approach at this. Oh, that solution doesn't work either. And being able to think of a few different ways that you could solve the problem, which is really hard to get, and they don't really teach in school very well, I think.
\n\nIt's funny to me that when I talk to people, they'll make excuses like, oh, I wasn't really that great at math in high school, or something like that. And the general perception of what you need to have to be a developer is different than what I think you actually need. I've heard a lot of excuses. [laughs] Like, wait, no, if you want to run an atom collider, then you probably do need to be really good at math. You have to have a really deep physics background. But if you want to tweak your blog, do you really need that math? Probably not, right? [laughs]
\n\nEDDY: I feel like there's a stigma from everyone from outside the scope where they're like, "Oh, every programmer and computer scientist needs to have huge mathematical comprehension." And like, [laughs] it could just be that I've only picked up semi-easy tickets, but to this day, I have yet to really hit a block because I'm not able to understand a math formula, and that's something. It could be different for senior developers.
\n\nMIKE: Has anybody here read a "Mathematician's Lament," also sometimes called "Lockhart's Lament?" It's written by a professional mathematician, and his lament is that mathematics teaching drives mathematics out of everybody. [laughs] And I laugh a little bit, but it's a tragic take on how that curiosity and creativity that you're talking about, Tad, ends up getting lost from rote teaching and learning to memorize the ways of doing things.
\n\nBut what professional mathematicians do is nothing like memorizing formulas; rather, it is exactly what you described of coming up with a bunch of different possible ideas and creatively trying to find other ways to approach a problem and then trying out and see if they work, which is play. And play has evolutionary purpose. It's what we do to learn about the world, but it's fun. The fact that it's useful doesn't change the fact that it is fun, [laughs] and it is rewarding, that it is a joyful thing to do.
\nThis is about mathematics. But if we treat anything, be it music, or writing, you name it, any human endeavor, if we make it something that's about memorization and regurgitation, we take that joy away rather than letting it be play, and computer science or mathematics, in general, is no different. A lot of people who think that they are not a math person really don't like being bored and genuinely have the ability to find creativity and pleasure in building things and just haven't been given the opportunity. I'd like to throw that out there.
AFTON: Mike, you mentioned learning through playing, and that reminded me that Ramses had mentioned that he loves learning every day and continuing to learn. I was thinking of that as another big drive to go into this field was that it would require constant and continual learning forever, and the challenges would always be new. And there would be new tools you could learn about to implement. And so I imagine this would not be a job that I could get bored at but that it would be constantly challenging and rewarding and always push lifelong learning, which really, really, I loved that idea. That was something I wanted.
\n\nMIKE: Yeah, it's true, isn't it? Not only is it something that will happen, but it has to happen. You can't have a career [laughs] in this field without the daily learning.
\n\nTAD: And it's not learning, just development. I've worked in the oil and gas industry. I've written software for the veterinary industry. I've worked at a marketing agency. So I've also had to learn those domains. I know a lot about how veterinarians track their medications and treat their animals and things like that. And I know a lot about a bunch of regulations about the oil and gas industry now and how they figure out mapping stuff. And it's everything, like, software is everywhere. And so you're learning development, but you're learning a little bit of possibly anything else.
\n\nMIKE: Maybe to take that a little bit further, none of us started a career in software, but we ended up there. And there's, I'm sure, need in whatever industry you're in, if you're in retail, if you're in oil and gas [laughs] industry, if you're a barista. You shouldn't necessarily think that software is somewhere else. There's probably a surprising amount of need for software right where you're at. And you might be able to pivot more easily than you think if you're not a software developer yet. Take that as a challenge. We need more developers. You shouldn't feel daunted by the fact that you haven't gotten there yet.
\n\nEDDY: Mike, I just want to point out that when you and Afton mentioned managing anger or pushing past those blockers, you know, frustration, I've hit that point with RSpec. I just want to say that. [laughs] But I'm pushing still, but it's a beast in itself.
\n\nMIKE: Take some time to talk to me for a few minutes. I'll give you some ideas that I think will help. Probably a good thing for a future podcast. That's a tool worth talking about. This was great. I loved hearing everybody's stories. I hope that it's inspiring to our listeners. Thank you for listening, and we'll see you next time.
","summary":"","date_published":"2023-05-24T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/6bae38e6-0441-4f13-ba41-a600023d33ec.mp3","mime_type":"audio/mpeg","size_in_bytes":43431135,"duration_in_seconds":2331}]},{"id":"fabfacdc-201e-45b5-bc5b-c5aae5c22f61","title":"Episode 17: How Do You Break Up a Product Request Into Work (Part 2)","url":"https://acima-development.fireside.fm/17","content_text":"Here's part two of how to break down product work! In the last episode, we talked about how to break down product work, and talked about the 'why' and the 'when'. Today, we tackle the 'how'!\n\nTranscript:\n\nDAVID: Welcome back to the Acima Development Podcast. We are doing the part two of how to break down product work. Last episode, we were going to talk about how to break down product work, and we ended up talking about why and when, and didn't get into the how very much. I'm your host, David Brady. Today we're joined on the podcast by Kyle Archer, Ramses Bateman, and Eddy Lopez. And it's exciting to see you guys. Let's jump in. So how do you break down product work?\n\nEDDY: You know, Dave, this has been lingering for me in my back pocket since last week. But I was getting over an illness, that I wasn't very productive in our conversation. As you may know, I'm an aspiring developer. Within the next few months or so, I'm hoping to actively be getting paid to develop and write code. \n\nDAVID: Nice.\n\nEDDY: One of the things though...and I see this often, specifically from a QA standpoint, where a company will ask you, they're like, \"Hey, we need this huge and large and pretty feature. Oh, and you got X amount of time to get it done. You look at epic, you look at the subtasks, and it's like 30. [laughs] And now it can seem a bit daunting to look at all the subtasks that you need to tackle. What's your approach when you feel overwhelmed when you look at how big a project is sometimes?\n\nDAVID: I do not want these podcasts to turn into me holding court with you guys because I'm honestly not that smart. Let me kick that over to Kyle and Ramses. How would you guys break that down? Somebody comes in and says, \"Hey, we've got this big product, and you're in charge of it. You're the lead developer.\" Obviously, you've got to break it down somehow because you can't work on a 30-point story. How do you break that down into something smaller?\n\nRAMSES: I think for me, it would kind of depend on what the epic is and then looking at the stories and seeing if we could subdivide the stories if it is appropriate to put them in thirds, halves, whatever it was. And kind of give some pushback and say, \"This is great. This is a lot of work. We don't have enough manpower to get this done,\" and express what we could accomplish in that given timeframe.\n\nDAVID: Yeah, I like that. In the last episode, [chuckles] I came up with a horrible metaphor. And it was because I was in the wrong aisle of the bakery. In my head, I was thinking it's like a loaf of bread. You've got to start at one end of the loaf and get to the other end of the loaf. And this was a terrible metaphor. And I apologize to everybody [laughs] who waited through that last line. Turn the loaf of bread sideways or on its end and imagine it's a layer cake. That's the metaphor that I should have gone for in the last episode. \n\nFor me, when I need to break product work down, especially if it's a big thing, you know, every business, not every business, but a lot of a lot of businesses, there's a central object that is like a document or a record of something. And it is the central artifact of business that your company works with, so with Acima, it's a lease. At CoverMyMeds, when I was working there, it was a prior authorization request, like somebody wanted to get a drug approved. These documents are at the center of everything.\n\nNew customers coming in they get attached to this document, or they're applying to get into one of these documents. And then they get approved, and they're now in this document. And then they're transacting the business of working through the contract of that document, and all the way until it's all paid off. And then it goes into history. And so there are all these events.\n\nLet's say you're at a business, and you've got some central document like this. Let's say you're at a legal firm, and it's a contract. We have people coming in, and they want to get a contract. They need to create the contract, join, da da da. Okay, that's fine. And you got all these servers, and they're running software, and they're prosecuting the business. Prosecuting is a terrible pun. Sorry, it was not intentional, but I am proud of it. Transacting all the business of processing this contract, right? \n\nProduct comes to you and says, \"Hey, we need a separate logging service. Anytime something happens to a contract, we need you to go to the master contract server and pull down the main copy, like, the original copy of the contract. We need you to amend the event, attach the event to it, and then store it back into the system. And we need you to do it in a separate service.\" And so you're going to talk to the contract server. You're going to get this thing. You're going to add these events to it, and then you're going to push these events back up into some other service to record them. This is pretty straightforward. \n\nAnybody that's worked in kind of a service-oriented architecture has been given product work where it's, hey, talk to this server, and that server, and that server, and do something that those servers can't do on their own because they can't see each other. They don't know what the other server knows. So your little job here is to talk to all three to have the knowledge that comes from all three of those things and do something with it. This is pretty straightforward. \n\nThe metaphor of a layer cake for me comes about because instead of just looking at the top layer of the cake and saying I'm going to build the top layer of the cake, the very top layer of the cake, is we're going to build the thing that downloads the contract from the main contract server. And we're going to build that piece of software, and we're going to build it complete. We're going to get every single field. We're going to get every translation bit. We're going to decode the thing. It's encrypted, so we're going to put an encryption key. And all of this is put on there.\n\nBut you don't go to the second layer of the cake until the top layer is completely finished. And so you end up with building this thing that can handle everything about understanding this contract that you've downloaded and how to get it from this main server. But the things that you need underneath, just one layer down, don't exist yet. And so you don't have a cake. You don't have anything that you can serve on a plate and eat. \n\nThis is how we did software in the '90s. You hear people talking about waterfall where you design everything, then you write it, then you debug it. You don't write code while you're debugging that kind of thing. The layer cake idea is if you want to take a piece of cake and serve it, you want to serve up a slice of cake as quickly as possible. And that means you've got to write just enough of that top layer to connect to the next layer down, and you got to write just enough of that to connect. \n\nSo you might sit down and go, okay, I'm going to connect to the main contract server, and I'm going to download the contract. The contract is encrypted. I don't care. I just want bits off of that server. If I can prove that those bits did not come from my server and they came from that server, that's good enough. So we pull this thing down. \n\nThere's some piece of the contract that's going to be unencrypted, like the ID number or something like this. If I can get the ID off of this thing, great, I'm in business. We go down to the next layer. The next layer is something that's going to decode or actually just parse the stupid document. So we're not even going to worry about the encryption piece. We're just going to decode can we find the ID field in this document? And then we go down to the next layer, and the next layer, and the next layer. \n\nAnd eventually, you've got this super, super thin, tiny little application. It's not even an MVP, minimum viable product. It's so much less than an MVP, but it goes full stack from the top to the end, from one end of the cake to the other, or from the top of the cake to the bottom. It connects to the main server. It downloads the contract. It parses out the ID field. \n\nIt figures out, oh, I want to attach an event to this. It gins up an event, which just has an ID and a created at, like, there's no event information. It's just the minimum. What's the smallest event that we can create? It's just got an ID and a timestamp. That's an event that exists but has no other useful data. And then, we upload that event to another server. \n\nAnd for this minimal piece, we're just going to connect to the event server. We're not even going to shove up the event that we created. We're just going to shove up an event with an ID of 42 and a created timestamp of now, and that's it. That's your entire slice. And I've got a really, really dangerous question for you guys, which is, why is that insanely useful? Or, if you prefer, tell me what goes wrong in building that? What problems are you going to have to solve in order to get that entire piece of cake put together? \n\nI worry that I've told the story carefully enough that you guys might feel like there's one right answer or one wrong answer, and there isn't. Have any of you guys done software where you take this vertical slice like this, and if so, was there something really surprising that wasn't in your master ticket, you know, the epic story that you have to break down that you found out by building this thing?\n\nKYLE: I think what I've seen when I've kind of approached it like this is it can be both beneficial and, I guess...harmful is not the word. But I'm trying to think of the word I'm wanting here, but detrimental, there we go. In the sense that when I'm doing a vertical like that, I see stories that are both missing and are both unneeded as I'm going along that route. So I think that's kind of the danger of doing it that way for me.\n\nDAVID: Talk to me more about this because I'm literally sitting here bouncing up and down on my chair, going it's not the defect. This is the feature of this approach. Talk to me about running into these missing and needed stories. What does that look like? How does that feel? And how do you deal with it?\n\nKYLE: I'm trying to think of how to respond to that. It's just...because you're going along and you just realize that...I'm trying to think of an example right now. But it's not going to quite work the way that you're wanting to. Maybe there's a faster protocol that you can use, so that's adding something, right?\n\nDAVID: Mm-hmm.\n\nKYLE: Or maybe you're realizing that you can't transfer as big of a file as you wanted, you know, there's a technical hurdle.\n\nDAVID: Bingo.\n\nKYLE: There's a legal hurdle. There's a security hurdle, you know, different things can get in the way. But as you're going along, you're learning, and you're also realizing what would make the feature or the system better so you can see where adding a story would be beneficial.\n\nDAVID: That is exactly, exactly it. When we look at these layers in our head, or we think about these layers, we often think about, okay, inside this layer, I got to do this, do that, do that. And then you go to the next layer, and you think about what's going to be in that. And you don't stop to think about, wait a minute, how is this layer going to talk to the next layer or the one above? What are the implications of this? \n\nAnd when you take a slice vertically through the entire problem space, those things jump right out at you. Right off the tip of the bat, you find out that, oh, you can't connect to the main contract server without a username, password, and encryption key. You don't have one of those. You've got to go to IT and get an encryption key. Like, oh, we don't have a story for that. But we've got this other story buried way, way down off the side. That's the entire communication between the contract server, and your service, and the service, and the eventing service, all have to be secured with encryption. Okay, fine. \n\nAnd we've got this big sub-epic kind of an epic of itself which is to dig into the encryption and figure out how we're going to encrypt all these packets back and forth. And as you're struggling with this, you go to lunch with somebody from IT. And you're telling them about the headache that you're having with this.\n\nAnd the person from IT looks at you, kind of cocks their head a little bit, and goes, \"Why are you doing that? You know that this server is on a backplane all by itself. It's inside a LAN. I mean, literally, there's a physical wire dedicated to the communication between this server and that server. And everything that goes on that wire is encrypted at the hardware level, like, we built it that way. We built it that way for you. Why aren't you using this?\" \n\nAnd you realize, oh, the application encryption it's done. This entire story is wasted heat for us trying to encrypt packets that are going on an encrypted transport protocol. I, four or five years ago, worked on...and don't quote me on this, guys, because I'm not a security guy. [chuckles] But we had a whole bunch of services that needed to talk to each other, and we needed encryption over them. \n\nAnd then we stepped back and realized we're doing all of this over HTTPS. And we're like, wait a minute, does this secure everything that we need? And we went back and like, why do we want this encryption? And we're like, somebody eavesdropping here. Oh, yeah, that's hardened, that's encrypted. Anybody eavesdropping on that wire is going to get encrypted packets, to begin with. It doesn't mean you're safe. You never think that with encryption or security. But to whatever degree of safe enough, we were already done, and we were just wasting time. \n\nThe opposite end is you come across stories that don't exist that you need. You need the encryption key to talk to the server, or you need an account on that server to download the contract. Or you run into a fun thing where your service talks to the main contract server. How does it know which contract to update? Well, it goes to the database, and it looks for things that have changed; okay, that's fine. \n\nBut unbeknownst to us, the eventing server, every time it gets a new event, it updates the timestamp on the contract to say you've been updated. Now what's going to happen the first time you try to tag an update and attach it to a contract? I'm grinning my evil grin. What's going to go wrong here?\n\nKYLE: You create an endless loop. \n\nDAVID: Exactly. You come in in the morning, and the server room is 140 degrees. And all the servers are spun up CPU bound. And they're literally, oh, I got a new event; I better attach a new event. Oh, I got a new event; I better attach a new event. Oh, I got a new event; I better...right? And they're just going, and going, and going. You don't have a story for this. And you're like, oh, how did we write it? We haven't even written the software. How do we already have a bug? [laughs] This is a bug that is in code that doesn't even exist yet. \n\nIt's because you sketched out how the thing was going to come together. You overlooked the fact that when we push this event on, it's going to update the contract. So, oh, okay, it turns out that we misunderstood the problem, and we're going to have to address that somehow. And you find that out when you take that little vertical slice. You serve up the thinnest slice of cake that you can. It doesn't do anything useful except it connects all of the pieces together, and that's immensely, immensely useful.\n\nKYLE: And based on your example, it sounds like we got a decent load test on the server to know whether or not it'll stay up. \n\nDAVID: [laughs] Yep. Yeah, yeah. If you come in and the server room was ice cold because the hard drives all gave out six hours ago and they've all powered down, we've just discovered a hardware condition that we might want to deal with at some point, yeah.\n\nKYLE: Yeah, not production ready at all.\n\nDAVID: Mm-hmm. I worked at a shop years and years ago that Amazon was...they call it something else now. But at the time, they had a product called RightScale. And this is at the beginning when EC2 and cloud computing was brand new. And what RightScale was was this ability that if you gave them a manifest like a Docker container...this is before Docker existed. But you gave them some way to define a new server. At boot-up, it would connect to a load balancer. Okay, that's great. \n\nNow when your web server gets overloaded or starts running at 80%, 90%, 95% CPU, Amazon takes the template for that web server, spins up a new one, boots it up, connects it into the web load balancer, and now you've got another web server. And if those servers go up to 80%, 90%, 95%, it would spin up another one, and another one, and another one. And it was fantastic. \n\nAnd this is back in the beta of EC2 when you could only have 100 instances total. That's the dark ages. Now if you don't have 1,000 servers in the cloud, you're not a real company. But we set this all up. We went home. Literally, it was like a Wednesday, and we went home. And we came in on Thursday, and the CEO is pacing back and forth, and he's like, \"All of the servers are spun up. What the hell is going on?\" \n\nWe go upstairs and we log into the console. And sure enough, we're getting errors from EC2 saying all your servers are spun up. They're all at 95%. And we're like, oh crap, oh crap. What do we do? What do we do? So we start diving into them. And we log in, and they're getting traffic. They're getting real traffic. We're like, what the hell? We needed two web servers yesterday, and now we need 100. What's going on? I mean, they got to be talking to each other or sending a loop to each other like the contract thing. What is this? What is this? \n\nIt was one of those perfect timing moments because we're pacing back and forth, and the CIO shows up at like 8:30, walks in the front door, and he's like, \"Hey, did you guys see the bid on Oprah?\" The company had literally been on The Oprah Winfrey Show the night before. And our servers had been getting pounded all night with real traffic. And the CEO went, \"Wait a minute, this is all making us money? Heck yeah.\" It was fantastic. So yeah, occasionally, you hook something up, and it works correctly. And that's even more terrifying [laughs] than having it go wildly wrong.\n\nEDDY: I'm just curious, have you ever found yourself in a situation where you felt you needed to push back when the breakdown of the work that was given to you was unachievable for the deadline that they're giving you? Because that kind of goes back to the whole how do you manage the workload? And so, in the event that is unachievable in your career, have you ever pushed back and said, \"No, this can't be done?\"\n\nDAVID: I'll tweak the question a little tiny bit. What happens when the workload is just shaped wrong, when it's too big for the calendar, or they pulled half your team off to go work on Project X, which is the secret initiative down on the other department, but your workload in your calendar hasn't shifted? How do you deal with that?\n\nKYLE: So I've been at a few companies, and they've all practiced their own...I feel like Agile and Scrum are used as buzzwords, and they're all practiced a little bit differently, regardless of where you're at. But one thing that I've seen that's kind of been common is everybody sizes. Everybody sizes things based upon your team's efficiency. And some teams use points; some teams use shirts. I had a team that used is this a pebble, or is this a galaxy?\n\nAnd it was one of those things where during planning or after investigation, it was one where we'd go back and say, \"Hey, this is no longer a pebble after researching it. This is a moon. This is going to take us much longer. We're not a moon team, you know; we're a mountain team. We can't get a full moon done in one sprint.\" And you'd have to go back and give pushback on that. And I just think that that sizing situation gave them a better understanding. \n\nBecause the people asking for the work generally are product managers or whoever it might be. And they're like, \"Oh, this is just an easy feature.\" \"This is just putting a new button on the webpage,\" or \"This won't be that bad.\" And they don't understand the scope of the work. So that's kind of what I'm saying there is like, once you're able to put it in terms they understand as well, it's a little bit easier to push back too.\n\nDAVID: There's a great thing that you're touching on here, which is that your product owner is somebody who's looking at your backlog. And they know that you have a velocity of 27.4 fiddly bits or whatever the velocity points are. And if your backlog has 12,000 story points in it, you're not finishing that in the next two weeks or three months or whatever. \n\nI have worked in environments years and years ago where nobody had any idea when things were going to be done. And the closer we got to a deadline, the more management would come browbeat the developers. And I kind of got in the habit of just shrugging and telling my manager, \"This takes as long as it takes. I'm giving you my best possible work. But I am one person; I can't make time.\" And sometimes, that was a difficult conversation. \n\nI've had people that are like, \"Well, make it happen. I don't care what you have to do.\" And I'm like, invent time travel, I guess. If that's really your management style, then I suggest you go cut a purchase order for a time machine. I'm going to need some resource support on that. The move into agile...and I like what you said, Kyle, about Agile with a capital A and a TM at the end of it is a product that we sell to teams. And then there's this idea of lowercase agile, which is just like the concepts underneath it. \n\nBut I did a Scrum training years ago, and I'm not a super big fan of Scrum. But I did the product master or something rather exceptional or whatever. Scrum is [chuckles]...they've got a whole certificate tiering racket going on. The most useful thing I think I took away from the Scrum training was this exact question of when we groom the backlog, and we find out that we thought this was going to take six weeks, and we've groomed the backlog, and it looks like it's going to take 18 months, what do we do? \n\nAnd the Scrum trainer grinned an evil little grin and said, \"You don't do anything. It's not your job.\" Your job is, to be honest. And it's your product owner's job to figure out what to cut off, and where, and what is more important. What do you want to have first? And she said something that I have carried around with me ever since. She said, \"The framework creates transparency, and transparency is a bear.\" I love that quote. \n\nBecause, yeah, you sit down, and you say, \"There's the backlog.\" Somebody comes in and says, \"We need this done in two weeks.\" You pull up the backlog, and you say, \"There's the line. I can fit this much stuff in the next few weeks. What stuff do you want in that box?\" \"We'll take that piece out and put this piece in. And oh, this piece that I've been telling you for six months is absolutely necessary turns out it's just UI tweaking. What we actually need is the ability to bill a customer, and we don't have that yet.\" So the important stuff suddenly gets put into the box, which is really, really great. \n\nSo I don't want to sound like I'm smug or defiant with the product team. But I am saying that there's a boundary violation here. It's like business' job is to decide what's important and what is first. And technical people aren't allowed to make that decision. It's not our responsibility, but it's not any of our business to decide what is first. But conversely, the business folks don't have any business telling the technical people how hard it's going to be or how long it's going to take. I tell you how much it costs. You tell me if it's worth it to pay for that, to pay that cost and if it is, we work on that first.\n\nKYLE: I was thinking, like, that's what a lot of this is when you're in planning is it's almost a haggling situation. You're sitting there trying to say, \"Well, we could get this much of this feature done or this much of this epic done.\" And they're going, \"Well, that's not enough.\" \"Well, okay. How about this? Can we do this?\" And you're kind of haggling back and forth. And while you're doing that, you're also pointing out, well, this is going to put us further into technical debt, and you're vouching for the technical debt that you want to get done. \n\nAnd it's this weird situation where you get into engineering, and you don't realize that part of your job is going to be sitting there haggling with the business over what you think is important to keep the business running and what product or the business thinks is important to keep running. Because new features are fun and shiny, but you got to keep the core up. Otherwise, if the core fails, then the business fails.\n\nDAVID: Everybody hates legacy code, not me. I love legacy code. And the reason I love legacy code is because that's the stuff that writes my paycheck. That's the stuff that's making the company the money that the company pays me with to work on the cool, new features. So I love legacy code. \n\nKYLE: As long as it's not spaghetti.\n\nDAVID: How do I put this? You can love someone and hate what they do. [laughs] So for me, sitting down with some code that was written...I've mentioned this on another podcast, but I literally had to maintain some code that was written to win a bet. Like, the architecture was a bet. He basically said, \"I can do this with one line of code.\" His team partner was like, \"No, you can't.\" \n\nHe then re-architected the way the modules talk to each other so that one module cascaded into the next one so that you could just bring them up in a chain. And then you could just do objects dot map, dot inject, dot, dot, dot, dot, you know, and it was a long one-liner, but it was a one-liner. [laughs] The guy who wrote this is legitimately one of the smartest people I've ever met. He and I have had multiple conversations where he's like, \"No, that one line of code was also the right line of code. It was the right way to solve it.\" \n\nAnd my repeated concern with that claim is that that one line of code is impossible to maintain. We cannot ever change that one line of code. We will rework the entire rest of the application to support that one line of code because it's just burned deeply, deeply, deeply into the architecture. Everything is in support of that one line. I'm okay with that. \n\nWhen you build a house, you've got to pick which walls are load-bearing. And that one line of code is absolutely the king truss load-bearing wall of the application. Yeah, you can get a piece of code. Anybody that worked in Ruby 10 years ago knows what it's like to have to maintain a PHP app with spaghetti code and servers that crash and don't give you error messages because you've got error reporting turned off in PHP and all of that fun stuff while working on the shiny, new Rails app that's going to replace the PHP.\n\nAnd you get around the water cooler, and you're just like, oh, I hate this code. I hate this code. I hate the old codebase. I can't wait to work on the new codebase. And I've been there. I've done that. And then, a couple of years later, we were standing around the water cooler, and we were working on the 2.0 version of the Rails app. And we were just lamenting how awful the 1.0 Rails app was. And I'm like, oh, I hate working on the old code. It's not going to be like...the new code is going to be so much better. And I'm like, wait a minute, didn't we just leave this party? \n\nSo yeah, legacy code, by definition, is insufficient to the new needs because people that wrote it weren't psychic. They don't write it for future us. Anyway, I can hate the way legacy code is written and still love the fact that...I guess what I'm saying is maybe I don't love legacy code so much as I love paychecks, like a lot. I really, really like that part. I don't think I would do this job if I wasn't getting paid. [laughs]\n\nKYLE: To kind of tangent off of what you're hitting on there, I think that's something like you said, it's water cooler talk. It's the running joke; oh, I don't want to go work on legacy code, or legacy code is so terrible. Well, the reason is because of situations like that where it's like, you've got this one line that does so much or a block of code, we'll say, file of code, doesn't matter. It does so much. And it's either so old, or there's something about it that makes it difficult.\n\nBut you telling another engineer, \"This is horrible. This is going to take me forever to do,\" that's one thing. But somehow translating that and explaining that to product or business-like, oh no, this is going to take two to three times longer because it's a change in the old codebase, that's something that's a little bit more difficult to explain to these individuals. Because it's the same thing to them, you know, depending on the individual, but it's the same thing to them. And how do you get them to understand that situation?\n\nDAVID: Honestly, I've had this happen a lot where you have this exact problem where it's like, oh, we can do this in four hours in the new codebase. But this is going to take us three weeks in the old codebase. And like, oh gosh, what's going on? Well, there are two big things that are going on; one is the essential amount of complexity. You're backing on to 70,000 lines of code versus backing on to 1,500 lines of code. \n\nThe 2.0 app doesn't do as much. The stuff it does do, it does beautifully, and it does elegantly, but it does it uncomplicatedly, if that's a word. It doesn't have to negotiate with all these other things. And then the other thing is there's often process that throws in. It's like; I can sit down and cut a feature on the 2.0 Rails app. And I don't have to do SOX compliance. I don't have to run this past QA. I don't have to run this through three separate code reviewers because it's this greenfield project. \n\nThere's no money depending on this. There's no auditing legislation that's going to lock us down, and you wouldn't want that. If you're cutting a new greenfield app and you're cutting that first slice of cake, you don't have the ability to pull that document down at all. Auditing for SOX compliance is a bad idea. That's going to slow you down and give you nothing in exchange. \n\nThings like SOX compliance or other types of compliance auditing are there to keep you from breaking something valuable that exists. And when you're doing a greenfield application, there's nothing valuable that exists. You're building [inaudible 29:06]. You're just spinning code out of whole cloth. And so we often have the ability just to move faster. \n\nBut I really think it comes down to just...it's not that legacy code is inherently terribly complex. It's just if you've got a seven-year-old app that you're building against, there are seven years of history. And it doesn't matter if that history is really, really good or really, really bad. I mean, it does, it does. I'd rather have seven years of good history code to work on than seven years of bad history. But seven years is still seven years. There's a lot of stuff to pick up and learn and hold in your head. \n\nAnd it's really hard to go through that and groom it so that we have borders that when you pick up this piece of the legacy code, you don't have to think about this other piece because we've built a wall between these. There's an interface here, so now you don't have to think about this. Where previous to putting in that interface, if you picked up code on this side, you had to be thinking about code all the way around it. \n\nIn that little slice of cake, we update the contract, and that updates the contract, which causes it to show up in a loop. And now we've got a new problem. And you get these surprising things coming in out of the side. And when you've got legacy code, seven years of legacy, it's all blindsides. You can't look around without getting hit in the back of the head by a piece of unexpected code. When you're building against ten times the size of a codebase, there's 100 times the complexity. \n\nAnd I guess this is the dangerous thing that I'm saying, the code that we're writing right now here today if we don't have a dramatically changed idea of how to write clean code, or maintainable code, or good code, or well-tested code if you don't have a really clear idea of that, then the only thing you know for certain is that you're writing more legacy code. Two years from now, you're going to be hating this code. And some of that is experience, and some of it is unavoidable, I think. \n\nBecause you today don't know what's coming down the pipe two years from now, and you shouldn't. The entire Agile principle of YAGNI \"You aren't gonna need it.\" Leave things unsupported until you need them because two years from now, you're going to be going through the code, maintaining some module of code that doesn't get used, and nobody needs it. Nobody wants it, but it's in the codebase. \n\nAnd you're renaming some variable, or you're changing some API, and this module uses that API. It's poorly tested, or it's not tested at all. And you get into it, and you find out that this is using the API wrong, but I have to update it to use the new API correctly, and that, yeah, it's terrible. I'll stop talking about YAGNI. YAGNI is bad. Don't do YAGNI.\n\nEDDY: You know, David, you touched on something that I kind of want to elaborate on. And this might be a topic for another podcast. You were talking about legacy code, and it kind of sparked an interest on how do you get familiar with a company's thousands of lines of codebase without getting overwhelmed? Because that kind of touches on it also. Do you recommend to get familiar with the overall design and architecture first and then you get familiar with the specific details of the code as you progress, or? Because I feel like there are some elements to the way work is divided.\n\nDAVID: We are getting close to the top of the hour, so I've got a short answer and a shorter answer. The shorter answer is we should do a whole podcast episode about working with legacy code. I think that would be fantastic. The short answer is two things, one; you should go get a copy of Michael Feathers' book \"Working with Legacy Code.\" That book is like 10 or 15 years old. I haven't picked it up in about five years, but I picked it up five years ago, and none of it was out of date. \n\nIt's dramatically profound the kind of stuff that he tells you. He literally tells you how to work with code that you don't know anything about. And I've really learned how to keep my elbows in when I'm working on code, how to edit a piece of code without affecting the next file over or the next module over or altering the interfaces. And I got that from that book. \n\nThe other piece of advice is read, read, read. Go get a project, download it, and then read the architecture and go, oh, that's how you're doing that. And then put that project down, pick up another project, read it, and go, oh, wow, they're using recursion here instead of for loops. That's weird. And you go along for six months, and you start using recursion everywhere until your teammates have an intervention, and they pull you aside and say, \"Dude, please just use a for loop here.\" And you realize, oh, there's a good place for a for loop, and there's a good place for recursion, and I'm using them everywhere. \n\nAnd yeah, read as much code. Your ability to navigate an existing codebase is largely determined by how many different patterns you're familiar with. So go get a new piece of software, download it, read it, lather, rinse, repeat. And look me up in five years, and you'll be a whiz at it. You won't be a whiz at it in five months. You got to stack as many arrows in your quiver as you can. \n\nAll righty, we're at the top of the hour. Thank you, guys, for coming. I really appreciate it. Kyle, Ramses, Eddy, this was a lot of fun. Be good until next episode. We'll talk to you guys later.","content_html":"Here's part two of how to break down product work! In the last episode, we talked about how to break down product work, and talked about the 'why' and the 'when'. Today, we tackle the 'how'!
\n\nTranscript:
\n\nDAVID: Welcome back to the Acima Development Podcast. We are doing the part two of how to break down product work. Last episode, we were going to talk about how to break down product work, and we ended up talking about why and when, and didn't get into the how very much. I'm your host, David Brady. Today we're joined on the podcast by Kyle Archer, Ramses Bateman, and Eddy Lopez. And it's exciting to see you guys. Let's jump in. So how do you break down product work?
\n\nEDDY: You know, Dave, this has been lingering for me in my back pocket since last week. But I was getting over an illness, that I wasn't very productive in our conversation. As you may know, I'm an aspiring developer. Within the next few months or so, I'm hoping to actively be getting paid to develop and write code.
\n\nDAVID: Nice.
\n\nEDDY: One of the things though...and I see this often, specifically from a QA standpoint, where a company will ask you, they're like, "Hey, we need this huge and large and pretty feature. Oh, and you got X amount of time to get it done. You look at epic, you look at the subtasks, and it's like 30. [laughs] And now it can seem a bit daunting to look at all the subtasks that you need to tackle. What's your approach when you feel overwhelmed when you look at how big a project is sometimes?
\n\nDAVID: I do not want these podcasts to turn into me holding court with you guys because I'm honestly not that smart. Let me kick that over to Kyle and Ramses. How would you guys break that down? Somebody comes in and says, "Hey, we've got this big product, and you're in charge of it. You're the lead developer." Obviously, you've got to break it down somehow because you can't work on a 30-point story. How do you break that down into something smaller?
\n\nRAMSES: I think for me, it would kind of depend on what the epic is and then looking at the stories and seeing if we could subdivide the stories if it is appropriate to put them in thirds, halves, whatever it was. And kind of give some pushback and say, "This is great. This is a lot of work. We don't have enough manpower to get this done," and express what we could accomplish in that given timeframe.
\n\nDAVID: Yeah, I like that. In the last episode, [chuckles] I came up with a horrible metaphor. And it was because I was in the wrong aisle of the bakery. In my head, I was thinking it's like a loaf of bread. You've got to start at one end of the loaf and get to the other end of the loaf. And this was a terrible metaphor. And I apologize to everybody [laughs] who waited through that last line. Turn the loaf of bread sideways or on its end and imagine it's a layer cake. That's the metaphor that I should have gone for in the last episode.
\n\nFor me, when I need to break product work down, especially if it's a big thing, you know, every business, not every business, but a lot of a lot of businesses, there's a central object that is like a document or a record of something. And it is the central artifact of business that your company works with, so with Acima, it's a lease. At CoverMyMeds, when I was working there, it was a prior authorization request, like somebody wanted to get a drug approved. These documents are at the center of everything.
\n\nNew customers coming in they get attached to this document, or they're applying to get into one of these documents. And then they get approved, and they're now in this document. And then they're transacting the business of working through the contract of that document, and all the way until it's all paid off. And then it goes into history. And so there are all these events.
\n\nLet's say you're at a business, and you've got some central document like this. Let's say you're at a legal firm, and it's a contract. We have people coming in, and they want to get a contract. They need to create the contract, join, da da da. Okay, that's fine. And you got all these servers, and they're running software, and they're prosecuting the business. Prosecuting is a terrible pun. Sorry, it was not intentional, but I am proud of it. Transacting all the business of processing this contract, right?
\n\nProduct comes to you and says, "Hey, we need a separate logging service. Anytime something happens to a contract, we need you to go to the master contract server and pull down the main copy, like, the original copy of the contract. We need you to amend the event, attach the event to it, and then store it back into the system. And we need you to do it in a separate service." And so you're going to talk to the contract server. You're going to get this thing. You're going to add these events to it, and then you're going to push these events back up into some other service to record them. This is pretty straightforward.
\n\nAnybody that's worked in kind of a service-oriented architecture has been given product work where it's, hey, talk to this server, and that server, and that server, and do something that those servers can't do on their own because they can't see each other. They don't know what the other server knows. So your little job here is to talk to all three to have the knowledge that comes from all three of those things and do something with it. This is pretty straightforward.
\n\nThe metaphor of a layer cake for me comes about because instead of just looking at the top layer of the cake and saying I'm going to build the top layer of the cake, the very top layer of the cake, is we're going to build the thing that downloads the contract from the main contract server. And we're going to build that piece of software, and we're going to build it complete. We're going to get every single field. We're going to get every translation bit. We're going to decode the thing. It's encrypted, so we're going to put an encryption key. And all of this is put on there.
\n\nBut you don't go to the second layer of the cake until the top layer is completely finished. And so you end up with building this thing that can handle everything about understanding this contract that you've downloaded and how to get it from this main server. But the things that you need underneath, just one layer down, don't exist yet. And so you don't have a cake. You don't have anything that you can serve on a plate and eat.
\n\nThis is how we did software in the '90s. You hear people talking about waterfall where you design everything, then you write it, then you debug it. You don't write code while you're debugging that kind of thing. The layer cake idea is if you want to take a piece of cake and serve it, you want to serve up a slice of cake as quickly as possible. And that means you've got to write just enough of that top layer to connect to the next layer down, and you got to write just enough of that to connect.
\n\nSo you might sit down and go, okay, I'm going to connect to the main contract server, and I'm going to download the contract. The contract is encrypted. I don't care. I just want bits off of that server. If I can prove that those bits did not come from my server and they came from that server, that's good enough. So we pull this thing down.
\n\nThere's some piece of the contract that's going to be unencrypted, like the ID number or something like this. If I can get the ID off of this thing, great, I'm in business. We go down to the next layer. The next layer is something that's going to decode or actually just parse the stupid document. So we're not even going to worry about the encryption piece. We're just going to decode can we find the ID field in this document? And then we go down to the next layer, and the next layer, and the next layer.
\n\nAnd eventually, you've got this super, super thin, tiny little application. It's not even an MVP, minimum viable product. It's so much less than an MVP, but it goes full stack from the top to the end, from one end of the cake to the other, or from the top of the cake to the bottom. It connects to the main server. It downloads the contract. It parses out the ID field.
\n\nIt figures out, oh, I want to attach an event to this. It gins up an event, which just has an ID and a created at, like, there's no event information. It's just the minimum. What's the smallest event that we can create? It's just got an ID and a timestamp. That's an event that exists but has no other useful data. And then, we upload that event to another server.
\n\nAnd for this minimal piece, we're just going to connect to the event server. We're not even going to shove up the event that we created. We're just going to shove up an event with an ID of 42 and a created timestamp of now, and that's it. That's your entire slice. And I've got a really, really dangerous question for you guys, which is, why is that insanely useful? Or, if you prefer, tell me what goes wrong in building that? What problems are you going to have to solve in order to get that entire piece of cake put together?
\n\nI worry that I've told the story carefully enough that you guys might feel like there's one right answer or one wrong answer, and there isn't. Have any of you guys done software where you take this vertical slice like this, and if so, was there something really surprising that wasn't in your master ticket, you know, the epic story that you have to break down that you found out by building this thing?
\n\nKYLE: I think what I've seen when I've kind of approached it like this is it can be both beneficial and, I guess...harmful is not the word. But I'm trying to think of the word I'm wanting here, but detrimental, there we go. In the sense that when I'm doing a vertical like that, I see stories that are both missing and are both unneeded as I'm going along that route. So I think that's kind of the danger of doing it that way for me.
\n\nDAVID: Talk to me more about this because I'm literally sitting here bouncing up and down on my chair, going it's not the defect. This is the feature of this approach. Talk to me about running into these missing and needed stories. What does that look like? How does that feel? And how do you deal with it?
\n\nKYLE: I'm trying to think of how to respond to that. It's just...because you're going along and you just realize that...I'm trying to think of an example right now. But it's not going to quite work the way that you're wanting to. Maybe there's a faster protocol that you can use, so that's adding something, right?
\n\nDAVID: Mm-hmm.
\n\nKYLE: Or maybe you're realizing that you can't transfer as big of a file as you wanted, you know, there's a technical hurdle.
\n\nDAVID: Bingo.
\n\nKYLE: There's a legal hurdle. There's a security hurdle, you know, different things can get in the way. But as you're going along, you're learning, and you're also realizing what would make the feature or the system better so you can see where adding a story would be beneficial.
\n\nDAVID: That is exactly, exactly it. When we look at these layers in our head, or we think about these layers, we often think about, okay, inside this layer, I got to do this, do that, do that. And then you go to the next layer, and you think about what's going to be in that. And you don't stop to think about, wait a minute, how is this layer going to talk to the next layer or the one above? What are the implications of this?
\n\nAnd when you take a slice vertically through the entire problem space, those things jump right out at you. Right off the tip of the bat, you find out that, oh, you can't connect to the main contract server without a username, password, and encryption key. You don't have one of those. You've got to go to IT and get an encryption key. Like, oh, we don't have a story for that. But we've got this other story buried way, way down off the side. That's the entire communication between the contract server, and your service, and the service, and the eventing service, all have to be secured with encryption. Okay, fine.
\n\nAnd we've got this big sub-epic kind of an epic of itself which is to dig into the encryption and figure out how we're going to encrypt all these packets back and forth. And as you're struggling with this, you go to lunch with somebody from IT. And you're telling them about the headache that you're having with this.
\n\nAnd the person from IT looks at you, kind of cocks their head a little bit, and goes, "Why are you doing that? You know that this server is on a backplane all by itself. It's inside a LAN. I mean, literally, there's a physical wire dedicated to the communication between this server and that server. And everything that goes on that wire is encrypted at the hardware level, like, we built it that way. We built it that way for you. Why aren't you using this?"
\n\nAnd you realize, oh, the application encryption it's done. This entire story is wasted heat for us trying to encrypt packets that are going on an encrypted transport protocol. I, four or five years ago, worked on...and don't quote me on this, guys, because I'm not a security guy. [chuckles] But we had a whole bunch of services that needed to talk to each other, and we needed encryption over them.
\n\nAnd then we stepped back and realized we're doing all of this over HTTPS. And we're like, wait a minute, does this secure everything that we need? And we went back and like, why do we want this encryption? And we're like, somebody eavesdropping here. Oh, yeah, that's hardened, that's encrypted. Anybody eavesdropping on that wire is going to get encrypted packets, to begin with. It doesn't mean you're safe. You never think that with encryption or security. But to whatever degree of safe enough, we were already done, and we were just wasting time.
\n\nThe opposite end is you come across stories that don't exist that you need. You need the encryption key to talk to the server, or you need an account on that server to download the contract. Or you run into a fun thing where your service talks to the main contract server. How does it know which contract to update? Well, it goes to the database, and it looks for things that have changed; okay, that's fine.
\n\nBut unbeknownst to us, the eventing server, every time it gets a new event, it updates the timestamp on the contract to say you've been updated. Now what's going to happen the first time you try to tag an update and attach it to a contract? I'm grinning my evil grin. What's going to go wrong here?
\n\nKYLE: You create an endless loop.
\n\nDAVID: Exactly. You come in in the morning, and the server room is 140 degrees. And all the servers are spun up CPU bound. And they're literally, oh, I got a new event; I better attach a new event. Oh, I got a new event; I better attach a new event. Oh, I got a new event; I better...right? And they're just going, and going, and going. You don't have a story for this. And you're like, oh, how did we write it? We haven't even written the software. How do we already have a bug? [laughs] This is a bug that is in code that doesn't even exist yet.
\n\nIt's because you sketched out how the thing was going to come together. You overlooked the fact that when we push this event on, it's going to update the contract. So, oh, okay, it turns out that we misunderstood the problem, and we're going to have to address that somehow. And you find that out when you take that little vertical slice. You serve up the thinnest slice of cake that you can. It doesn't do anything useful except it connects all of the pieces together, and that's immensely, immensely useful.
\n\nKYLE: And based on your example, it sounds like we got a decent load test on the server to know whether or not it'll stay up.
\n\nDAVID: [laughs] Yep. Yeah, yeah. If you come in and the server room was ice cold because the hard drives all gave out six hours ago and they've all powered down, we've just discovered a hardware condition that we might want to deal with at some point, yeah.
\n\nKYLE: Yeah, not production ready at all.
\n\nDAVID: Mm-hmm. I worked at a shop years and years ago that Amazon was...they call it something else now. But at the time, they had a product called RightScale. And this is at the beginning when EC2 and cloud computing was brand new. And what RightScale was was this ability that if you gave them a manifest like a Docker container...this is before Docker existed. But you gave them some way to define a new server. At boot-up, it would connect to a load balancer. Okay, that's great.
\n\nNow when your web server gets overloaded or starts running at 80%, 90%, 95% CPU, Amazon takes the template for that web server, spins up a new one, boots it up, connects it into the web load balancer, and now you've got another web server. And if those servers go up to 80%, 90%, 95%, it would spin up another one, and another one, and another one. And it was fantastic.
\n\nAnd this is back in the beta of EC2 when you could only have 100 instances total. That's the dark ages. Now if you don't have 1,000 servers in the cloud, you're not a real company. But we set this all up. We went home. Literally, it was like a Wednesday, and we went home. And we came in on Thursday, and the CEO is pacing back and forth, and he's like, "All of the servers are spun up. What the hell is going on?"
\n\nWe go upstairs and we log into the console. And sure enough, we're getting errors from EC2 saying all your servers are spun up. They're all at 95%. And we're like, oh crap, oh crap. What do we do? What do we do? So we start diving into them. And we log in, and they're getting traffic. They're getting real traffic. We're like, what the hell? We needed two web servers yesterday, and now we need 100. What's going on? I mean, they got to be talking to each other or sending a loop to each other like the contract thing. What is this? What is this?
\n\nIt was one of those perfect timing moments because we're pacing back and forth, and the CIO shows up at like 8:30, walks in the front door, and he's like, "Hey, did you guys see the bid on Oprah?" The company had literally been on The Oprah Winfrey Show the night before. And our servers had been getting pounded all night with real traffic. And the CEO went, "Wait a minute, this is all making us money? Heck yeah." It was fantastic. So yeah, occasionally, you hook something up, and it works correctly. And that's even more terrifying [laughs] than having it go wildly wrong.
\n\nEDDY: I'm just curious, have you ever found yourself in a situation where you felt you needed to push back when the breakdown of the work that was given to you was unachievable for the deadline that they're giving you? Because that kind of goes back to the whole how do you manage the workload? And so, in the event that is unachievable in your career, have you ever pushed back and said, "No, this can't be done?"
\n\nDAVID: I'll tweak the question a little tiny bit. What happens when the workload is just shaped wrong, when it's too big for the calendar, or they pulled half your team off to go work on Project X, which is the secret initiative down on the other department, but your workload in your calendar hasn't shifted? How do you deal with that?
\n\nKYLE: So I've been at a few companies, and they've all practiced their own...I feel like Agile and Scrum are used as buzzwords, and they're all practiced a little bit differently, regardless of where you're at. But one thing that I've seen that's kind of been common is everybody sizes. Everybody sizes things based upon your team's efficiency. And some teams use points; some teams use shirts. I had a team that used is this a pebble, or is this a galaxy?
\n\nAnd it was one of those things where during planning or after investigation, it was one where we'd go back and say, "Hey, this is no longer a pebble after researching it. This is a moon. This is going to take us much longer. We're not a moon team, you know; we're a mountain team. We can't get a full moon done in one sprint." And you'd have to go back and give pushback on that. And I just think that that sizing situation gave them a better understanding.
\n\nBecause the people asking for the work generally are product managers or whoever it might be. And they're like, "Oh, this is just an easy feature." "This is just putting a new button on the webpage," or "This won't be that bad." And they don't understand the scope of the work. So that's kind of what I'm saying there is like, once you're able to put it in terms they understand as well, it's a little bit easier to push back too.
\n\nDAVID: There's a great thing that you're touching on here, which is that your product owner is somebody who's looking at your backlog. And they know that you have a velocity of 27.4 fiddly bits or whatever the velocity points are. And if your backlog has 12,000 story points in it, you're not finishing that in the next two weeks or three months or whatever.
\n\nI have worked in environments years and years ago where nobody had any idea when things were going to be done. And the closer we got to a deadline, the more management would come browbeat the developers. And I kind of got in the habit of just shrugging and telling my manager, "This takes as long as it takes. I'm giving you my best possible work. But I am one person; I can't make time." And sometimes, that was a difficult conversation.
\n\nI've had people that are like, "Well, make it happen. I don't care what you have to do." And I'm like, invent time travel, I guess. If that's really your management style, then I suggest you go cut a purchase order for a time machine. I'm going to need some resource support on that. The move into agile...and I like what you said, Kyle, about Agile with a capital A and a TM at the end of it is a product that we sell to teams. And then there's this idea of lowercase agile, which is just like the concepts underneath it.
\n\nBut I did a Scrum training years ago, and I'm not a super big fan of Scrum. But I did the product master or something rather exceptional or whatever. Scrum is [chuckles]...they've got a whole certificate tiering racket going on. The most useful thing I think I took away from the Scrum training was this exact question of when we groom the backlog, and we find out that we thought this was going to take six weeks, and we've groomed the backlog, and it looks like it's going to take 18 months, what do we do?
\n\nAnd the Scrum trainer grinned an evil little grin and said, "You don't do anything. It's not your job." Your job is, to be honest. And it's your product owner's job to figure out what to cut off, and where, and what is more important. What do you want to have first? And she said something that I have carried around with me ever since. She said, "The framework creates transparency, and transparency is a bear." I love that quote.
\n\nBecause, yeah, you sit down, and you say, "There's the backlog." Somebody comes in and says, "We need this done in two weeks." You pull up the backlog, and you say, "There's the line. I can fit this much stuff in the next few weeks. What stuff do you want in that box?" "We'll take that piece out and put this piece in. And oh, this piece that I've been telling you for six months is absolutely necessary turns out it's just UI tweaking. What we actually need is the ability to bill a customer, and we don't have that yet." So the important stuff suddenly gets put into the box, which is really, really great.
\n\nSo I don't want to sound like I'm smug or defiant with the product team. But I am saying that there's a boundary violation here. It's like business' job is to decide what's important and what is first. And technical people aren't allowed to make that decision. It's not our responsibility, but it's not any of our business to decide what is first. But conversely, the business folks don't have any business telling the technical people how hard it's going to be or how long it's going to take. I tell you how much it costs. You tell me if it's worth it to pay for that, to pay that cost and if it is, we work on that first.
\n\nKYLE: I was thinking, like, that's what a lot of this is when you're in planning is it's almost a haggling situation. You're sitting there trying to say, "Well, we could get this much of this feature done or this much of this epic done." And they're going, "Well, that's not enough." "Well, okay. How about this? Can we do this?" And you're kind of haggling back and forth. And while you're doing that, you're also pointing out, well, this is going to put us further into technical debt, and you're vouching for the technical debt that you want to get done.
\n\nAnd it's this weird situation where you get into engineering, and you don't realize that part of your job is going to be sitting there haggling with the business over what you think is important to keep the business running and what product or the business thinks is important to keep running. Because new features are fun and shiny, but you got to keep the core up. Otherwise, if the core fails, then the business fails.
\n\nDAVID: Everybody hates legacy code, not me. I love legacy code. And the reason I love legacy code is because that's the stuff that writes my paycheck. That's the stuff that's making the company the money that the company pays me with to work on the cool, new features. So I love legacy code.
\n\nKYLE: As long as it's not spaghetti.
\n\nDAVID: How do I put this? You can love someone and hate what they do. [laughs] So for me, sitting down with some code that was written...I've mentioned this on another podcast, but I literally had to maintain some code that was written to win a bet. Like, the architecture was a bet. He basically said, "I can do this with one line of code." His team partner was like, "No, you can't."
\n\nHe then re-architected the way the modules talk to each other so that one module cascaded into the next one so that you could just bring them up in a chain. And then you could just do objects dot map, dot inject, dot, dot, dot, dot, you know, and it was a long one-liner, but it was a one-liner. [laughs] The guy who wrote this is legitimately one of the smartest people I've ever met. He and I have had multiple conversations where he's like, "No, that one line of code was also the right line of code. It was the right way to solve it."
\n\nAnd my repeated concern with that claim is that that one line of code is impossible to maintain. We cannot ever change that one line of code. We will rework the entire rest of the application to support that one line of code because it's just burned deeply, deeply, deeply into the architecture. Everything is in support of that one line. I'm okay with that.
\n\nWhen you build a house, you've got to pick which walls are load-bearing. And that one line of code is absolutely the king truss load-bearing wall of the application. Yeah, you can get a piece of code. Anybody that worked in Ruby 10 years ago knows what it's like to have to maintain a PHP app with spaghetti code and servers that crash and don't give you error messages because you've got error reporting turned off in PHP and all of that fun stuff while working on the shiny, new Rails app that's going to replace the PHP.
\n\nAnd you get around the water cooler, and you're just like, oh, I hate this code. I hate this code. I hate the old codebase. I can't wait to work on the new codebase. And I've been there. I've done that. And then, a couple of years later, we were standing around the water cooler, and we were working on the 2.0 version of the Rails app. And we were just lamenting how awful the 1.0 Rails app was. And I'm like, oh, I hate working on the old code. It's not going to be like...the new code is going to be so much better. And I'm like, wait a minute, didn't we just leave this party?
\n\nSo yeah, legacy code, by definition, is insufficient to the new needs because people that wrote it weren't psychic. They don't write it for future us. Anyway, I can hate the way legacy code is written and still love the fact that...I guess what I'm saying is maybe I don't love legacy code so much as I love paychecks, like a lot. I really, really like that part. I don't think I would do this job if I wasn't getting paid. [laughs]
\n\nKYLE: To kind of tangent off of what you're hitting on there, I think that's something like you said, it's water cooler talk. It's the running joke; oh, I don't want to go work on legacy code, or legacy code is so terrible. Well, the reason is because of situations like that where it's like, you've got this one line that does so much or a block of code, we'll say, file of code, doesn't matter. It does so much. And it's either so old, or there's something about it that makes it difficult.
\n\nBut you telling another engineer, "This is horrible. This is going to take me forever to do," that's one thing. But somehow translating that and explaining that to product or business-like, oh no, this is going to take two to three times longer because it's a change in the old codebase, that's something that's a little bit more difficult to explain to these individuals. Because it's the same thing to them, you know, depending on the individual, but it's the same thing to them. And how do you get them to understand that situation?
\n\nDAVID: Honestly, I've had this happen a lot where you have this exact problem where it's like, oh, we can do this in four hours in the new codebase. But this is going to take us three weeks in the old codebase. And like, oh gosh, what's going on? Well, there are two big things that are going on; one is the essential amount of complexity. You're backing on to 70,000 lines of code versus backing on to 1,500 lines of code.
\n\nThe 2.0 app doesn't do as much. The stuff it does do, it does beautifully, and it does elegantly, but it does it uncomplicatedly, if that's a word. It doesn't have to negotiate with all these other things. And then the other thing is there's often process that throws in. It's like; I can sit down and cut a feature on the 2.0 Rails app. And I don't have to do SOX compliance. I don't have to run this past QA. I don't have to run this through three separate code reviewers because it's this greenfield project.
\n\nThere's no money depending on this. There's no auditing legislation that's going to lock us down, and you wouldn't want that. If you're cutting a new greenfield app and you're cutting that first slice of cake, you don't have the ability to pull that document down at all. Auditing for SOX compliance is a bad idea. That's going to slow you down and give you nothing in exchange.
\n\nThings like SOX compliance or other types of compliance auditing are there to keep you from breaking something valuable that exists. And when you're doing a greenfield application, there's nothing valuable that exists. You're building [inaudible 29:06]. You're just spinning code out of whole cloth. And so we often have the ability just to move faster.
\n\nBut I really think it comes down to just...it's not that legacy code is inherently terribly complex. It's just if you've got a seven-year-old app that you're building against, there are seven years of history. And it doesn't matter if that history is really, really good or really, really bad. I mean, it does, it does. I'd rather have seven years of good history code to work on than seven years of bad history. But seven years is still seven years. There's a lot of stuff to pick up and learn and hold in your head.
\n\nAnd it's really hard to go through that and groom it so that we have borders that when you pick up this piece of the legacy code, you don't have to think about this other piece because we've built a wall between these. There's an interface here, so now you don't have to think about this. Where previous to putting in that interface, if you picked up code on this side, you had to be thinking about code all the way around it.
\n\nIn that little slice of cake, we update the contract, and that updates the contract, which causes it to show up in a loop. And now we've got a new problem. And you get these surprising things coming in out of the side. And when you've got legacy code, seven years of legacy, it's all blindsides. You can't look around without getting hit in the back of the head by a piece of unexpected code. When you're building against ten times the size of a codebase, there's 100 times the complexity.
\n\nAnd I guess this is the dangerous thing that I'm saying, the code that we're writing right now here today if we don't have a dramatically changed idea of how to write clean code, or maintainable code, or good code, or well-tested code if you don't have a really clear idea of that, then the only thing you know for certain is that you're writing more legacy code. Two years from now, you're going to be hating this code. And some of that is experience, and some of it is unavoidable, I think.
\n\nBecause you today don't know what's coming down the pipe two years from now, and you shouldn't. The entire Agile principle of YAGNI "You aren't gonna need it." Leave things unsupported until you need them because two years from now, you're going to be going through the code, maintaining some module of code that doesn't get used, and nobody needs it. Nobody wants it, but it's in the codebase.
\n\nAnd you're renaming some variable, or you're changing some API, and this module uses that API. It's poorly tested, or it's not tested at all. And you get into it, and you find out that this is using the API wrong, but I have to update it to use the new API correctly, and that, yeah, it's terrible. I'll stop talking about YAGNI. YAGNI is bad. Don't do YAGNI.
\n\nEDDY: You know, David, you touched on something that I kind of want to elaborate on. And this might be a topic for another podcast. You were talking about legacy code, and it kind of sparked an interest on how do you get familiar with a company's thousands of lines of codebase without getting overwhelmed? Because that kind of touches on it also. Do you recommend to get familiar with the overall design and architecture first and then you get familiar with the specific details of the code as you progress, or? Because I feel like there are some elements to the way work is divided.
\n\nDAVID: We are getting close to the top of the hour, so I've got a short answer and a shorter answer. The shorter answer is we should do a whole podcast episode about working with legacy code. I think that would be fantastic. The short answer is two things, one; you should go get a copy of Michael Feathers' book "Working with Legacy Code." That book is like 10 or 15 years old. I haven't picked it up in about five years, but I picked it up five years ago, and none of it was out of date.
\n\nIt's dramatically profound the kind of stuff that he tells you. He literally tells you how to work with code that you don't know anything about. And I've really learned how to keep my elbows in when I'm working on code, how to edit a piece of code without affecting the next file over or the next module over or altering the interfaces. And I got that from that book.
\n\nThe other piece of advice is read, read, read. Go get a project, download it, and then read the architecture and go, oh, that's how you're doing that. And then put that project down, pick up another project, read it, and go, oh, wow, they're using recursion here instead of for loops. That's weird. And you go along for six months, and you start using recursion everywhere until your teammates have an intervention, and they pull you aside and say, "Dude, please just use a for loop here." And you realize, oh, there's a good place for a for loop, and there's a good place for recursion, and I'm using them everywhere.
\n\nAnd yeah, read as much code. Your ability to navigate an existing codebase is largely determined by how many different patterns you're familiar with. So go get a new piece of software, download it, read it, lather, rinse, repeat. And look me up in five years, and you'll be a whiz at it. You won't be a whiz at it in five months. You got to stack as many arrows in your quiver as you can.
\n\nAll righty, we're at the top of the hour. Thank you, guys, for coming. I really appreciate it. Kyle, Ramses, Eddy, this was a lot of fun. Be good until next episode. We'll talk to you guys later.
","summary":"","date_published":"2023-05-10T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/fabfacdc-201e-45b5-bc5b-c5aae5c22f61.mp3","mime_type":"audio/mpeg","size_in_bytes":39213262,"duration_in_seconds":2051}]},{"id":"8688641c-bfec-4717-918a-1f79f46cd894","title":"Episode 16: How Do You Break Up a Product Request Into Work?","url":"https://acima-development.fireside.fm/16","content_text":"Today we talk about how we break down work and what breaking work down means?\n\nTranscript:\n\nDAVID: Hello and welcome to the Acima Development Podcast. I'm your host, David Brady. And today we have an exciting panel. We have Eric Martinez, Ramses Bateman, Eddy Lopez, Mike Challis, and Jonathan Greiner. And we have one of our product managers sitting in the back. He says he doesn't want to join the call, but we might drag him into it. Because today we're going to talk about how we break down work. I'm kind of excited about this. I've got some ideas that I want to throw out, but I want to hear what you guys have to say. Just a cold start, how do you break down work, or what does breaking work down mean?\n\nMIKE: I can say that if you don't do it, then you break down. [laughter] You can break down the work, or it'll break down you. Several years ago, I worked on a project. We started as a group project. It was a special project day. We took a day...let's go work on something we want to work on. We extracted something. We made a lot of progress. And we wanted to keep on continuing with the project. I'm not going to go into details of the project; they're not important. \n\nBut somebody was left to continue the work, and this developer who was working on it had this huge project. And they said, \"Okay, well, I've got this huge body of work to do. So I'm going to work on a little bit over here and a little bit over there. And I'm going to come back over here and do a little bit, and then maybe over in the middle somewhere.\" And they just kind of touched a little bit here and there as they felt like it. \n\nAnd I watched that project, and two months later, very little progressed versus what it had been two months previous because all the complexity of trying to think about the entire project had to be held by the developer in their head. They're trying to think about the entire project. And so that lack of focus on individual pieces meant that it didn't ever get done. And this developer was capable and just hadn't taken the time to break down the work. \n\nSo we then took the project. We said, \"Well, let's do this differently.\" And that actually was a turning point in my career where I noticed just how important it is to break down every project into manageable pieces. I kind of take my own blame here because this was a less experienced developer. I should have stepped in [laughs] and been like, \"Let me help you.\" And yes, this is me not really realizing how much this was needed as well, and so it was a self-realization. \n\nAnd I realized, you know what? Every time I've got a project, if I don't break it down into small pieces I can think about, then I'm not treating myself like I'm a human. I'm treating myself like I'm something else, and I will fail. I need to break it down into pieces that can fit in my head. Me and the team I've worked with have taken the time tried to encourage this that when we see a project, to break it down into those human-sized pieces. \n\nAnd unless it's in a piece that you think that you can say, oh yeah, that's easy, you know, if I were to number this through 1 to 10...usually in development, we use a Fibonacci sequence so 1,2,3,5,8, 13. And the team, several teams that I've worked with have said, \"You know what? If it's above a three, it's not broken down enough.\" It means we haven't thought through it enough to break it down into a piece that I can fit in my head. \n\nAnd the teams that I've seen do this have been wildly enthusiastic about the results because you're looking at a mountain and saying, \"Okay, here's your spoon. Go dig it.\" It's completely impossible. It's so daunting you don't know where to begin. But if somebody instead says, \"Here's a molehill, and here's a shovel,\" you're like, okay, I can handle that. And there may be a million molehills, [laughs] but you can handle that. You can keep on shoveling those molehills all day, and it's very satisfying.\n\nDAVID: As always, Mike, you've thrown about five things onto the table that are sparkly and shiny, and I want to chase after them. There's a topic that's near and dear to my heart called cognitive load. And that's just...I like fancy words because I'm that way. [laughs] But cognitive load is a fancy technical term. The load is how much weight is resting on your brain if your brain was a muscle. \n\nAnd what breaking a project down does is it reduces the amount of cognitive load that any one piece takes up. And hopefully, you end up in a place where the cognitive load of each sub-task that you work on fits in your brain. You can pick up that task. You can hold the whole thing in your brain. You can lift it. You can carry it. You can get it done, and you can move on to the next one. \n\nAnd when we make the mistake of going over cognitive load, we often don't know that we've done it. The fun thing about the human brain, like, a microscope cannot look at itself. And most of the brain's ways of detecting problems about itself don't work. Like, the brain can't think; I mean, you can think roughly about yourself, but you can't actively perceive your perception. You can't perceive what's going on inside your head. \n\nSo I have had to learn tricks to tell externally what symptoms are happening in my life right now that might indicate that I am overloaded at some level in a way that I can't feel. When your judgment is impaired, the first thing that gets impaired is your ability to determine if your judgment is impaired, which is how we get ourselves into trouble. \n\nSo side tangent to this, I'm curious if you guys have had that experience of knowing when you're overloaded. And how do you get around it? Do you just go, oh, this is too hard to think about? Or are there specific things that happen in your day-to-day job that tell you, oh, I need to break something down, or I need to do something different? How do you tell if you're overloaded or if your task is too big? \n\nSo, okay, so that's kind of a scary question. It's like, how do we know this? It's invisible. I'm going to leave that for us to think on. I have some ideas. The one that Mike...that you said was two months went by, and nothing happened on the project. I've been that guy, and I've done that amount of nothing. And it was a lot of work to achieve that much nothing at the end of two months.\n\nMIKE: Absolutely. It's a ton of work to get there, yeah.\n\nDAVID: So when I see a long period of time go by, and there's nothing to deliver to the client or to my employer, and it is coupled with me having very high amounts of stress, especially if I start feeling impostor syndrome where I'm like, I shouldn't even be programming a computer; I got no business doing this, these are all signals to me that I'm trying to run it way too high of a gear, that I need to gear down. I need to cut my tasks into smaller and smaller pieces. I need to get more leverage on this because I'm just not grinding enough hamburger to feed the family. I'm trying to do too much. \n\nI'm going to be all over the floor with metaphors today. Good luck, guys. [laughs] But you're not getting enough done. And so when a long period of time with no progress and very high stress, but importantly, during that entire time, I have this belief that I should be making progress. If you drop me into a brand new project, greenfield go build this thing from scratch; I'm kind of okay if some lead time doesn't produce anything. I expect it, then. But if the project is underway and has momentum and we kind of know generally what happens next, and then I get nothing done for a day, or 3, or 20, that's one of my big tells.\n\nMIKE: I think what you're saying is practically true.\n\nDAVID: Oooh.\n\nMIKE: Like, it's true at the large scale. You get two months in, like, wow, this project is going slow. My team has been working on this huge project or my team of teams. Our company has been working on this project for a year, and it's not making any progress. What have we done wrong? Or I have been working on this for three months, and I'm not making any progress. What have I done wrong? Or I've been working on this for two hours. What have I done wrong? And I'm not making any progress. What have I done wrong? \n\nI think that the scale is somewhat insignificant, but you call that something vitally important. When you notice that you're not making progress, you're generally doing some sort of loop. You're wandering through the woods, and you're like, wait, haven't I been here before? Well, you probably have because people aren't very good at walking straight, [laughs] and so we tend to just walk in circles. Well, the same thing happens in your code, in your cognitive work, whatever it is, I think. \n\nIf you find yourself not making any progress, you're probably in a loop where you're just kind of banging away on something, stepping away, and you're banging away on the same thing and not making any progress. And that suggests that it's time to rethink your assumptions and your process.\n\nDAVID: I like that you scaled that all the way down to some tiny thing that you thought was going to take five minutes. It's two hours later, and you've gotten nowhere with it. We talk about things that block tickets, like, when do we run into a blocker? And the original idea for stand-up meetings was this idea that you say what I did yesterday, what I'm working on today, and you raise visibility on anything that's blocking you from completing what you have to get done. \n\nAnd the funny thing that I learned there is that the blocker is almost never something that you anticipated because if you anticipated it, then you say, \"Well, what I'm working on today is this thing that has to be done before...\" it's not a blocker. I know it's on my to-do list. And blockers, at least for me, they tend to blindside me. It's not like, oh, I need to write this database code, but I don't know the syntax for this new version of the database. It's never that. \n\nIt's, oh, I need to write this database code, but there's a person in the chain that I have to physically have a meeting with and talk to them face to face. And I have no idea who this person is. I don't know where they..., and so I spend like two hours trying to chase down this weird side task. \n\nOr it could be in software, but it's, you know, oh, I have to track down this device driver for Linux so that I can even talk to the network towards the database because it's got some weird security protocol or something like that. And you end up just going down this rabbit hole chasing weird side things that you keep getting blindsided, and you keep getting rolled over by this and that for me is another big time. \n\nSo when I get blindsided, I often don't know I've been blindsided. I think, oh, I'm just chasing the next prerequisite to finish this ticket. And then yeah, two hours go by, and you're like, wait a minute, I bid zero points on this ticket. I thought it was going to be a five-minute chore with essentially no impact to the schedule. But here it is; I've burned most of my morning. What's going on? And like, oh, hey, everybody, did you know we need this TLS driver on Linux to talk to the database? Uh, no. Now you can raise some visibility and say, \"This is what's going on.\"\n\nMIKE: There's so much there that's valuable. I saw an article once that I think made a bit of a splash on Hacker News or something, but I'd have to go track down the reference. I don't have it in front of me. The article made this...I think it was just a blog post. But they made an assertion that the way that our work as developers...it probably applies to other cognitive work as well and probably even real physical world work. The way that the size of a project scales is nowhere near linear. And the trick is complexity. \n\nIf you look at something and there's a lot of complexity in there, there's a huge amount of unknowns. And then you get into all those tangles. You get in with one tangle after another. And a better measure than trying to say, \"Oh, this is going to take five days...\" we're actually really terrible at that because there's a difference between ways of calculating the midpoint. If you've got a set of numbers, you can say, well, the mathematical average or the arithmetic average, I should say. \n\nSo you add the arithmetic mean. You add them all up together, then divide by the number of things. You get some number in the middle. Well, that's one way of calculating which number is in the middle. And let's hold that for a second. That's one way of calculating the middle, and we call that the mean. \n\nAnother way is to line up all the things and pick the one in the middle. That's your median. And usually, if you have kind of a random data set, they're about the same thing. But if you have a highly non-linear scaling, you have one thing that takes 5 minutes, and another one takes 10, and another one takes three weeks; another one takes a year; maybe your median is 2 hours. And your mean is six months. And that wild disparity between your median and mean means that we're really bad at giving estimates because we tend to estimate the median and not the mean. And complexity can throw this huge, enormous wrench in the works that makes things take orders of magnitude longer. \n\nSo when you're estimating [laughs], you need to remember that you're almost certainly going to get wrong on the mean. You're probably going to be pretty good on the median. And one way to deal with that is to break the work down into smaller pieces so that on each one, you can kind of define the complexity and eliminate the possibility of some of those gotchas. It makes much better predictions.\n\nDAVID: Wow, there are two big things that I love for that. The first one is that anytime you're trying to do a linear approximation of an exponential curve or a curve that just curves, something that doesn't go in a straight line, you end up with this dip below the center of the line and the ends usually shoot up past the ends of the line, and you end up way off everywhere, except for where the line accidentally crosses your curve. \n\nThe best illustration I've heard for this is that if you line up all the humans in the world and order them by the number of appendages that they have, the average human has about 1.99 arms, but the median human has exactly 2. In fact, you can go 80%-90% all the way up the curve, and 80-90% of the population have two arms. But there are people at the end of the curve that are throwing off the mean. If you drew it on a chart, you'd have this long flat bit and then a curve right at the end. \n\nAnd if you try to draw a line from the top of that curve down to the bottom on the other side where everybody has exactly two, that line is never correct, except for the very, very beginning when you take that very first human, and you go, you have two arms, great. And you're the only one here, so the average is now two; great, carry on. And then, the longer you go, the more your estimate drifts.\n\nMIKE: I found the original reference, by the way. His name is Erik Bernhardsson, and it's definitely worth looking up. If you look up his --\n\nDAVID: Can you spell Bernhardsson? There's like three ways to spell half of the sub-words in the name.\n\nMIKE: Yeah. Erik with a K, E-R-I-K, and it's Bernhardsson, B-E-R-N-H-A-R-D-S-S-O-N.\n\nDAVID: S-S-O-N, okay.\n\nMIKE: S-S-O-N. And I just googled software estimation median mean, and he comes up at the top because, like I said, it made a bit of a splash. Read that blog post, and I think you'll think about estimation differently forever afterwards in a better way because you'll recognize some of the gotchas.\n\nDAVID: The other thing that you said that really hooked my brain there is this notion that as we get further and further away, something gets bigger and bigger. The difference between the curve and the line gets worse and worse and worse. I love the Fibonacci or even the exponential curve. I've gotten good mileage out of just doubling the estimates 1,2,4, 8, 16. And both of these, the Fibonacci curve and the exponent, we look at this as like, oh, the job gets bigger, much bigger, much faster the bigger it gets. And no, it doesn't. \n\nIt's just that our ability to be precise falls off exponentially. So if you've got something that's bigger than eight on a Fibonacci, that's what? Five, then 8, so 13 is the next one. On a Fibonacci sequence, if you've got something that's 8, you can't estimate a 9. You just can't. You try to estimate a ten you can't see your yardstick that you're holding up. It's really hard to tell if there are one or two full yardsticks. You're off by a full meter. So estimated down to the inch is an exercise and a folly.\n\nMIKE: Absolutely. It's that, you know, the degrees of precision. The digits of precision are important. Maybe you can take the digits of pi out of 20 significant figures. But most of our measurements are nowhere near that precise. And suggesting that they're more significant figures than you are is actually going to give you bad information. It's suggesting a level of confidence that's wrong. \n\nUsually, we're much closer to those polls that say, \"Oh, plus or minus five percentage points.\" [laughs] It could be, you know, I'm going to give no decimal points at all, and I'm still probably off by 5%, you know, within about a 10% range. I felt like I did pretty good at that. That's far more likely, and honestly, our error bar is usually a lot bigger than that. \n\nDAVID: Exactly. There's a fun thing that you run into if you're trying to put information out of the United States against scientific data coming from anywhere else in the world. And you will often find...especially if it's meant to be consumed by the average person rather than by scientists because if it's by scientists, it's all going to be a metric. And if it's going to be by the average person, you're going to see something like, oh, we heated this water to exactly 39.214 degrees centigrade. And you're like, wow, that's really precise. No, it's not really precise. That was just 99 degrees Fahrenheit. And don't quote me on that. I didn't actually check those numbers. \n\nBut you end up with, like, oh yeah, no, we were just rounding to 100 degrees Fahrenheit, plus or minus 10 degrees. But somebody just slavishly copied over 100 degrees Fahrenheit is exactly 38 point dot, dot, dot, and however many decimal places. And they copied up to five decimal places. And you're like, wow, that's super precise. No, no, it isn't. It's terrible. \n\nMIKE: Which goes to this idea of breaking down work that you got to estimate loosely. I will make an observation here. A lot of times, we look at that and say, well, then estimation is stupid. [laughs] Why should I do any estimation at all? I've probably had times in my life when I thought that, but I've changed my perception on this because I do think that project estimation is useful, but not always for the reasons that you'd expect. \n\nDAVID: There's an entire school of thought called no estimates, and it's a sub-genre or a sub-flavor of the agile movement. And there are some people that I really, really love and respect that really champion this idea, and I have not extracted that information from their brain. I just want to put a pin in that, Mike, because I think we ought to circle around to this in a future episode, maybe even trick one of those experts to come on and talk to us about no estimates, about why they think it's good and what problems that solves. \n\nSorry for interrupting you. I want to put that pin in there and then say what you and I have certainly found is that, no, estimates are good. They help us achieve what we...or we think they help us achieve what we want.\n\nMIKE: Well, let me say that I think that they are terrible in general for telling whoever wants to know when it's going to be done that it's going to be done. But they're pretty good at telling us the scale of complexity of the work. If we look at it, and we can say it was, oh, that's pretty big. I'd say that's five. Well, then, we know that it's beyond what we understand at the moment. It doesn't fit in our head.\n\nTYSON: And I think the other value of estimates is it helps planning. This is taking it to a more larger sense of a business scale. But if we can give the estimates, it lets us plan for the future of what's most valuable based on the estimate.\n\nMIKE: Well, and what it does, it might not give you an exact date. But if we went to a project and we say, \"That's kind of big,\" that gives you one thing, but if you go in and you say, \"Well, I have these size two pieces, and there's 50 of them,\" well, that's far more precise. It doesn't give you a number of days, but it gives you a very good sense of the scale of the project. And actually, if you get in the habit of doing this as a team, of making these estimates, then you can actually sometimes map it to days not too badly if you've broken it down to that level. \n\nIt's a ton of work, and you don't do that until you're ready to work on it. But at that point, you can get actually...I've seen teams come within a couple of days, like two or three months out, when they estimated this way. It took over a week to come up with the estimation. So it's very expensive if you're going to plan out very far. You don't ever want to do this unless you're committed.\n\nDAVID: I would also wager that the team that did those estimates has been working together for months and months or years. \n\nMIKE: Years.\n\nDAVID: And they can reliably...years, exactly. You can reliably say, \"This is going to take Mike two days. And this is going to take Dave two weeks.\" You can literally go through things and say, \"Yeah, we know as a team we have a collective sense for how long this is going to take.\"\n\nTYSON: I think it's also important to remember these are estimates. And so you have to be pretty flexible to say, you know, if we're going to put a date on it, like, oh, it's going to be two weeks, but then also realize we gave an estimate. And if you go past that, okay, that's fine, and we can re-adjust and plan accordingly. There's so much value on an estimate, and you can use it as kind of a guiding light, but also, you can go off trail, and you're okay with it.\n\nDAVID: There's a planning tool called Pivotal Tracker that some of our listeners are probably going to be familiar with. My favorite thing about Tracker is that it is continuously giving you an estimate. Basically, it says if you keep moving at the rate you're moving, then you're going to finish exactly on this day because you've put all the tickets into the system, which we can talk about why that's a bad idea. [laughs] But Pivotal always knows; Tracker always knows how long it's going to be until you finish. And it's important to not go...by the way, to the listeners, that's Tyson Novakovich. That's the product manager that I was hoping to get to talk on this call. So I'm very, very happy. Welcome, Tyson. \n\nTracker will tell you you're going to finish on March 23rd of, 2025. And you do not walk out of there going, oh yeah, we are totally going to finish this. Because every time you complete a job, Tracker goes, oh, you said that was going to take eight hours, and it took you seven. And your estimate moves from March 23rd of 2025 to February 15th of, 2025. And you're like, whoa, I just jumped the schedule by two weeks. And well, yeah, because when you estimate an eight, it takes you seven, and Tracker keeps track of that. \n\nAnd it's always giving (I learned a term just yesterday.) a good faith estimate. And what this is is you're basically telling management, this is when I think I will be done, but please, please, please remember, every single day, I find out something new. I find out things that I thought were solved that we're going to have to figure out how to do. I found this piece. We've got this entire chunk of time dedicated to figuring out how we're going to talk to the Postgres database, but halfway through the project, somebody came in and said, \"Oh no, we're going to throw it straight into the data lake. I want you to talk to Amazon Redshift instead.\" \n\nAnd now this entire sub-module of put it into Postgres, which, by the way, everyone on the team is fluent in, now it's put it in this data lake. It's going to be way more powerful. There are all these problems that we were anticipating with Postgres that just go away because we're throwing this entire cluster of cloud databases at it. But also, nobody's familiar with it. And so we've removed this big known problem and, oh, look, our estimate goes way down. Look at that; we're going to finish in 2022. No. No, you're not because we just threw this big thing in there, this gigantic unknown.\n\nSo every single day, my point is, every single day, we're going to management and saying, \"This is the good faith estimate. Don't buy ad space for the shipping date on that day unless you're willing to cut features. Because every time we take a step forward, we find new problems, and you guys add new features.\" Hey, wouldn't it be great if...Can we add this? Sure, sure, you can. Drop it into the system. And here's your new good-faith estimate. \n\nAnd it's never a promise of when we're going to finish. It is a calculation of if everything stays the same; this is about when we'll finish. And unless you've been on a team like the one Mike was describing, where you've worked together for years, and you collectively know about how big the work that team can wrestle to the ground in how much time, you're going to be way, way, way, way, way off.\n\nMIKE: We could easily dive deep into this estimation. I think we should probably save that for a different...We're talking about recognizing how to break down projects. \n\nDAVID: Yes. But in theory, the topic for today is how to break stuff down, and we haven't gotten to the how. We're just talking about the why. And are you sure you need to? How do you know when you've missed it? [laughs]\n\nMIKE: It is a huge deal because it is a part. Because if you start by developing this ability to estimate some...how big is this for me? Then you can get a sense of the scale of the problem. And I think that that's actually one of the first steps. Until you get a sense of the scale of the problem, it's really hard to break it down. \n\nIf you have something that really is going to take you five minutes, if you spend two weeks breaking that down into the sub-components, well, you've wasted some time. But if you have errors and you take five minutes on it, say, oh yeah, we'll get that done, well, then you have not spent nearly enough time. [laughs] So, some assessment of the scale of the problem, I think, is an excellent starting point.\n\nDAVID: I like that. Very importantly, revisit that scale. So many projects I've worked on, I've said, \"Oh, we're going to build this over six months. We've got these really big unknowns. But let's assume that these unknowns are going to shake out this way, this way, and that way.\" And then you go into Jira or whatever case management system you've got, and you enter in great big epics for all of those big things. And the problem is three of those epics end up never happening. And there are three hidden epics that never got put into the system. \n\nAnd you will go four, five months in...I've seen teams slavishly build those three epics that we originally predicted on day one because we never circled back. We had this great, big meeting where we tried to break everything down in advance. And the problem is we broke things down. We were breaking things into ones and twos, but they were four months out where we had no business breaking anything smaller than an eight because we don't even know if we're going to do this. This might be a zero because it vanishes from the schedule entirely. \n\nMy point there, revisit the grand scale of the thing. Don't just have one big meeting. Having a big meeting is fine. That's what I'm saying. But have that meeting again. Don't think that meeting is done and done forever and that you're never going to circle back. You need to circle back and say, okay, our good faith estimate has changed by this much. Why? What's changing, and what do we need to put on here? \n\nAnd you have another big meeting, and you go through everything that's left to do, and your good faith estimate changes. I'm not a huge proponent of big meetings. But sometimes, they are a bad, bad solution, but they are sometimes the best solution. You might not have a good solution to something, a big meeting for me is that.\n\nMIKE: Okay. So you get the people together. You get an assessment of the size of it. And then what comes next? I read a book. This was in \"Team Topologies.\" Well, I listened to it somewhat recently. And it talks about how teams ought to be structured, and they give this great idea. If you look at particularly sedimentary rock, it has these natural layers, these strata. And so there are natural fracture lines. This is true of other kinds of rock too. There are seams within the rock. And a skilled stonemason, and times have passed, but probably still today knows how to exploit those seams to split the rock in the way that they want.\n\nThey're not going to go and just start banging on the rock and hope that it breaks into half. Instead, they're going to study the rock. What are the seams here? Where are the natural lines that it would split? And let's look for one of those just splitting the rock because then it's going to split cleanly. Well, I think that we need to look for those natural fracture lines in the work. So we say, oh, we got this huge project. Well, what are some natural components here that we can start to break it down on? What do you think of that idea?\n\nRAMSES: I think those are interesting points. I often think about how important it is to understand the requirements before even starting a project. And then, if you're working with a sub-team, we're finding those requirements so each member of the sub-team understands those requirements. And what often happens or has happened is requirements change mid-project. And as long as those new requirements are discussed, just having clear communication and refining those requirements, like, constantly refining those requirements, helps to move a project forward, I think. And it makes it easy to break down a project and think about a specific component of that requirement.\n\nDAVID: I like that. Try not to lose track of what is it exactly that we're trying to build. Don't get so laser-focused on what you are building and say, oh, I'm building the database adapter. And then you peel off for six months trying to write a general-purpose universal database adapter when it turns out we just needed to be able to do two queries and an insert. We didn't need to do anything else.\n\nMIKE: It's interesting that you focus so much on understanding and shared understanding as well. Developing that shared understanding you said was critical to breaking it down because if you haven't gotten some understanding first, it's not going to work so well. \n\nRAMSES: Yeah, it's hard to solve a problem if you don't understand it, like, why it needs to be solved. Because the product or the business can say, \"Oh, solve this,\" and if you don't know the intention or how the end user is going to be impacted...\n\nMIKE: So every product manager out there listening or in the call, [laughs] if we don't understand the problem, we can't build it. So your work is invaluable, and it's about helping us understand the problem. You can bring the engineers a description of the problem. We don't really need to know how to solve the problem; that's what we do. But if you can bring us a description of what the problem is, a succinct and actionable description of a problem, here's the goal, here's the problem, here's what we want to solve, we'll know it's solved because of this, that is what engineers live on, a problem that's well-described that we can go start working on. \n\nTYSON: I wanted to...I think one thing you said, Mike, about the stonemasons looking for the key part of the stone to aim for, is when I hear that, I think of, well, that's how we aim for MVPs. If we have a big massive problem or project that we're trying to do, what's the MVP or the minimum amount of work that we can do to get to solving the problem? And then, from there, breaking out smaller parts of the project to improve upon the MVP. But MVPs are super valuable, and it may not be the most polished thing ever, but we're going get something out that solves the problem that we're trying to solve for.\n\nDAVID: I love that. I've got MVP in my notes here, the minimum viable product. And I was hoping somebody would bring this up because at the very top of the call, when we said how do we break down work, the two things that my brain immediately jumped to are, let's treat this like a rope and slice the rope into pieces just from one end...We'll treat it like a loaf of bread and slice each slice up from one end to the other, working your way from one side to the other. \n\nWhere MVP, the minimum viable product, you sit down, and you go, what is the first thing the system needs to do to be considered not complete and feature complete but like, what's the very first thing the system needs to do to tell us our idea could ever possibly work? So it's like, I don't need to insert and delete from a database. I just need to connect to the database. That's arguably not a viable product. It's certainly not for the 1.0 of the thing we're trying to build. \n\nBut the first time I do this, I need to connect, and the second time, I need to hand a query to the database where I can just gin up this entire long string and just shove it at the database. Eventually, I'm going to have to build this whole adapter layer that can take these objects and spread them out and turn them into that query. \n\nBut I like the MVP because you kind of like take one corner of the...like, if the project is this great, big rectangle, you take one corner of it, and you just slice a little circle, you know, slice one corner of it out and you say, \"This is my product.\" And then you slice another piece and another piece, and you just keep sticking them onto the thing that you've built. \n\nAnd from the get-go, you have something that doesn't do everything you need, but it does something. And you can test it, and you can verify to yourself from now until the project is finished; everything we've done up till now still works. I can still connect to the database when I put this piece. I really, really like that. It gives me a lot of safety and security to know that something I just built didn't ruin everything we've built up.\n\nMIKE: Do you remember when the iPod came out? \n\nDAVID: Mm-hmm.\n\nMIKE: How well was it critically received?\n\nDAVID: Oh, that part, I don't remember. \n\nMIKE: It was widely -- \n\nDAVID: Actually, I do. Penny Arcade is a webcomic that I used to read. And the way that I loved it was you could buy...at that time; you could buy a Discman, which is a CD, portable CD player. You could buy one of these for $29. And the iPod was $300, if I recall correctly. And people were like, \"Oh, but when you listen to music in digital format, it never skips.\" And the Penny Arcade strip that I remember, he says, \"My Discman doesn't skip either because I padded it with $270 of cash to keep it from bouncing around. [laughter] I'm using dollar bills as packing material.\" Yeah, it was a terrible idea.\n\nMIKE: Everybody thought, like, critics said, \"It doesn't have nearly the features of its competitors. All it really has going for it is it looks nice, and it's got an easy-to-use interface. But who actually goes out and buys and listens to music?\" Well, it's like teenage kids who don't want to go and figure out a complicated nerdy interface to listen to their music. If they can press some buttons and easily get to where they are and play it, that's all they care about. \n\nAnd that product was probably embarrassing to a lot of engineers who built it because it did almost nothing. You'd put a few songs on it, and you'd press play. Well, they iterated on that. They came out with a consumer product. Apple was not when that thing came out, the behemoth they are today. They were trying to recover. And they came out with this consumer product that was kind of outside of the normal things they'd been doing. And they just sold these kinds of weird computers. And they came up with a smaller consumer product to test out the market. Well, it worked. \n\nThey put out this minimal product that was good enough for some people to buy it. They didn't put out a massive smartphone that had three cameras on the back. They put out a thing that would play some songs. And you could press kind of like play and pause, and that's about it. And then they made it a little bit better, and then made it a little bit better. \n\nAnd a few years later, they said, you know what? What if we take the same idea and we apply it to phones? And they birthed a whole industry and have come to dominate it and become what? At least at this time, the most valuable company on earth. Because they started with that incredibly simple minimum viable product, I think that should be a strong lesson to all of us. \n\nDAVID: There was a lovely sea change that happened in the world, not just in the industry but in the world where prior to the iPod coming out, we generally consumed our music in albums. You would go buy a cassette or a CD, and you would throw that chunk of physical media into your player. And those were the tracks that you had available. So you listened to the album in the way that the producer layered the tracks. Like, bands used to stack their songs in an order that we're going to come out of this song and into the next one. What DJs do now bands had to do with their own music and present it to you in that format. \n\nBut all of a sudden, people are now doing...they're arranging their music into a thing called a playlist. And I had never done that prior to this. I was a stick in the CD; oh, I'm going to do this work today. ELO \"Time\" is going to be a good album to listen to today. And all of a sudden, I'm sitting at my computer, and I'm dragging all the tracks out in order that are all 170 beats per minute because I've got to really knuckle down and work really hard, really fast, really intense, and I need some really fast music. \n\nAnd all of a sudden, I'm throwing in classical music, and I'm throwing in heavy...it's like when you come out of Vivaldi's \"Four Seasons\" and run straight into Rob Zombie. It's a little bit of a whiplash. But it worked because they were the same BPM which no producer has ever put together. Well, I'm certain that's wrong because now people can go buy an album that's just running music, and you literally buy the album at the BPM that you want. \n\nBut the playlist, the idea of you're going to sit down and figure out what you want to listen to in advance. And now you strap the iPod on, and you just push the big red play button, and that's the only button you need. And that was a sea change. Prior to that, we needed the seven different controls because I love this album, but I can't stand this track. I've got to be able to skip over it whenever I want.\n\nMIKE: A fundamental change in the industry was sparked by people just simplifying, by the engineers saying, \"What's the bare minimum we can do?\" And it forced a rethink of the interfaces and the way we even think about the problem. Well, we're talking about how to break down a problem, and if we don't start there, we're probably doing it wrong. We have to start, like, what is the bare minimum we can actually do? And it may force us to challenge our assumptions to say, \"Well, what can we really get away with here? What can we really cut?\" And maybe there's a lot more than we thought that we could. \n\nAnd if you're not being uncomfortable with the cutting, then you're probably leaving the project too big. You need to truly make it minimal, or else there's some of that complexity that's going to kill you. That non-linear complexity is going to make it take way longer than you expected. You need to shave as much of that as you possibly can to get something really tiny because if you get that really tiny goal, it's achievable. \n\nAnd once you have something that works, well, now you've got something where before you had nothing. So that jump from nothing to something is the hardest part. And then you repeat and say, \"What's the next minimum thing I can add to this that actually provides value?\" And you aim for that. And you just put it on repeat. [laughs] You put that, and you do that in a cycle.\n\nDAVID: I worked with project managers 15-20 years ago who told me to my face, \"There is no minimum viable product.\" I must have every single feature down to 100% completion, or the entire project is worthless. And I opened up the project, and there were like two weeks spent polishing the user interface. And I'm like, this is...no, we need to teach you what an MVP is at this point. \n\nI love that you said if you're not feeling uncomfortable while cutting features, you're not cutting enough. You have to remember; you're not saying we're never going to build this; you're just saying I'm not going to build this now. We're not going to sell this to a customer without this piece. But can we stand it up and prove to ourselves that it works right now, is useful? \n\nThe phrase that I like that's related to the uncomfortable one. I think it actually used the word ruthless, which is kind of like the mental image of a programmer just head down, looking up at you through the eyebrows with an evil smile and basically saying...the phrase that I loved was every feature must fight for its life, or it does not get to live on the project schedule. That's what you should be asking when you're trying to figure out an MVP. Look at any feature and then say, \"Can we just not? How much of this can we not do and still move forward?\" I love that idea. \n\nIf you're taking the slice of bread analogy and you've got to move data from...okay, this is a terrible mixed metaphor. You got to move data from one end of the loaf to the other, [laughs], but you've got these layers. You've got to move...you got the user interface layer. You got the client layer. Then you got like the middleware, and then you got the back end, and the backplane, and the messaging system, and the data system. You got all these layers. \n\nIf you have somebody sit down and say, \"We have to build this slice of the project. It has to be 100% complete before we can move on to the next slice,\" I promise you that person is wrong, and you are looking at the project the wrong way. That's the maximum viable product is to finish that layer 100%. What's so much better is to take one tiny little core sample of that slice of bread, and then build the core underneath in the slice below it, and then build the core of that under the next slice below that. \n\nAnd eventually, you end up...it doesn't look like a loaf of bread. It looks like a string of beads from one end to the other. And you can't run any useful data through it, but you can run a ping and get a pong back. And that pong came from the database server, which was on the other side of the network, which was through the enterprise backplane, which was through the messaging system, which was through the back-end front-end middleware all the way up to the client. And that first time you get that pong actually coming out of the database server, it's very exciting as a programmer. I love that.\n\nMIKE: It gives you the skeleton that you can start building on. \n\nDAVID: Yes.\n\nMIKE: When they build a house, they don't start with the siding. They build the frame. And that's not how houses have to be built. They can build the kitchen, and they could finish it and put all the flooring, you know, paint the walls, put in the cabinets. You get that done and then move on to the next room. But nobody does do that because it doesn't work out very well for a project. \n\nIf you can build out that skeleton, then there's stuff to hang everything, stuff to hang your sheetrock, stuff to hang everything else. You can start to work in parallel once you've got that frame. And you can see it and have an organizing idea. And getting up that skeleton is a huge turning point for the success of the project.\n\nDAVID: Absolutely. You absolutely can paint the wall before you build the wall. I realized that sounds bizarre and weird. But you don't want to just sit down and stretch a tarp over the wall and then paint the tarp. That's not how you want to do that, but you can. There are people who do critical path analysis, and they figured out that you can build a complete house with foundation, and cement, and electrical, and finishing work in like 18 hours of continuous time. We started at this time, and 18 hours later, we were done. \n\nBut yeah, the walls were assembled on the ground, and the primer coat was put on the walls while they were still on the ground, and absolutely, you can do that. But it's a really weird way to work. And you have to know exactly every messy, little side tangent, and in software, we often don't have the luxury of that. So it's much, much better if we can just go; let's dig the foundation and find out are there any pipes that we have to work around? And, okay, let's pour the foundation and find out any problems we've got there. And it's much easier to paint the walls once they've been built. \n\nI feel like we now need to do another episode on actually how to break stuff down, [laughs] like how to break something into an MVP and what constitutes an MVP. There are still some open questions here. But Ramses, or Eddy, or Tyson, is there any kind of a coda that you think that we either need to touch on or that you touched on really well?\n\nTYSON: I think it's much of the how, but I think even with the project itself is the why of it. And so really covering all our bases on the why we want to break things down is equally as important as the how. It's a good overarching summary of what we talked about today.\n\nDAVID: Awesome. Gentlemen, thank you. This has been the Acima Development podcast. And, Mike, we'll have to talk about maybe splitting this...maybe changing the title into why break things down and then maybe circle back. I think that would be a fun segue. Or maybe we'll just call this the how and let people extrapolate from what we've said. Thanks, everyone, for joining, and we'll see you next week or in a couple of weeks.","content_html":"Today we talk about how we break down work and what breaking work down means?
\n\nTranscript:
\n\nDAVID: Hello and welcome to the Acima Development Podcast. I'm your host, David Brady. And today we have an exciting panel. We have Eric Martinez, Ramses Bateman, Eddy Lopez, Mike Challis, and Jonathan Greiner. And we have one of our product managers sitting in the back. He says he doesn't want to join the call, but we might drag him into it. Because today we're going to talk about how we break down work. I'm kind of excited about this. I've got some ideas that I want to throw out, but I want to hear what you guys have to say. Just a cold start, how do you break down work, or what does breaking work down mean?
\n\nMIKE: I can say that if you don't do it, then you break down. [laughter] You can break down the work, or it'll break down you. Several years ago, I worked on a project. We started as a group project. It was a special project day. We took a day...let's go work on something we want to work on. We extracted something. We made a lot of progress. And we wanted to keep on continuing with the project. I'm not going to go into details of the project; they're not important.
\n\nBut somebody was left to continue the work, and this developer who was working on it had this huge project. And they said, "Okay, well, I've got this huge body of work to do. So I'm going to work on a little bit over here and a little bit over there. And I'm going to come back over here and do a little bit, and then maybe over in the middle somewhere." And they just kind of touched a little bit here and there as they felt like it.
\n\nAnd I watched that project, and two months later, very little progressed versus what it had been two months previous because all the complexity of trying to think about the entire project had to be held by the developer in their head. They're trying to think about the entire project. And so that lack of focus on individual pieces meant that it didn't ever get done. And this developer was capable and just hadn't taken the time to break down the work.
\n\nSo we then took the project. We said, "Well, let's do this differently." And that actually was a turning point in my career where I noticed just how important it is to break down every project into manageable pieces. I kind of take my own blame here because this was a less experienced developer. I should have stepped in [laughs] and been like, "Let me help you." And yes, this is me not really realizing how much this was needed as well, and so it was a self-realization.
\n\nAnd I realized, you know what? Every time I've got a project, if I don't break it down into small pieces I can think about, then I'm not treating myself like I'm a human. I'm treating myself like I'm something else, and I will fail. I need to break it down into pieces that can fit in my head. Me and the team I've worked with have taken the time tried to encourage this that when we see a project, to break it down into those human-sized pieces.
\n\nAnd unless it's in a piece that you think that you can say, oh yeah, that's easy, you know, if I were to number this through 1 to 10...usually in development, we use a Fibonacci sequence so 1,2,3,5,8, 13. And the team, several teams that I've worked with have said, "You know what? If it's above a three, it's not broken down enough." It means we haven't thought through it enough to break it down into a piece that I can fit in my head.
\n\nAnd the teams that I've seen do this have been wildly enthusiastic about the results because you're looking at a mountain and saying, "Okay, here's your spoon. Go dig it." It's completely impossible. It's so daunting you don't know where to begin. But if somebody instead says, "Here's a molehill, and here's a shovel," you're like, okay, I can handle that. And there may be a million molehills, [laughs] but you can handle that. You can keep on shoveling those molehills all day, and it's very satisfying.
\n\nDAVID: As always, Mike, you've thrown about five things onto the table that are sparkly and shiny, and I want to chase after them. There's a topic that's near and dear to my heart called cognitive load. And that's just...I like fancy words because I'm that way. [laughs] But cognitive load is a fancy technical term. The load is how much weight is resting on your brain if your brain was a muscle.
\n\nAnd what breaking a project down does is it reduces the amount of cognitive load that any one piece takes up. And hopefully, you end up in a place where the cognitive load of each sub-task that you work on fits in your brain. You can pick up that task. You can hold the whole thing in your brain. You can lift it. You can carry it. You can get it done, and you can move on to the next one.
\n\nAnd when we make the mistake of going over cognitive load, we often don't know that we've done it. The fun thing about the human brain, like, a microscope cannot look at itself. And most of the brain's ways of detecting problems about itself don't work. Like, the brain can't think; I mean, you can think roughly about yourself, but you can't actively perceive your perception. You can't perceive what's going on inside your head.
\n\nSo I have had to learn tricks to tell externally what symptoms are happening in my life right now that might indicate that I am overloaded at some level in a way that I can't feel. When your judgment is impaired, the first thing that gets impaired is your ability to determine if your judgment is impaired, which is how we get ourselves into trouble.
\n\nSo side tangent to this, I'm curious if you guys have had that experience of knowing when you're overloaded. And how do you get around it? Do you just go, oh, this is too hard to think about? Or are there specific things that happen in your day-to-day job that tell you, oh, I need to break something down, or I need to do something different? How do you tell if you're overloaded or if your task is too big?
\n\nSo, okay, so that's kind of a scary question. It's like, how do we know this? It's invisible. I'm going to leave that for us to think on. I have some ideas. The one that Mike...that you said was two months went by, and nothing happened on the project. I've been that guy, and I've done that amount of nothing. And it was a lot of work to achieve that much nothing at the end of two months.
\n\nMIKE: Absolutely. It's a ton of work to get there, yeah.
\n\nDAVID: So when I see a long period of time go by, and there's nothing to deliver to the client or to my employer, and it is coupled with me having very high amounts of stress, especially if I start feeling impostor syndrome where I'm like, I shouldn't even be programming a computer; I got no business doing this, these are all signals to me that I'm trying to run it way too high of a gear, that I need to gear down. I need to cut my tasks into smaller and smaller pieces. I need to get more leverage on this because I'm just not grinding enough hamburger to feed the family. I'm trying to do too much.
\n\nI'm going to be all over the floor with metaphors today. Good luck, guys. [laughs] But you're not getting enough done. And so when a long period of time with no progress and very high stress, but importantly, during that entire time, I have this belief that I should be making progress. If you drop me into a brand new project, greenfield go build this thing from scratch; I'm kind of okay if some lead time doesn't produce anything. I expect it, then. But if the project is underway and has momentum and we kind of know generally what happens next, and then I get nothing done for a day, or 3, or 20, that's one of my big tells.
\n\nMIKE: I think what you're saying is practically true.
\n\nDAVID: Oooh.
\n\nMIKE: Like, it's true at the large scale. You get two months in, like, wow, this project is going slow. My team has been working on this huge project or my team of teams. Our company has been working on this project for a year, and it's not making any progress. What have we done wrong? Or I have been working on this for three months, and I'm not making any progress. What have I done wrong? Or I've been working on this for two hours. What have I done wrong? And I'm not making any progress. What have I done wrong?
\n\nI think that the scale is somewhat insignificant, but you call that something vitally important. When you notice that you're not making progress, you're generally doing some sort of loop. You're wandering through the woods, and you're like, wait, haven't I been here before? Well, you probably have because people aren't very good at walking straight, [laughs] and so we tend to just walk in circles. Well, the same thing happens in your code, in your cognitive work, whatever it is, I think.
\n\nIf you find yourself not making any progress, you're probably in a loop where you're just kind of banging away on something, stepping away, and you're banging away on the same thing and not making any progress. And that suggests that it's time to rethink your assumptions and your process.
\n\nDAVID: I like that you scaled that all the way down to some tiny thing that you thought was going to take five minutes. It's two hours later, and you've gotten nowhere with it. We talk about things that block tickets, like, when do we run into a blocker? And the original idea for stand-up meetings was this idea that you say what I did yesterday, what I'm working on today, and you raise visibility on anything that's blocking you from completing what you have to get done.
\n\nAnd the funny thing that I learned there is that the blocker is almost never something that you anticipated because if you anticipated it, then you say, "Well, what I'm working on today is this thing that has to be done before..." it's not a blocker. I know it's on my to-do list. And blockers, at least for me, they tend to blindside me. It's not like, oh, I need to write this database code, but I don't know the syntax for this new version of the database. It's never that.
\n\nIt's, oh, I need to write this database code, but there's a person in the chain that I have to physically have a meeting with and talk to them face to face. And I have no idea who this person is. I don't know where they..., and so I spend like two hours trying to chase down this weird side task.
\n\nOr it could be in software, but it's, you know, oh, I have to track down this device driver for Linux so that I can even talk to the network towards the database because it's got some weird security protocol or something like that. And you end up just going down this rabbit hole chasing weird side things that you keep getting blindsided, and you keep getting rolled over by this and that for me is another big time.
\n\nSo when I get blindsided, I often don't know I've been blindsided. I think, oh, I'm just chasing the next prerequisite to finish this ticket. And then yeah, two hours go by, and you're like, wait a minute, I bid zero points on this ticket. I thought it was going to be a five-minute chore with essentially no impact to the schedule. But here it is; I've burned most of my morning. What's going on? And like, oh, hey, everybody, did you know we need this TLS driver on Linux to talk to the database? Uh, no. Now you can raise some visibility and say, "This is what's going on."
\n\nMIKE: There's so much there that's valuable. I saw an article once that I think made a bit of a splash on Hacker News or something, but I'd have to go track down the reference. I don't have it in front of me. The article made this...I think it was just a blog post. But they made an assertion that the way that our work as developers...it probably applies to other cognitive work as well and probably even real physical world work. The way that the size of a project scales is nowhere near linear. And the trick is complexity.
\n\nIf you look at something and there's a lot of complexity in there, there's a huge amount of unknowns. And then you get into all those tangles. You get in with one tangle after another. And a better measure than trying to say, "Oh, this is going to take five days..." we're actually really terrible at that because there's a difference between ways of calculating the midpoint. If you've got a set of numbers, you can say, well, the mathematical average or the arithmetic average, I should say.
\n\nSo you add the arithmetic mean. You add them all up together, then divide by the number of things. You get some number in the middle. Well, that's one way of calculating which number is in the middle. And let's hold that for a second. That's one way of calculating the middle, and we call that the mean.
\n\nAnother way is to line up all the things and pick the one in the middle. That's your median. And usually, if you have kind of a random data set, they're about the same thing. But if you have a highly non-linear scaling, you have one thing that takes 5 minutes, and another one takes 10, and another one takes three weeks; another one takes a year; maybe your median is 2 hours. And your mean is six months. And that wild disparity between your median and mean means that we're really bad at giving estimates because we tend to estimate the median and not the mean. And complexity can throw this huge, enormous wrench in the works that makes things take orders of magnitude longer.
\n\nSo when you're estimating [laughs], you need to remember that you're almost certainly going to get wrong on the mean. You're probably going to be pretty good on the median. And one way to deal with that is to break the work down into smaller pieces so that on each one, you can kind of define the complexity and eliminate the possibility of some of those gotchas. It makes much better predictions.
\n\nDAVID: Wow, there are two big things that I love for that. The first one is that anytime you're trying to do a linear approximation of an exponential curve or a curve that just curves, something that doesn't go in a straight line, you end up with this dip below the center of the line and the ends usually shoot up past the ends of the line, and you end up way off everywhere, except for where the line accidentally crosses your curve.
\n\nThe best illustration I've heard for this is that if you line up all the humans in the world and order them by the number of appendages that they have, the average human has about 1.99 arms, but the median human has exactly 2. In fact, you can go 80%-90% all the way up the curve, and 80-90% of the population have two arms. But there are people at the end of the curve that are throwing off the mean. If you drew it on a chart, you'd have this long flat bit and then a curve right at the end.
\n\nAnd if you try to draw a line from the top of that curve down to the bottom on the other side where everybody has exactly two, that line is never correct, except for the very, very beginning when you take that very first human, and you go, you have two arms, great. And you're the only one here, so the average is now two; great, carry on. And then, the longer you go, the more your estimate drifts.
\n\nMIKE: I found the original reference, by the way. His name is Erik Bernhardsson, and it's definitely worth looking up. If you look up his --
\n\nDAVID: Can you spell Bernhardsson? There's like three ways to spell half of the sub-words in the name.
\n\nMIKE: Yeah. Erik with a K, E-R-I-K, and it's Bernhardsson, B-E-R-N-H-A-R-D-S-S-O-N.
\n\nDAVID: S-S-O-N, okay.
\n\nMIKE: S-S-O-N. And I just googled software estimation median mean, and he comes up at the top because, like I said, it made a bit of a splash. Read that blog post, and I think you'll think about estimation differently forever afterwards in a better way because you'll recognize some of the gotchas.
\n\nDAVID: The other thing that you said that really hooked my brain there is this notion that as we get further and further away, something gets bigger and bigger. The difference between the curve and the line gets worse and worse and worse. I love the Fibonacci or even the exponential curve. I've gotten good mileage out of just doubling the estimates 1,2,4, 8, 16. And both of these, the Fibonacci curve and the exponent, we look at this as like, oh, the job gets bigger, much bigger, much faster the bigger it gets. And no, it doesn't.
\n\nIt's just that our ability to be precise falls off exponentially. So if you've got something that's bigger than eight on a Fibonacci, that's what? Five, then 8, so 13 is the next one. On a Fibonacci sequence, if you've got something that's 8, you can't estimate a 9. You just can't. You try to estimate a ten you can't see your yardstick that you're holding up. It's really hard to tell if there are one or two full yardsticks. You're off by a full meter. So estimated down to the inch is an exercise and a folly.
\n\nMIKE: Absolutely. It's that, you know, the degrees of precision. The digits of precision are important. Maybe you can take the digits of pi out of 20 significant figures. But most of our measurements are nowhere near that precise. And suggesting that they're more significant figures than you are is actually going to give you bad information. It's suggesting a level of confidence that's wrong.
\n\nUsually, we're much closer to those polls that say, "Oh, plus or minus five percentage points." [laughs] It could be, you know, I'm going to give no decimal points at all, and I'm still probably off by 5%, you know, within about a 10% range. I felt like I did pretty good at that. That's far more likely, and honestly, our error bar is usually a lot bigger than that.
\n\nDAVID: Exactly. There's a fun thing that you run into if you're trying to put information out of the United States against scientific data coming from anywhere else in the world. And you will often find...especially if it's meant to be consumed by the average person rather than by scientists because if it's by scientists, it's all going to be a metric. And if it's going to be by the average person, you're going to see something like, oh, we heated this water to exactly 39.214 degrees centigrade. And you're like, wow, that's really precise. No, it's not really precise. That was just 99 degrees Fahrenheit. And don't quote me on that. I didn't actually check those numbers.
\n\nBut you end up with, like, oh yeah, no, we were just rounding to 100 degrees Fahrenheit, plus or minus 10 degrees. But somebody just slavishly copied over 100 degrees Fahrenheit is exactly 38 point dot, dot, dot, and however many decimal places. And they copied up to five decimal places. And you're like, wow, that's super precise. No, no, it isn't. It's terrible.
\n\nMIKE: Which goes to this idea of breaking down work that you got to estimate loosely. I will make an observation here. A lot of times, we look at that and say, well, then estimation is stupid. [laughs] Why should I do any estimation at all? I've probably had times in my life when I thought that, but I've changed my perception on this because I do think that project estimation is useful, but not always for the reasons that you'd expect.
\n\nDAVID: There's an entire school of thought called no estimates, and it's a sub-genre or a sub-flavor of the agile movement. And there are some people that I really, really love and respect that really champion this idea, and I have not extracted that information from their brain. I just want to put a pin in that, Mike, because I think we ought to circle around to this in a future episode, maybe even trick one of those experts to come on and talk to us about no estimates, about why they think it's good and what problems that solves.
\n\nSorry for interrupting you. I want to put that pin in there and then say what you and I have certainly found is that, no, estimates are good. They help us achieve what we...or we think they help us achieve what we want.
\n\nMIKE: Well, let me say that I think that they are terrible in general for telling whoever wants to know when it's going to be done that it's going to be done. But they're pretty good at telling us the scale of complexity of the work. If we look at it, and we can say it was, oh, that's pretty big. I'd say that's five. Well, then, we know that it's beyond what we understand at the moment. It doesn't fit in our head.
\n\nTYSON: And I think the other value of estimates is it helps planning. This is taking it to a more larger sense of a business scale. But if we can give the estimates, it lets us plan for the future of what's most valuable based on the estimate.
\n\nMIKE: Well, and what it does, it might not give you an exact date. But if we went to a project and we say, "That's kind of big," that gives you one thing, but if you go in and you say, "Well, I have these size two pieces, and there's 50 of them," well, that's far more precise. It doesn't give you a number of days, but it gives you a very good sense of the scale of the project. And actually, if you get in the habit of doing this as a team, of making these estimates, then you can actually sometimes map it to days not too badly if you've broken it down to that level.
\n\nIt's a ton of work, and you don't do that until you're ready to work on it. But at that point, you can get actually...I've seen teams come within a couple of days, like two or three months out, when they estimated this way. It took over a week to come up with the estimation. So it's very expensive if you're going to plan out very far. You don't ever want to do this unless you're committed.
\n\nDAVID: I would also wager that the team that did those estimates has been working together for months and months or years.
\n\nMIKE: Years.
\n\nDAVID: And they can reliably...years, exactly. You can reliably say, "This is going to take Mike two days. And this is going to take Dave two weeks." You can literally go through things and say, "Yeah, we know as a team we have a collective sense for how long this is going to take."
\n\nTYSON: I think it's also important to remember these are estimates. And so you have to be pretty flexible to say, you know, if we're going to put a date on it, like, oh, it's going to be two weeks, but then also realize we gave an estimate. And if you go past that, okay, that's fine, and we can re-adjust and plan accordingly. There's so much value on an estimate, and you can use it as kind of a guiding light, but also, you can go off trail, and you're okay with it.
\n\nDAVID: There's a planning tool called Pivotal Tracker that some of our listeners are probably going to be familiar with. My favorite thing about Tracker is that it is continuously giving you an estimate. Basically, it says if you keep moving at the rate you're moving, then you're going to finish exactly on this day because you've put all the tickets into the system, which we can talk about why that's a bad idea. [laughs] But Pivotal always knows; Tracker always knows how long it's going to be until you finish. And it's important to not go...by the way, to the listeners, that's Tyson Novakovich. That's the product manager that I was hoping to get to talk on this call. So I'm very, very happy. Welcome, Tyson.
\n\nTracker will tell you you're going to finish on March 23rd of, 2025. And you do not walk out of there going, oh yeah, we are totally going to finish this. Because every time you complete a job, Tracker goes, oh, you said that was going to take eight hours, and it took you seven. And your estimate moves from March 23rd of 2025 to February 15th of, 2025. And you're like, whoa, I just jumped the schedule by two weeks. And well, yeah, because when you estimate an eight, it takes you seven, and Tracker keeps track of that.
\n\nAnd it's always giving (I learned a term just yesterday.) a good faith estimate. And what this is is you're basically telling management, this is when I think I will be done, but please, please, please remember, every single day, I find out something new. I find out things that I thought were solved that we're going to have to figure out how to do. I found this piece. We've got this entire chunk of time dedicated to figuring out how we're going to talk to the Postgres database, but halfway through the project, somebody came in and said, "Oh no, we're going to throw it straight into the data lake. I want you to talk to Amazon Redshift instead."
\n\nAnd now this entire sub-module of put it into Postgres, which, by the way, everyone on the team is fluent in, now it's put it in this data lake. It's going to be way more powerful. There are all these problems that we were anticipating with Postgres that just go away because we're throwing this entire cluster of cloud databases at it. But also, nobody's familiar with it. And so we've removed this big known problem and, oh, look, our estimate goes way down. Look at that; we're going to finish in 2022. No. No, you're not because we just threw this big thing in there, this gigantic unknown.
\n\nSo every single day, my point is, every single day, we're going to management and saying, "This is the good faith estimate. Don't buy ad space for the shipping date on that day unless you're willing to cut features. Because every time we take a step forward, we find new problems, and you guys add new features." Hey, wouldn't it be great if...Can we add this? Sure, sure, you can. Drop it into the system. And here's your new good-faith estimate.
\n\nAnd it's never a promise of when we're going to finish. It is a calculation of if everything stays the same; this is about when we'll finish. And unless you've been on a team like the one Mike was describing, where you've worked together for years, and you collectively know about how big the work that team can wrestle to the ground in how much time, you're going to be way, way, way, way, way off.
\n\nMIKE: We could easily dive deep into this estimation. I think we should probably save that for a different...We're talking about recognizing how to break down projects.
\n\nDAVID: Yes. But in theory, the topic for today is how to break stuff down, and we haven't gotten to the how. We're just talking about the why. And are you sure you need to? How do you know when you've missed it? [laughs]
\n\nMIKE: It is a huge deal because it is a part. Because if you start by developing this ability to estimate some...how big is this for me? Then you can get a sense of the scale of the problem. And I think that that's actually one of the first steps. Until you get a sense of the scale of the problem, it's really hard to break it down.
\n\nIf you have something that really is going to take you five minutes, if you spend two weeks breaking that down into the sub-components, well, you've wasted some time. But if you have errors and you take five minutes on it, say, oh yeah, we'll get that done, well, then you have not spent nearly enough time. [laughs] So, some assessment of the scale of the problem, I think, is an excellent starting point.
\n\nDAVID: I like that. Very importantly, revisit that scale. So many projects I've worked on, I've said, "Oh, we're going to build this over six months. We've got these really big unknowns. But let's assume that these unknowns are going to shake out this way, this way, and that way." And then you go into Jira or whatever case management system you've got, and you enter in great big epics for all of those big things. And the problem is three of those epics end up never happening. And there are three hidden epics that never got put into the system.
\n\nAnd you will go four, five months in...I've seen teams slavishly build those three epics that we originally predicted on day one because we never circled back. We had this great, big meeting where we tried to break everything down in advance. And the problem is we broke things down. We were breaking things into ones and twos, but they were four months out where we had no business breaking anything smaller than an eight because we don't even know if we're going to do this. This might be a zero because it vanishes from the schedule entirely.
\n\nMy point there, revisit the grand scale of the thing. Don't just have one big meeting. Having a big meeting is fine. That's what I'm saying. But have that meeting again. Don't think that meeting is done and done forever and that you're never going to circle back. You need to circle back and say, okay, our good faith estimate has changed by this much. Why? What's changing, and what do we need to put on here?
\n\nAnd you have another big meeting, and you go through everything that's left to do, and your good faith estimate changes. I'm not a huge proponent of big meetings. But sometimes, they are a bad, bad solution, but they are sometimes the best solution. You might not have a good solution to something, a big meeting for me is that.
\n\nMIKE: Okay. So you get the people together. You get an assessment of the size of it. And then what comes next? I read a book. This was in "Team Topologies." Well, I listened to it somewhat recently. And it talks about how teams ought to be structured, and they give this great idea. If you look at particularly sedimentary rock, it has these natural layers, these strata. And so there are natural fracture lines. This is true of other kinds of rock too. There are seams within the rock. And a skilled stonemason, and times have passed, but probably still today knows how to exploit those seams to split the rock in the way that they want.
\n\nThey're not going to go and just start banging on the rock and hope that it breaks into half. Instead, they're going to study the rock. What are the seams here? Where are the natural lines that it would split? And let's look for one of those just splitting the rock because then it's going to split cleanly. Well, I think that we need to look for those natural fracture lines in the work. So we say, oh, we got this huge project. Well, what are some natural components here that we can start to break it down on? What do you think of that idea?
\n\nRAMSES: I think those are interesting points. I often think about how important it is to understand the requirements before even starting a project. And then, if you're working with a sub-team, we're finding those requirements so each member of the sub-team understands those requirements. And what often happens or has happened is requirements change mid-project. And as long as those new requirements are discussed, just having clear communication and refining those requirements, like, constantly refining those requirements, helps to move a project forward, I think. And it makes it easy to break down a project and think about a specific component of that requirement.
\n\nDAVID: I like that. Try not to lose track of what is it exactly that we're trying to build. Don't get so laser-focused on what you are building and say, oh, I'm building the database adapter. And then you peel off for six months trying to write a general-purpose universal database adapter when it turns out we just needed to be able to do two queries and an insert. We didn't need to do anything else.
\n\nMIKE: It's interesting that you focus so much on understanding and shared understanding as well. Developing that shared understanding you said was critical to breaking it down because if you haven't gotten some understanding first, it's not going to work so well.
\n\nRAMSES: Yeah, it's hard to solve a problem if you don't understand it, like, why it needs to be solved. Because the product or the business can say, "Oh, solve this," and if you don't know the intention or how the end user is going to be impacted...
\n\nMIKE: So every product manager out there listening or in the call, [laughs] if we don't understand the problem, we can't build it. So your work is invaluable, and it's about helping us understand the problem. You can bring the engineers a description of the problem. We don't really need to know how to solve the problem; that's what we do. But if you can bring us a description of what the problem is, a succinct and actionable description of a problem, here's the goal, here's the problem, here's what we want to solve, we'll know it's solved because of this, that is what engineers live on, a problem that's well-described that we can go start working on.
\n\nTYSON: I wanted to...I think one thing you said, Mike, about the stonemasons looking for the key part of the stone to aim for, is when I hear that, I think of, well, that's how we aim for MVPs. If we have a big massive problem or project that we're trying to do, what's the MVP or the minimum amount of work that we can do to get to solving the problem? And then, from there, breaking out smaller parts of the project to improve upon the MVP. But MVPs are super valuable, and it may not be the most polished thing ever, but we're going get something out that solves the problem that we're trying to solve for.
\n\nDAVID: I love that. I've got MVP in my notes here, the minimum viable product. And I was hoping somebody would bring this up because at the very top of the call, when we said how do we break down work, the two things that my brain immediately jumped to are, let's treat this like a rope and slice the rope into pieces just from one end...We'll treat it like a loaf of bread and slice each slice up from one end to the other, working your way from one side to the other.
\n\nWhere MVP, the minimum viable product, you sit down, and you go, what is the first thing the system needs to do to be considered not complete and feature complete but like, what's the very first thing the system needs to do to tell us our idea could ever possibly work? So it's like, I don't need to insert and delete from a database. I just need to connect to the database. That's arguably not a viable product. It's certainly not for the 1.0 of the thing we're trying to build.
\n\nBut the first time I do this, I need to connect, and the second time, I need to hand a query to the database where I can just gin up this entire long string and just shove it at the database. Eventually, I'm going to have to build this whole adapter layer that can take these objects and spread them out and turn them into that query.
\n\nBut I like the MVP because you kind of like take one corner of the...like, if the project is this great, big rectangle, you take one corner of it, and you just slice a little circle, you know, slice one corner of it out and you say, "This is my product." And then you slice another piece and another piece, and you just keep sticking them onto the thing that you've built.
\n\nAnd from the get-go, you have something that doesn't do everything you need, but it does something. And you can test it, and you can verify to yourself from now until the project is finished; everything we've done up till now still works. I can still connect to the database when I put this piece. I really, really like that. It gives me a lot of safety and security to know that something I just built didn't ruin everything we've built up.
\n\nMIKE: Do you remember when the iPod came out?
\n\nDAVID: Mm-hmm.
\n\nMIKE: How well was it critically received?
\n\nDAVID: Oh, that part, I don't remember.
\n\nMIKE: It was widely --
\n\nDAVID: Actually, I do. Penny Arcade is a webcomic that I used to read. And the way that I loved it was you could buy...at that time; you could buy a Discman, which is a CD, portable CD player. You could buy one of these for $29. And the iPod was $300, if I recall correctly. And people were like, "Oh, but when you listen to music in digital format, it never skips." And the Penny Arcade strip that I remember, he says, "My Discman doesn't skip either because I padded it with $270 of cash to keep it from bouncing around. [laughter] I'm using dollar bills as packing material." Yeah, it was a terrible idea.
\n\nMIKE: Everybody thought, like, critics said, "It doesn't have nearly the features of its competitors. All it really has going for it is it looks nice, and it's got an easy-to-use interface. But who actually goes out and buys and listens to music?" Well, it's like teenage kids who don't want to go and figure out a complicated nerdy interface to listen to their music. If they can press some buttons and easily get to where they are and play it, that's all they care about.
\n\nAnd that product was probably embarrassing to a lot of engineers who built it because it did almost nothing. You'd put a few songs on it, and you'd press play. Well, they iterated on that. They came out with a consumer product. Apple was not when that thing came out, the behemoth they are today. They were trying to recover. And they came out with this consumer product that was kind of outside of the normal things they'd been doing. And they just sold these kinds of weird computers. And they came up with a smaller consumer product to test out the market. Well, it worked.
\n\nThey put out this minimal product that was good enough for some people to buy it. They didn't put out a massive smartphone that had three cameras on the back. They put out a thing that would play some songs. And you could press kind of like play and pause, and that's about it. And then they made it a little bit better, and then made it a little bit better.
\n\nAnd a few years later, they said, you know what? What if we take the same idea and we apply it to phones? And they birthed a whole industry and have come to dominate it and become what? At least at this time, the most valuable company on earth. Because they started with that incredibly simple minimum viable product, I think that should be a strong lesson to all of us.
\n\nDAVID: There was a lovely sea change that happened in the world, not just in the industry but in the world where prior to the iPod coming out, we generally consumed our music in albums. You would go buy a cassette or a CD, and you would throw that chunk of physical media into your player. And those were the tracks that you had available. So you listened to the album in the way that the producer layered the tracks. Like, bands used to stack their songs in an order that we're going to come out of this song and into the next one. What DJs do now bands had to do with their own music and present it to you in that format.
\n\nBut all of a sudden, people are now doing...they're arranging their music into a thing called a playlist. And I had never done that prior to this. I was a stick in the CD; oh, I'm going to do this work today. ELO "Time" is going to be a good album to listen to today. And all of a sudden, I'm sitting at my computer, and I'm dragging all the tracks out in order that are all 170 beats per minute because I've got to really knuckle down and work really hard, really fast, really intense, and I need some really fast music.
\n\nAnd all of a sudden, I'm throwing in classical music, and I'm throwing in heavy...it's like when you come out of Vivaldi's "Four Seasons" and run straight into Rob Zombie. It's a little bit of a whiplash. But it worked because they were the same BPM which no producer has ever put together. Well, I'm certain that's wrong because now people can go buy an album that's just running music, and you literally buy the album at the BPM that you want.
\n\nBut the playlist, the idea of you're going to sit down and figure out what you want to listen to in advance. And now you strap the iPod on, and you just push the big red play button, and that's the only button you need. And that was a sea change. Prior to that, we needed the seven different controls because I love this album, but I can't stand this track. I've got to be able to skip over it whenever I want.
\n\nMIKE: A fundamental change in the industry was sparked by people just simplifying, by the engineers saying, "What's the bare minimum we can do?" And it forced a rethink of the interfaces and the way we even think about the problem. Well, we're talking about how to break down a problem, and if we don't start there, we're probably doing it wrong. We have to start, like, what is the bare minimum we can actually do? And it may force us to challenge our assumptions to say, "Well, what can we really get away with here? What can we really cut?" And maybe there's a lot more than we thought that we could.
\n\nAnd if you're not being uncomfortable with the cutting, then you're probably leaving the project too big. You need to truly make it minimal, or else there's some of that complexity that's going to kill you. That non-linear complexity is going to make it take way longer than you expected. You need to shave as much of that as you possibly can to get something really tiny because if you get that really tiny goal, it's achievable.
\n\nAnd once you have something that works, well, now you've got something where before you had nothing. So that jump from nothing to something is the hardest part. And then you repeat and say, "What's the next minimum thing I can add to this that actually provides value?" And you aim for that. And you just put it on repeat. [laughs] You put that, and you do that in a cycle.
\n\nDAVID: I worked with project managers 15-20 years ago who told me to my face, "There is no minimum viable product." I must have every single feature down to 100% completion, or the entire project is worthless. And I opened up the project, and there were like two weeks spent polishing the user interface. And I'm like, this is...no, we need to teach you what an MVP is at this point.
\n\nI love that you said if you're not feeling uncomfortable while cutting features, you're not cutting enough. You have to remember; you're not saying we're never going to build this; you're just saying I'm not going to build this now. We're not going to sell this to a customer without this piece. But can we stand it up and prove to ourselves that it works right now, is useful?
\n\nThe phrase that I like that's related to the uncomfortable one. I think it actually used the word ruthless, which is kind of like the mental image of a programmer just head down, looking up at you through the eyebrows with an evil smile and basically saying...the phrase that I loved was every feature must fight for its life, or it does not get to live on the project schedule. That's what you should be asking when you're trying to figure out an MVP. Look at any feature and then say, "Can we just not? How much of this can we not do and still move forward?" I love that idea.
\n\nIf you're taking the slice of bread analogy and you've got to move data from...okay, this is a terrible mixed metaphor. You got to move data from one end of the loaf to the other, [laughs], but you've got these layers. You've got to move...you got the user interface layer. You got the client layer. Then you got like the middleware, and then you got the back end, and the backplane, and the messaging system, and the data system. You got all these layers.
\n\nIf you have somebody sit down and say, "We have to build this slice of the project. It has to be 100% complete before we can move on to the next slice," I promise you that person is wrong, and you are looking at the project the wrong way. That's the maximum viable product is to finish that layer 100%. What's so much better is to take one tiny little core sample of that slice of bread, and then build the core underneath in the slice below it, and then build the core of that under the next slice below that.
\n\nAnd eventually, you end up...it doesn't look like a loaf of bread. It looks like a string of beads from one end to the other. And you can't run any useful data through it, but you can run a ping and get a pong back. And that pong came from the database server, which was on the other side of the network, which was through the enterprise backplane, which was through the messaging system, which was through the back-end front-end middleware all the way up to the client. And that first time you get that pong actually coming out of the database server, it's very exciting as a programmer. I love that.
\n\nMIKE: It gives you the skeleton that you can start building on.
\n\nDAVID: Yes.
\n\nMIKE: When they build a house, they don't start with the siding. They build the frame. And that's not how houses have to be built. They can build the kitchen, and they could finish it and put all the flooring, you know, paint the walls, put in the cabinets. You get that done and then move on to the next room. But nobody does do that because it doesn't work out very well for a project.
\n\nIf you can build out that skeleton, then there's stuff to hang everything, stuff to hang your sheetrock, stuff to hang everything else. You can start to work in parallel once you've got that frame. And you can see it and have an organizing idea. And getting up that skeleton is a huge turning point for the success of the project.
\n\nDAVID: Absolutely. You absolutely can paint the wall before you build the wall. I realized that sounds bizarre and weird. But you don't want to just sit down and stretch a tarp over the wall and then paint the tarp. That's not how you want to do that, but you can. There are people who do critical path analysis, and they figured out that you can build a complete house with foundation, and cement, and electrical, and finishing work in like 18 hours of continuous time. We started at this time, and 18 hours later, we were done.
\n\nBut yeah, the walls were assembled on the ground, and the primer coat was put on the walls while they were still on the ground, and absolutely, you can do that. But it's a really weird way to work. And you have to know exactly every messy, little side tangent, and in software, we often don't have the luxury of that. So it's much, much better if we can just go; let's dig the foundation and find out are there any pipes that we have to work around? And, okay, let's pour the foundation and find out any problems we've got there. And it's much easier to paint the walls once they've been built.
\n\nI feel like we now need to do another episode on actually how to break stuff down, [laughs] like how to break something into an MVP and what constitutes an MVP. There are still some open questions here. But Ramses, or Eddy, or Tyson, is there any kind of a coda that you think that we either need to touch on or that you touched on really well?
\n\nTYSON: I think it's much of the how, but I think even with the project itself is the why of it. And so really covering all our bases on the why we want to break things down is equally as important as the how. It's a good overarching summary of what we talked about today.
\n\nDAVID: Awesome. Gentlemen, thank you. This has been the Acima Development podcast. And, Mike, we'll have to talk about maybe splitting this...maybe changing the title into why break things down and then maybe circle back. I think that would be a fun segue. Or maybe we'll just call this the how and let people extrapolate from what we've said. Thanks, everyone, for joining, and we'll see you next week or in a couple of weeks.
","summary":"","date_published":"2023-04-26T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/8688641c-bfec-4717-918a-1f79f46cd894.mp3","mime_type":"audio/mpeg","size_in_bytes":50148975,"duration_in_seconds":2657}]},{"id":"cae052a7-9bfb-4fa4-8b53-952aa659928a","title":"Episode 15: What Do You Study to Continue Learning?","url":"https://acima-development.fireside.fm/15","content_text":"Today we dive in and talk about what we study to continue learning.\n\nTranscript:\n\nDAVID: Hello and welcome to the Acima Development Podcast. I'm your host today, David Brady. And today on the panel, we have Mike Challis, Eddy Lopez, Ramses Bateman, Kyle Archer, and Afton Call. Welcome, welcome, everybody. How's everybody doing? It's been a while since I've been on.\n\nMIKE: It's good having you.\n\nRAMSES: Yeah, it's been a while. \n\nDAVID: It has. It's been. It's good to be back. All right, today we're going to dive in and talk about what do you study to continue learning? And I'm kind of excited to talk about this because this has been actually coming around on my feed and the things that I listen to. I've actually got some unusual answers to this, and I'm kind of curious. But I'm going to throw it out to the room because you guys know that when I show up, I talk too much, so somebody else talk. What do you guys study to continue learning?\n\nMIKE: It's an interesting question because when I graduated from high school, my career didn't exist; that is, you couldn't be a web developer. That role didn't exist in the early '90s. There was no such thing, right?\n\nDAVID: Yap.\n\nMIKE: It didn't really exist in a meaningful way for some time after that. We've touched on this idea before on the podcast that there are some accidents of birth and your background that sometimes affect your career trajectory. This is kind of a big deal. The industry is changing, and it's a new industry for web development in particular but kind of anything that touches the internet that didn't exist in any meaningful form. So if you're not learning, [laughs] you might not even have the chance to have a career because, like I said, the career didn't exist. Mobile development didn't exist...what? Ten years ago, 15 years ago. That didn't exist as a profession because there was no such thing as a smartphone.\n\nDAVID: I saw an actual study on that. I cannot remember the number now, but it was an alarmingly large number of people in the technical sector who had jobs that did not exist when they started college. They graduated and went straight into a job. And their job is ecclesiastical brand manager, or technology evangelist, or data personality manager. What is any of this stuff? And yeah, if you're not studying now to grow yourself, there are entire jobs coming that you're not prepared for because it's not coming down the mainstream curriculum.\n\nMIKE: And that you couldn't be prepared for. Yeah, there's not going to be a university degree for it because they'd have to invent the field, right? [laughs]\n\nDAVID: Mm-hmm. Yeah. \n\nMIKE: And you're not going to learn mobile development in college if the iPhone hasn't come out yet. There's a chicken and egg sort of problem; one of them has to come first.\n\nDAVID: And academia is 20 years behind, right? \n\nMIKE: Yes.\n\nDAVID: I remember in 2005 or 2006, the people that I was working with that were coming out of BYU were all Java programmers, and I was really surprised by that. I'm like, when I went there; it was C++ and assembly language. And, oh, you guys are now doing Java. Java had been out for ten years, '96, I think, '94 when it came out, and now it's in academia. But everybody that was good at Java had been programming in Java for 5,6,7,8 years. And it was just now showing up in the colleges.\n\nMIKE: And I think there's always going to be that lag. I mean, just in the best of all possible worlds, you had some really forward-thinking professor who notices a new thing, takes the time to gather the information, stays up to date on the latest state in the field, and writes a textbook. That doesn't happen overnight. In the best of cases, you're probably going to be at least a couple of years behind the industry. \n\nDAVID: Oh yeah. There's a weird sentiment that I've actually heard a professor express, which is that universities have an obligation to present grounded, well-spread fundamentals, which means they actually have a duty to avoid fads. So the only way to avoid a fad is to wait for something to stand the test of time, and unfortunately, that takes time.\n\nMIKE: So back to your question, [laughs] you got to stay relevant. And I enjoy learning. I enjoyed school. Let me clarify that because there are a lot of people who are like, \"Oh man, school was awful.\" There are some aspects of school that can be wonderful and others maybe not so much. You look at little children, and they love to play. They love to explore. I look at my young kids, and they like to try out new things all the time. It's innate. They find great joy in creativity and exploration. \n\nAnd if that's how you define school, hey, school is great. I get to go learn new things and try new stuff. That's play. But if school is learning things by rote and getting in big trouble if you made a mistake somewhere, well, that's not fun at all. So I clarify a little bit [chuckles] that when done right, I think for people in general, we have that innate curiosity and deep longing to try new things and to explore ideas. So yeah, that part of education I really enjoy.\n\nMyself, I love to read. One thing I do is I subscribe to newsletters; some people do it in a different way. But that way, I can look through generally aggregator newsletters in academic fields which I'm interested in so that I can look through; so; here are some articles that may interest you. And I go look through, and I'm like, yeah, that one does interest me so that I can keep up to date on the state of the industry or on nascent industries, you know, things that are starting to form. I'm personally interested in machine learning, so I follow that pretty closely. I follow that. \n\nI've also taken courses online in topics that interest me, both alone and with others. And I will say that taking a class with somebody else, you are far more likely to finish it because there's the social aspect to it, so I love that.\n\nDAVID: Absolutely.\n\nMIKE: And it is true also that just in the course of your job, you will encounter things, and you shouldn't be ashamed to go out and learn that as you're going. So that's a quick sampling of some things that I do.\n\nDAVID: I love...there's a thing that happens to me occasionally in this field. When I'm talking to people, I talk about being an autodidact and learning and growing on your own, like, motivating yourself. And I actually hear people come back and tell me, \"My boss tells me I don't pay you to learn.\" And I just laugh and laugh and laugh and laugh and laugh because I ask them, \"What are you working on?\" Because in software, what your boss hands you pretty much every single morning is, here's the thing that's never been done before, go do it. Uh, you sure your boss doesn't pay you to learn? Your job is literally to learn. \n\nMIKE: Absolutely. \n\nDAVID: I said at the top of the call that I had kind of a weird insight into this because of something that I had been looking into. And I was going to try and hold it in my back pocket, but you stepped right onto it, Mike, with talking about children. There was a fantastic video...I'll have to dig it up. If we've got show notes for the show, I'll put these out, but if not, you can search for it on YouTube. \n\nIt's a discussion that Neil deGrasse Tyson had in an interview. And he got asked, \"What do you study? What are you learning right now?\" And he kind of goes off on this tangent about the things that he's studying, about how he's interested in studying how people learn and how people change the way they think. But he veers into this beautiful, beautiful anecdote about how as an educator, he feels that it's his job to spend energy teaching people to love experimentation. And he needed to illustrate what does that mean. \n\nHe's like when you have a six-year-old pushing a tray table with a glass of water on it, and that glass is shaking, that's an experiment. This child is doing an experiment. If I shake this, it tips, it falls, the glass breaks. That's an experiment. I have a situation. I have a stimulus. I have a response. And so many of us, the natural instinct is don't do that, don't do that to the degree that it's just simply a day-to-day occurrence. Yeah, sure, I mean, you got to live with your kids. [chuckles]\n\nBut if you can view it from the point of view of this is an exploring creature conducting an experiment on the universe outside of them, and I want to encourage them to gather prima facie evidence, first-hand evidence on the universe around them, you let them break the glass. And you say, \"Okay, what did we learn?\" without shaming them, not the \"What did we leaaarn?\" No. But literally, \"No, seriously, what did you learn? Tell me what you learned from this.\" \n\nOr if you must be preventative in this, step in and say, \"What do you think you're going to learn? What do you think is going to happen here?\" And again, not to do it in a shaming way but to do it in an encouraging way, and that takes energy. I mean, you got to go buy a new glass [laughs] and then replace it. You got to clean up a mess if the child's too small to clean up broken glass.\n\nBut that child goes on to become a scientist or an explorer because they end up with a first-hand thirst for exploration and knowledge. And they also gain this core belief that exploration is safe and wonderful rather than damaging and hurtful because I got yelled at when I broke a glass. I was blown away that that's what Neil deGrasse Tyson is studying right now is that level of learning. And I thought, wow, he's literally learning how to learn and how to teach people how to learn. That's cool.\n\nMIKE: We could probably spend a lot of time talking about the joy of exploration that children have. And maybe that could be a guiding principle as we're talking about this topic. What do you do to stay up to date? Well, be curious. [laughs] If you've got curiosity, feed it because if you don't feed it, it will kind of atrophy, and you'll find yourself burned out and bored. But if you feed it, then you're going to find your career pivoting, and you're going to be in that job that didn't exist ten years ago because you'll have gradually migrated and followed your curiosity into something new.\n\nDAVID: Absolutely. What are things that we can do if not to, I mean, I think it's like a foregone conclusion for us to say we got to keep learning; we got to keep growing. Are there conscious, explicit things that you can do? I know that the Atlas team at Acima there's dedicated time on the schedule. This is learning class. This is time for us to sharpen our skills. Skills Clinic is literally what it's called. And it's an invested amount of time. I've not worked at a place that had that dedicated, so most shops, in my experience, don't do that. \n\nWhat can you do to encourage those around you to learn or to create? I just realized I'm trying to trick you into giving me the answer that I want. And the answer that I want you to give me is that if I go create the environment where everybody's learning, then I get to learn too. So I'll throw that out. But what can we do to create an environment of learning where other people can learn, grow, and continue, and we can learn, grow, and continue? And who cares? Not just for you getting your next job but how is that going to benefit your employer here today?\n\nMIKE: You dropped a couple of hints there. [chuckles] The first is you said, well, you do the skills clinic where you dedicate your time every day. Well, not everybody out there is going to be able to walk up to your boss and say, \"We're going to start taking an hour every day learning stuff.\" Now, a lot of you probably could because your boss might be like, \"Okay, that sounds great. I want better-educated employees.\" \n\nSometimes that might be a little overwhelming, like, wait, what? What about productivity? But you don't have to start that big. Start a book club. Start a book club. Now you are working with other people, which will help keep you motivated, and you can do that together. Or go find some people who are interested in a class. Go take it at the community college, or a local university, or online. Most of those are get together here. There's a recurring theme. [laughs] It helps keep you motivated if you wanted to make space for other people. \n\nThere are things that you can do, I think, wherever you are to make that kind of space. You can say, \"Let's read a book together. Let's do a book club, and then every week, we'll talk about it.\" You're not taking very much time. You can even do it on your lunch break. You can make that space. \"Let's go take a class,\" and then you swap ideas. [laughs] You give each other support like, \"Hey, have you done homework yet?\" [laughs] \n\nYou can find somebody who is starting their career or who wants to start their career and say, \"Hey, want to get together at lunch, and I'll help you out to learn some of this coding thing?\" or this data thing, whatever it is that they're wanting to pursue. Well, now you have a recurring opportunity to get together and mentor somebody. And as you mentor, you learn a lot. \n\nI threw a few ideas out there. I'm curious, other people I think have been involved in these ideas and more. I'm throwing these out because I've been involved in all of these things before. I mean, I've done these things. Other people, have you done other things, or if you participated in the kinds of things I mentioned, how did it work out? \n\nRAMSES: One idea that we incorporate quite a bit, probably in our organization but specifically on our team, is encouraging the idea of pair programming and pair reviewing, which I think helps to promote a healthier understanding of how things work or should work, or can work and just alternative solutions. And overall, just better discussions and better collaboration, which I think is important. Each of us is limited by our experiences. And we're limited to our current understanding of things. So gaining someone else's perspective or insight and experience is tremendous. \n\nAFTON: I agree. I think our pairing, which has been highly encouraged on the Atlas team for quite some time, is a great way to have this ongoing mentoring environment, which then helps everyone to continue learning because everyone is teaching. Those who know more are teaching those who know less, and those who know less get to have a chance to try and explain things to someone else, and that develops their skill. I think that's a wonderful thing that we have on our team. \n\nI want to go back just a little bit to what Dave mentioned earlier, which was our skills clinic, and how that's been in place for a while as an opportunity for us to spend time sharpening our skills. And the funny thing is, and Mike can attest to this, is we started that skills clinic kind of as part of an internship. But after the internship ended, it was really hard to get the skills clinic to keep going. It was hard to get developers on the team to attend and take advantage of it. \n\nAnd even before the skills clinic, the take an hour a day to sharpen your skills was talked about, encouraged. But I found for me; it was really hard to take that time. Even though it was being handed to me on a platter and said, \"Do it,\" it was really hard to take the time. And it has been always really hard because when you're in the middle of a problem, it's hard to set it aside and go do something else. Context shifting is hard. You always just feel like I need to get this done. I need to get this solved. I need to get this out. Sometimes there's pressure to get something out quick. Sometimes it's other people are relying on me. \n\nThere's just always a lot of weight going and pressure to get work done. There's always so much work to do that we can never catch up, which I think contributes to that. So recently, I realized something that has made a world of difference in me, taking that time to sharpen my skills as often as I can. I don't know that I'm getting an hour a day, but certainly, more than I was in the past. And what that was was thinking about my career and what I'm working toward personally. \n\nSo I actually took this little online course on LinkedIn learning about...I think it was how to choose or organize your priorities when everything on your plate is a priority. [laughs] And so it was breaking things down into, well, you have to think about what's urgent, and what's important, and do the things that are urgent and important first, and then the urgent but not important or important but not urgent. They had this stack of how to decide what to do first. \n\nAnd then it also talked about another way to decide and get things done that you keep wanting to do but haven't figured out how to make happen is to think, okay, where do I want to be a year from now? Where do I want to be in my career? What do I want to have accomplished? Where do I want to be five years from now? And I was thinking a year from now; I want to have better technical skills than I have today. And I want to have written a lot more code and have a lot more experience in our codebase. \n\nAnd in my newish position as a team lead, it's been a lot harder to find time to be writing code and to be learning. But when I said okay, a year from now, if I haven't progressed in those two areas that are super important to me, I'm going to be really frustrated with myself. So the only way to make that happen is for me to make sure that every day starting yesterday [laughs], I prioritize that. \n\nAnd sometimes, I have to take something that is a priority and say I'm not going to do that for one hour. And instead, I'm going to spend some time sharpening my skills or working on a ticket because that is also a really high priority. And that's made the difference for me is knowing what my goal is for myself a year from now, five years from now. \n\nDAVID: That's amazing. That's awesome. Thank you. There are so many things you just dropped on there. I'm writing frantically. I love that idea that there's always so much to do. I would amend that and say there's always too much to do. And just like you said, when everything is priority one, nothing is priority one. Well, guess what? You can weaponize that to your advantage. \n\nIf you can't stop to improve your skills and invest in yourself because you always have too much to do, then stop and invest in yourself because you're still going to have too much to do, whether you stop and invest in yourself or not. And a month from now or a year from now, if you have increased your capacity a month ago or a year ago, you're reaping the benefits of that. \n\nAFTON: Yeah, absolutely. \n\nDAVID: You said having a goal, and it reminds me of a thing I did in...oh God, [laughs] somebody told me once that \"I hate when programmers stand around telling war stories.\" This is totally a war story. I'll make it quick. Back in like 2006 or 2007, I had gotten into Ruby on Rails, and I was really excited about it. But all the work in my hometown was PHP. And I had a customer approach me. I was freelancing back then. I had a customer come to me and said, \"I want you to build me a website from the ground up.\" \n\nAnd this was an old customer. We had a really good trust relationship. And he also paid me miserably. [laughs] He wanted old rates from 10 years ago when you didn't know how to program. And I negotiated with him that I will do this for you, and I will do it at the old rates, but I'm doing it in Ruby on Rails. And he didn't program, you know, I basically told him, I'm going to do this with a left-handed metric spanner, and he was like, yeah, okay, knock yourself out. \n\nAnd because I had that as an explicit objective that I want to get professional experience working in this, I was able to just gin it up out of whole cloth and basically say, I'm starting this project professionally because I'm a consultant and I can do that. And then, a year later, when I got the opportunity to work in Ruby on Rails at a company, and they were like, \"Well, what experience do you have?\" I'm like, \"I've been doing it for the past year.\" And that was super, super useful.\n\nMIKE: Interesting. My intro to Ruby on Rails was somewhat similar. I was at a company doing Java. They said, \"You know what? We need to use an interpreted language. We want the flexibility and speed that we've seen other people have in interpreted languages. So you're going to do PHP.\" And I'd done quite a bit of PHP kind of on the side. And I thought, given the state of that language community at the time, I thought, if we do this, we're going to have a horrible ball of mud in no time flat. I need to use something that has a framework and organization that we can work with. \n\nAnd I heard a presentation about Ruby on Rails at a Java Users Group. It was like, \"Yeah, there's this new framework in beta called Ruby on Rails.\" So I went and wrote the seed of our rewrite in Ruby on Rails over the weekend, kind of learned the language and the framework. I spent a long weekend. I came back, and I said, \"Okay, well, I've got this prototype. What if we try this?\" Like, okay, I mean, you've already got it; we might as well. [laughs] And we ran with it. And I've been doing it ever since.\n\nDAVID: That's awesome. Rails had that sneaky underdog thing. There was that seminal post by DHH, \"Build a Blog In 15 Minutes.\" I've seen that happen as well where somebody says, \"Oh, let's switch to Rails.\" And they're like, \"Well, what's the start-up cost?\" It's so great to be able to say, \"I wrote it on the car over here today,\" or, \"I wrote it last night.\" The start-up is done. Now all that's left is all the really hard work. But you don't tell them that. You just tell them, \"Oh, look, the start-up piece is done. That's half the work,\" right?\n\nMIKE: [laughs] It's true. I can say that that application we rewrote ended up having one-tenth the number of lines of code, and it did more. But that doesn't necessarily mean better. So, I mean, I'm not trying to be a framework snob or anything here, [laughs] but there were some definite pluses that came from it. But yeah, exactly; if you come with the prototype, it's a lot easier to sell your cons.\n\nDAVID: There's a line count that, in my experience, Ruby has about somewhere between a 3:1 and a 10:1 ratio of line count. Prior to Rails, I was used to working on C++ projects with half a million lines of code and then PHP projects that had 100,000, 150,000 lines of code. And now, if I see a Rails project with more than 30,000 lines of code, I get scared because that's a big project because you can do so much. \n\nAnd there are trade-offs to that. It's a lot harder to tell your manager, \"Oh, yeah, I wrote 1,000 lines of code today.\" It's a lot harder to do that in Ruby than it is to do it in C++ because there's just so much boilerplate. You get 900 lines for free.\n\nMIKE: And you need to recognize there's trade-offs as well. We are talking about interpreted languages. In Ruby specifically, you don't get some of the type checks that you get from other languages, and there are some real trade-offs there. I'm thinking TypeScript is overtaking JavaScript. It compiles to JavaScript; I mean, it's the same language, basically. But people want to have that type safety because it avoids certain kinds of problems. So, I mean, absolutely, there are trade-offs but interesting ones. We can really get into this. [laughs]\n\nDAVID: Oh yeah, I can drill into this really easily. There's a concept that I've seen, well, actually, this is a good example of learning, and then all of a sudden...what I will say about studying to learn something is don't be afraid to chase a tangent because that's where all the marrow is. That's where the juiciest tidbits are is when you're in the middle of something, and then, whoo, we go off down this sidebar. But when my ADHD fires way too hard, I look around, and I realize everyone's eyes are glazed over because we're seven tangents deep. \n\nAnd there's an idea where those of us coming from old statically-typed languages we had all this upfront checking that the language had to do. And that cost ceremony, and that caused us to slow down. And it was very frustrating, and we wanted to go fast. And these interpreted languages came along, and these dynamic languages, and it's like, oh hey, look, we don't have to do our upfront checking. Well, then our programs blew, so it's like, okay, we need to do unit testing. We need to test at the other end. \n\nIf you're not going to test that all the types are correct, then you have to test that the program behaves correctly at the end of it. And there's a really phenomenal thing in the industry where you can see some people going; I don't have to check upfront, but I'm too lazy to actually come back around and test at the end. And those people, bless their hearts, their co-workers are the ones who are saying, \"Let's maybe go back to statically typed. I think it would be okay if Jim could not write software without enforcing something on either end of this. Let's hook into somewhere.\n\nMIKE: We should do an episode on typing.\n\nDAVID: Oh yeah. I can do about 110 words per minute.\n\nMIKE: [laughs]\n\nDAVID: Oh, wait, wait. \n\nMIKE: Ramses mentioned pairing. That's really interesting. You didn't say formal study but getting involved with another developer so that you're sharing ideas with each other. Kind of continuing on this idea of tangents, those of you who have learned something pairing, do you usually learn something that you were expecting to learn when you're pairing with somebody?\n\nDAVID: Never. I'll let somebody else take the question, too, though. [laughs]\n\nRAMSES: Yeah, not always. You never really know what you're about to learn. Like, it's not really super formal. So you just get together, do some discussions, and throw out different ideas, different solutions and see what you come up with. It's always an interesting and unexpected experience.\n\nMIKE: Yes. So you set up to solve a problem. You're pairing to solve a problem, and you end up learning something. I was talking with some people about recursion earlier this week about a function calling itself. And we ended up talking a good deal about memory management, about how your computer manages memory, and the operating system, and addressing, and pages in memory, virtual memory, kind of far afield from recursion. \n\nBut we talked about that so that we'd understand how that stack of function calls eventually is going to run out of space. So we went in with one goal in mind and ended up somewhere very different. But they're both useful. It always happens that way if you let it happen. You leave room for that spark.\n\nDAVID: Yes, it's very important to not fall into the trap of trying to predict the spark. Or rather, you can absolutely predict that the spark will happen. I've done podcast episodes where everyone is sitting around going, \"What are we going to talk about? I have no idea what we're going to get out of this.\" And I just told everyone on the call, \"It's fine. Just sit down, relax. It will happen. Trust me; it will happen.\" Banking on the spark happening is absolutely doable. \n\nBut if somebody sits down and says, \"What are you going to learn today?\" It's really hard. Mike, you might have sat down and said, \"Well, we're going to learn about recursion. We're going to learn about creating base cases. We're going to get into mutual recursion where this function calls that, and that function calls back into this other one,\" and blah, blah, blah, and down the road, you go. \n\nNowhere on your prospectus would you put we're going to learn about how memory management, dah, dah, dah, that the heap is well managed and the stack is not, and dah, dah, dah, and down you go. If you lock yourself into that predictive deductive thinking rather than walking in open-armed and ready for inductive learning, you'll cut yourself off from your own creativity. What's the rule from writing? You can't create and edit at the same time. You can't be an editor for your writing while you're writing everything you're writing. I've missed the conversations where I throw three metaphors at a problem at the same time; there you go. \n\nMIKE: But we went there, this idea that pairing is a really great way to enhance learning. You don't go in there necessarily with a goal in mind. Instead, you create an environment where that curiosity and exchange of ideas can happen.\n\nAFTON: I want to say that this learning from pairing is not limited to learning additional technical skills like some new coding trick or even a new design pattern or something, which are definitely valuable. But one thing I also get from pairing is getting to see how someone else's process works. What kinds of questions do they ask to navigate the problem we're trying to solve? Where do they go in the code? How do they figure out what questions to ask and where to look? And what are the steps that they take from start to finish to solve a problem? I think processes are super interesting, and having a good process can make you more effective. \n\nThis kind of goes into what I was thinking about what I do to continue learning. I realized also recently that I have two different areas of learning that I focus on; one is on super technical skills, learning a new language, or refreshing my Ruby on Rails knowledge, or even studying algorithms, which we've been doing in our book club. But on the other hand, I'm also studying how to manage projects, how to communicate well with people I work with, like on my team. Right now, as a leadership, we're starting crucial conversations and learning about how important it is to be able to talk to people and communicate well your intentions and your ideas, and organize your thoughts and respectfully, and all those things. \n\nAnd we mentioned in an earlier podcast episode; development is so much more than just writing code; we do so much more. We are teammates. We're working with other people. We're organizing projects. We need to know how to manage our time to be efficient and effective. And so I also study time management and figuring out your priorities, how to figure out your priorities, leadership skills, communication because I believe that all those things are also going to make me a better developer, a better teammate, more effective in my career.\n\nDAVID: There's a thing...I believe it's called the synthesization step or integration. I can't remember. There are steps to learning ideas. And for me, the exciting thing is near the end when all of a sudden, you find out that these wildly disparate fields of study are 100% overlapping where you're getting into time management, and you're like, okay, this is important, and it's essential. And I have no control over where it's going, so I have to focus on the process and just let it go where it needs to go. Or this other thing is not important, but it needs to be done. So I need to focus on what is the fastest way to get to this outcome? \n\nAnd then weeks later, you're having a conversation with a co-worker, and you realize I need you to write this to this API. I don't want to talk to you about your feelings about it. We'll do that at lunch. I just need you to do this, and I need it done quick. We've got this other deadline. It's like, I need to be efficient with you. I need to focus on the outcome, boom, boom, boom. \n\nAnd then an hour later, you're talking to somebody else, and you realize they are wide open vulnerable. And you suddenly realize I can't be efficient right now. Efficient is the most deadly thing I can do to this conversation. I have to be effective in how I communicate with this person. And so you're like, you know what? I'm clearing my schedule because this is important, and I don't know how long it's going to take. \n\nWhen you see those parallels, you study how to communicate with people. And then a week later, you're writing some code, and you're like, oh, how do I document this function? And all of a sudden, you realize, oh yeah, I know exactly how the person reading this...I know what they're going to be hungry for, what they're going to be looking for. I'm going to document that, or I'm going to write a unit test that expresses this. \n\nAnd it's kind of nice to have somebody come back and find you and say, \"I love that test that you wrote because I could not figure out what your system was doing until I saw that test. And all of a sudden, I could see the through line in all of your software.\" That's amazing. I've had that happen once in my career, and I'm still bragging about it on podcasts today. \n\nI have a weird question for the group. You know me, I love weird questions. What is the weirdest, most out-there thing that you have learned that you've been able to bring into a professional situation with benefit? I mean, obviously, some of us bring weird stuff into the office just for the sake of bringing weird stuff into the office, and it doesn't always go well. But is there something that you guys can think of that you're like, I did not expect to use that at work today? \n\nRAMSES: Yeah, that is a weird question, and I don't know if I have a good response for it. I spend a lot of my time trying to learn new things to improve my workflow and to improve my knowledge. I don't know if I have a better response for any weird things.\n\nMIKE: I'm trying to think of a specific example. It feels like everything that I end up studying ends up crossing over. So here's a recent example. I'm going to take my kids out trick or treating. We'll probably release this next year in March or something. You're like, wait, what? [laughter] But we're recording this in October, and here in the U.S., we're doing Halloween in about a week. And we were talking about how to do a quicksort earlier this week, or I think it was last week. Recently, we were talking about how to do quicksort. \n\nAnd I was trying to think about how can I represent the intuition behind this idea in a way that you can get your head wrapped around an event or two? And I thought, oh wait, okay, so it's Halloween. And you've just come home with your big bag of loot. You got your big bag of candy, and you want to know which is the worst candy, which is the best candy. You want to trade with your sister. And so you want to make sure you know that you're trading the bad stuff, keeping the good stuff. You want your tootsie rolls to be given away. You want the big candy bars. You get the idea. So you've got this big bag of candy. You want to sort it.\n\nWell, how do you go about doing that when you got a whole big bag of candy? How could you possibly go through and sort that in a reasonable way? Well, here's what you do. You dump out your candy on the floor, and you pick out a random piece. And you say this piece is going to be the decision piece. It's going to be the pivotal piece. And I'm going to take everything that's worse than that piece, and I'm going to put it in a pile to the left. And then take everything better than this piece, and I'm going to put on a pile to the right. That's all you do. \n\nSo I'm just going to put the ones worse than this to the left, better on the right. That's an easy decision to make. And I'm going to put this piece in the middle. Well, then I'm going to take the pile on the left, and I'm going to do the same thing. I'm going to pick out a random piece, and I'm going to take everything that's worse than that one and put it on the left and everything better than it on the right. \n\nWell, now I've got three piles. And I'm going to do that to each of those piles and then any piles that come after that until I have gone through all of my piles, and all I have is a line of candy. And it's perfectly organized from worst to best, left to right. That is the Quicksort algorithm. For me, that illustrated, in my mind, in a way that I'm never going to forget. And that was a huge leap. It wasn't even a technical field at all. [chuckles] It was just something that came from life. But these intersecting ideas happen all the time, and being able to connect them gave me a huge aha moment. \n\nDAVID: That is awesome. Do any of us have any thoughts that we want to throw out on this? Is there something that you wish you could have said at this point that you want to get in? \n\nMIKE: Keep the joy of curiosity in your life. Find a channel where you can keep that curiosity alive. And I think it will serve you really well.\n\nDAVID: For me, I would say don't be afraid to go way, far afield with things. If you want to be a better programmer, study a parenting book, pick up the guitar and learn music, go hiking, learn how to hike better, actually study hiking instead of just throwing at it. Pick stuff way, way, way out, and you're going to find parallels to the thing that you do every day. And it'll surprise you.\n\nRAMSES: Yeah, that's a pretty good way to end it. Try to learn things that you're curious in and also things that scare you. [chuckles]\n\nDAVID: Yeah. Well, all righty. Thank you, everyone. This has been fantastic. I've missed coming back and hanging out with you guys. I'm enjoying my time over in the database land, but I missed the front-end, back-end work. Thanks, everyone, for coming.","content_html":"Today we dive in and talk about what we study to continue learning.
\n\nTranscript:
\n\nDAVID: Hello and welcome to the Acima Development Podcast. I'm your host today, David Brady. And today on the panel, we have Mike Challis, Eddy Lopez, Ramses Bateman, Kyle Archer, and Afton Call. Welcome, welcome, everybody. How's everybody doing? It's been a while since I've been on.
\n\nMIKE: It's good having you.
\n\nRAMSES: Yeah, it's been a while.
\n\nDAVID: It has. It's been. It's good to be back. All right, today we're going to dive in and talk about what do you study to continue learning? And I'm kind of excited to talk about this because this has been actually coming around on my feed and the things that I listen to. I've actually got some unusual answers to this, and I'm kind of curious. But I'm going to throw it out to the room because you guys know that when I show up, I talk too much, so somebody else talk. What do you guys study to continue learning?
\n\nMIKE: It's an interesting question because when I graduated from high school, my career didn't exist; that is, you couldn't be a web developer. That role didn't exist in the early '90s. There was no such thing, right?
\n\nDAVID: Yap.
\n\nMIKE: It didn't really exist in a meaningful way for some time after that. We've touched on this idea before on the podcast that there are some accidents of birth and your background that sometimes affect your career trajectory. This is kind of a big deal. The industry is changing, and it's a new industry for web development in particular but kind of anything that touches the internet that didn't exist in any meaningful form. So if you're not learning, [laughs] you might not even have the chance to have a career because, like I said, the career didn't exist. Mobile development didn't exist...what? Ten years ago, 15 years ago. That didn't exist as a profession because there was no such thing as a smartphone.
\n\nDAVID: I saw an actual study on that. I cannot remember the number now, but it was an alarmingly large number of people in the technical sector who had jobs that did not exist when they started college. They graduated and went straight into a job. And their job is ecclesiastical brand manager, or technology evangelist, or data personality manager. What is any of this stuff? And yeah, if you're not studying now to grow yourself, there are entire jobs coming that you're not prepared for because it's not coming down the mainstream curriculum.
\n\nMIKE: And that you couldn't be prepared for. Yeah, there's not going to be a university degree for it because they'd have to invent the field, right? [laughs]
\n\nDAVID: Mm-hmm. Yeah.
\n\nMIKE: And you're not going to learn mobile development in college if the iPhone hasn't come out yet. There's a chicken and egg sort of problem; one of them has to come first.
\n\nDAVID: And academia is 20 years behind, right?
\n\nMIKE: Yes.
\n\nDAVID: I remember in 2005 or 2006, the people that I was working with that were coming out of BYU were all Java programmers, and I was really surprised by that. I'm like, when I went there; it was C++ and assembly language. And, oh, you guys are now doing Java. Java had been out for ten years, '96, I think, '94 when it came out, and now it's in academia. But everybody that was good at Java had been programming in Java for 5,6,7,8 years. And it was just now showing up in the colleges.
\n\nMIKE: And I think there's always going to be that lag. I mean, just in the best of all possible worlds, you had some really forward-thinking professor who notices a new thing, takes the time to gather the information, stays up to date on the latest state in the field, and writes a textbook. That doesn't happen overnight. In the best of cases, you're probably going to be at least a couple of years behind the industry.
\n\nDAVID: Oh yeah. There's a weird sentiment that I've actually heard a professor express, which is that universities have an obligation to present grounded, well-spread fundamentals, which means they actually have a duty to avoid fads. So the only way to avoid a fad is to wait for something to stand the test of time, and unfortunately, that takes time.
\n\nMIKE: So back to your question, [laughs] you got to stay relevant. And I enjoy learning. I enjoyed school. Let me clarify that because there are a lot of people who are like, "Oh man, school was awful." There are some aspects of school that can be wonderful and others maybe not so much. You look at little children, and they love to play. They love to explore. I look at my young kids, and they like to try out new things all the time. It's innate. They find great joy in creativity and exploration.
\n\nAnd if that's how you define school, hey, school is great. I get to go learn new things and try new stuff. That's play. But if school is learning things by rote and getting in big trouble if you made a mistake somewhere, well, that's not fun at all. So I clarify a little bit [chuckles] that when done right, I think for people in general, we have that innate curiosity and deep longing to try new things and to explore ideas. So yeah, that part of education I really enjoy.
\n\nMyself, I love to read. One thing I do is I subscribe to newsletters; some people do it in a different way. But that way, I can look through generally aggregator newsletters in academic fields which I'm interested in so that I can look through; so; here are some articles that may interest you. And I go look through, and I'm like, yeah, that one does interest me so that I can keep up to date on the state of the industry or on nascent industries, you know, things that are starting to form. I'm personally interested in machine learning, so I follow that pretty closely. I follow that.
\n\nI've also taken courses online in topics that interest me, both alone and with others. And I will say that taking a class with somebody else, you are far more likely to finish it because there's the social aspect to it, so I love that.
\n\nDAVID: Absolutely.
\n\nMIKE: And it is true also that just in the course of your job, you will encounter things, and you shouldn't be ashamed to go out and learn that as you're going. So that's a quick sampling of some things that I do.
\n\nDAVID: I love...there's a thing that happens to me occasionally in this field. When I'm talking to people, I talk about being an autodidact and learning and growing on your own, like, motivating yourself. And I actually hear people come back and tell me, "My boss tells me I don't pay you to learn." And I just laugh and laugh and laugh and laugh and laugh because I ask them, "What are you working on?" Because in software, what your boss hands you pretty much every single morning is, here's the thing that's never been done before, go do it. Uh, you sure your boss doesn't pay you to learn? Your job is literally to learn.
\n\nMIKE: Absolutely.
\n\nDAVID: I said at the top of the call that I had kind of a weird insight into this because of something that I had been looking into. And I was going to try and hold it in my back pocket, but you stepped right onto it, Mike, with talking about children. There was a fantastic video...I'll have to dig it up. If we've got show notes for the show, I'll put these out, but if not, you can search for it on YouTube.
\n\nIt's a discussion that Neil deGrasse Tyson had in an interview. And he got asked, "What do you study? What are you learning right now?" And he kind of goes off on this tangent about the things that he's studying, about how he's interested in studying how people learn and how people change the way they think. But he veers into this beautiful, beautiful anecdote about how as an educator, he feels that it's his job to spend energy teaching people to love experimentation. And he needed to illustrate what does that mean.
\n\nHe's like when you have a six-year-old pushing a tray table with a glass of water on it, and that glass is shaking, that's an experiment. This child is doing an experiment. If I shake this, it tips, it falls, the glass breaks. That's an experiment. I have a situation. I have a stimulus. I have a response. And so many of us, the natural instinct is don't do that, don't do that to the degree that it's just simply a day-to-day occurrence. Yeah, sure, I mean, you got to live with your kids. [chuckles]
\n\nBut if you can view it from the point of view of this is an exploring creature conducting an experiment on the universe outside of them, and I want to encourage them to gather prima facie evidence, first-hand evidence on the universe around them, you let them break the glass. And you say, "Okay, what did we learn?" without shaming them, not the "What did we leaaarn?" No. But literally, "No, seriously, what did you learn? Tell me what you learned from this."
\n\nOr if you must be preventative in this, step in and say, "What do you think you're going to learn? What do you think is going to happen here?" And again, not to do it in a shaming way but to do it in an encouraging way, and that takes energy. I mean, you got to go buy a new glass [laughs] and then replace it. You got to clean up a mess if the child's too small to clean up broken glass.
\n\nBut that child goes on to become a scientist or an explorer because they end up with a first-hand thirst for exploration and knowledge. And they also gain this core belief that exploration is safe and wonderful rather than damaging and hurtful because I got yelled at when I broke a glass. I was blown away that that's what Neil deGrasse Tyson is studying right now is that level of learning. And I thought, wow, he's literally learning how to learn and how to teach people how to learn. That's cool.
\n\nMIKE: We could probably spend a lot of time talking about the joy of exploration that children have. And maybe that could be a guiding principle as we're talking about this topic. What do you do to stay up to date? Well, be curious. [laughs] If you've got curiosity, feed it because if you don't feed it, it will kind of atrophy, and you'll find yourself burned out and bored. But if you feed it, then you're going to find your career pivoting, and you're going to be in that job that didn't exist ten years ago because you'll have gradually migrated and followed your curiosity into something new.
\n\nDAVID: Absolutely. What are things that we can do if not to, I mean, I think it's like a foregone conclusion for us to say we got to keep learning; we got to keep growing. Are there conscious, explicit things that you can do? I know that the Atlas team at Acima there's dedicated time on the schedule. This is learning class. This is time for us to sharpen our skills. Skills Clinic is literally what it's called. And it's an invested amount of time. I've not worked at a place that had that dedicated, so most shops, in my experience, don't do that.
\n\nWhat can you do to encourage those around you to learn or to create? I just realized I'm trying to trick you into giving me the answer that I want. And the answer that I want you to give me is that if I go create the environment where everybody's learning, then I get to learn too. So I'll throw that out. But what can we do to create an environment of learning where other people can learn, grow, and continue, and we can learn, grow, and continue? And who cares? Not just for you getting your next job but how is that going to benefit your employer here today?
\n\nMIKE: You dropped a couple of hints there. [chuckles] The first is you said, well, you do the skills clinic where you dedicate your time every day. Well, not everybody out there is going to be able to walk up to your boss and say, "We're going to start taking an hour every day learning stuff." Now, a lot of you probably could because your boss might be like, "Okay, that sounds great. I want better-educated employees."
\n\nSometimes that might be a little overwhelming, like, wait, what? What about productivity? But you don't have to start that big. Start a book club. Start a book club. Now you are working with other people, which will help keep you motivated, and you can do that together. Or go find some people who are interested in a class. Go take it at the community college, or a local university, or online. Most of those are get together here. There's a recurring theme. [laughs] It helps keep you motivated if you wanted to make space for other people.
\n\nThere are things that you can do, I think, wherever you are to make that kind of space. You can say, "Let's read a book together. Let's do a book club, and then every week, we'll talk about it." You're not taking very much time. You can even do it on your lunch break. You can make that space. "Let's go take a class," and then you swap ideas. [laughs] You give each other support like, "Hey, have you done homework yet?" [laughs]
\n\nYou can find somebody who is starting their career or who wants to start their career and say, "Hey, want to get together at lunch, and I'll help you out to learn some of this coding thing?" or this data thing, whatever it is that they're wanting to pursue. Well, now you have a recurring opportunity to get together and mentor somebody. And as you mentor, you learn a lot.
\n\nI threw a few ideas out there. I'm curious, other people I think have been involved in these ideas and more. I'm throwing these out because I've been involved in all of these things before. I mean, I've done these things. Other people, have you done other things, or if you participated in the kinds of things I mentioned, how did it work out?
\n\nRAMSES: One idea that we incorporate quite a bit, probably in our organization but specifically on our team, is encouraging the idea of pair programming and pair reviewing, which I think helps to promote a healthier understanding of how things work or should work, or can work and just alternative solutions. And overall, just better discussions and better collaboration, which I think is important. Each of us is limited by our experiences. And we're limited to our current understanding of things. So gaining someone else's perspective or insight and experience is tremendous.
\n\nAFTON: I agree. I think our pairing, which has been highly encouraged on the Atlas team for quite some time, is a great way to have this ongoing mentoring environment, which then helps everyone to continue learning because everyone is teaching. Those who know more are teaching those who know less, and those who know less get to have a chance to try and explain things to someone else, and that develops their skill. I think that's a wonderful thing that we have on our team.
\n\nI want to go back just a little bit to what Dave mentioned earlier, which was our skills clinic, and how that's been in place for a while as an opportunity for us to spend time sharpening our skills. And the funny thing is, and Mike can attest to this, is we started that skills clinic kind of as part of an internship. But after the internship ended, it was really hard to get the skills clinic to keep going. It was hard to get developers on the team to attend and take advantage of it.
\n\nAnd even before the skills clinic, the take an hour a day to sharpen your skills was talked about, encouraged. But I found for me; it was really hard to take that time. Even though it was being handed to me on a platter and said, "Do it," it was really hard to take the time. And it has been always really hard because when you're in the middle of a problem, it's hard to set it aside and go do something else. Context shifting is hard. You always just feel like I need to get this done. I need to get this solved. I need to get this out. Sometimes there's pressure to get something out quick. Sometimes it's other people are relying on me.
\n\nThere's just always a lot of weight going and pressure to get work done. There's always so much work to do that we can never catch up, which I think contributes to that. So recently, I realized something that has made a world of difference in me, taking that time to sharpen my skills as often as I can. I don't know that I'm getting an hour a day, but certainly, more than I was in the past. And what that was was thinking about my career and what I'm working toward personally.
\n\nSo I actually took this little online course on LinkedIn learning about...I think it was how to choose or organize your priorities when everything on your plate is a priority. [laughs] And so it was breaking things down into, well, you have to think about what's urgent, and what's important, and do the things that are urgent and important first, and then the urgent but not important or important but not urgent. They had this stack of how to decide what to do first.
\n\nAnd then it also talked about another way to decide and get things done that you keep wanting to do but haven't figured out how to make happen is to think, okay, where do I want to be a year from now? Where do I want to be in my career? What do I want to have accomplished? Where do I want to be five years from now? And I was thinking a year from now; I want to have better technical skills than I have today. And I want to have written a lot more code and have a lot more experience in our codebase.
\n\nAnd in my newish position as a team lead, it's been a lot harder to find time to be writing code and to be learning. But when I said okay, a year from now, if I haven't progressed in those two areas that are super important to me, I'm going to be really frustrated with myself. So the only way to make that happen is for me to make sure that every day starting yesterday [laughs], I prioritize that.
\n\nAnd sometimes, I have to take something that is a priority and say I'm not going to do that for one hour. And instead, I'm going to spend some time sharpening my skills or working on a ticket because that is also a really high priority. And that's made the difference for me is knowing what my goal is for myself a year from now, five years from now.
\n\nDAVID: That's amazing. That's awesome. Thank you. There are so many things you just dropped on there. I'm writing frantically. I love that idea that there's always so much to do. I would amend that and say there's always too much to do. And just like you said, when everything is priority one, nothing is priority one. Well, guess what? You can weaponize that to your advantage.
\n\nIf you can't stop to improve your skills and invest in yourself because you always have too much to do, then stop and invest in yourself because you're still going to have too much to do, whether you stop and invest in yourself or not. And a month from now or a year from now, if you have increased your capacity a month ago or a year ago, you're reaping the benefits of that.
\n\nAFTON: Yeah, absolutely.
\n\nDAVID: You said having a goal, and it reminds me of a thing I did in...oh God, [laughs] somebody told me once that "I hate when programmers stand around telling war stories." This is totally a war story. I'll make it quick. Back in like 2006 or 2007, I had gotten into Ruby on Rails, and I was really excited about it. But all the work in my hometown was PHP. And I had a customer approach me. I was freelancing back then. I had a customer come to me and said, "I want you to build me a website from the ground up."
\n\nAnd this was an old customer. We had a really good trust relationship. And he also paid me miserably. [laughs] He wanted old rates from 10 years ago when you didn't know how to program. And I negotiated with him that I will do this for you, and I will do it at the old rates, but I'm doing it in Ruby on Rails. And he didn't program, you know, I basically told him, I'm going to do this with a left-handed metric spanner, and he was like, yeah, okay, knock yourself out.
\n\nAnd because I had that as an explicit objective that I want to get professional experience working in this, I was able to just gin it up out of whole cloth and basically say, I'm starting this project professionally because I'm a consultant and I can do that. And then, a year later, when I got the opportunity to work in Ruby on Rails at a company, and they were like, "Well, what experience do you have?" I'm like, "I've been doing it for the past year." And that was super, super useful.
\n\nMIKE: Interesting. My intro to Ruby on Rails was somewhat similar. I was at a company doing Java. They said, "You know what? We need to use an interpreted language. We want the flexibility and speed that we've seen other people have in interpreted languages. So you're going to do PHP." And I'd done quite a bit of PHP kind of on the side. And I thought, given the state of that language community at the time, I thought, if we do this, we're going to have a horrible ball of mud in no time flat. I need to use something that has a framework and organization that we can work with.
\n\nAnd I heard a presentation about Ruby on Rails at a Java Users Group. It was like, "Yeah, there's this new framework in beta called Ruby on Rails." So I went and wrote the seed of our rewrite in Ruby on Rails over the weekend, kind of learned the language and the framework. I spent a long weekend. I came back, and I said, "Okay, well, I've got this prototype. What if we try this?" Like, okay, I mean, you've already got it; we might as well. [laughs] And we ran with it. And I've been doing it ever since.
\n\nDAVID: That's awesome. Rails had that sneaky underdog thing. There was that seminal post by DHH, "Build a Blog In 15 Minutes." I've seen that happen as well where somebody says, "Oh, let's switch to Rails." And they're like, "Well, what's the start-up cost?" It's so great to be able to say, "I wrote it on the car over here today," or, "I wrote it last night." The start-up is done. Now all that's left is all the really hard work. But you don't tell them that. You just tell them, "Oh, look, the start-up piece is done. That's half the work," right?
\n\nMIKE: [laughs] It's true. I can say that that application we rewrote ended up having one-tenth the number of lines of code, and it did more. But that doesn't necessarily mean better. So, I mean, I'm not trying to be a framework snob or anything here, [laughs] but there were some definite pluses that came from it. But yeah, exactly; if you come with the prototype, it's a lot easier to sell your cons.
\n\nDAVID: There's a line count that, in my experience, Ruby has about somewhere between a 3:1 and a 10:1 ratio of line count. Prior to Rails, I was used to working on C++ projects with half a million lines of code and then PHP projects that had 100,000, 150,000 lines of code. And now, if I see a Rails project with more than 30,000 lines of code, I get scared because that's a big project because you can do so much.
\n\nAnd there are trade-offs to that. It's a lot harder to tell your manager, "Oh, yeah, I wrote 1,000 lines of code today." It's a lot harder to do that in Ruby than it is to do it in C++ because there's just so much boilerplate. You get 900 lines for free.
\n\nMIKE: And you need to recognize there's trade-offs as well. We are talking about interpreted languages. In Ruby specifically, you don't get some of the type checks that you get from other languages, and there are some real trade-offs there. I'm thinking TypeScript is overtaking JavaScript. It compiles to JavaScript; I mean, it's the same language, basically. But people want to have that type safety because it avoids certain kinds of problems. So, I mean, absolutely, there are trade-offs but interesting ones. We can really get into this. [laughs]
\n\nDAVID: Oh yeah, I can drill into this really easily. There's a concept that I've seen, well, actually, this is a good example of learning, and then all of a sudden...what I will say about studying to learn something is don't be afraid to chase a tangent because that's where all the marrow is. That's where the juiciest tidbits are is when you're in the middle of something, and then, whoo, we go off down this sidebar. But when my ADHD fires way too hard, I look around, and I realize everyone's eyes are glazed over because we're seven tangents deep.
\n\nAnd there's an idea where those of us coming from old statically-typed languages we had all this upfront checking that the language had to do. And that cost ceremony, and that caused us to slow down. And it was very frustrating, and we wanted to go fast. And these interpreted languages came along, and these dynamic languages, and it's like, oh hey, look, we don't have to do our upfront checking. Well, then our programs blew, so it's like, okay, we need to do unit testing. We need to test at the other end.
\n\nIf you're not going to test that all the types are correct, then you have to test that the program behaves correctly at the end of it. And there's a really phenomenal thing in the industry where you can see some people going; I don't have to check upfront, but I'm too lazy to actually come back around and test at the end. And those people, bless their hearts, their co-workers are the ones who are saying, "Let's maybe go back to statically typed. I think it would be okay if Jim could not write software without enforcing something on either end of this. Let's hook into somewhere.
\n\nMIKE: We should do an episode on typing.
\n\nDAVID: Oh yeah. I can do about 110 words per minute.
\n\nMIKE: [laughs]
\n\nDAVID: Oh, wait, wait.
\n\nMIKE: Ramses mentioned pairing. That's really interesting. You didn't say formal study but getting involved with another developer so that you're sharing ideas with each other. Kind of continuing on this idea of tangents, those of you who have learned something pairing, do you usually learn something that you were expecting to learn when you're pairing with somebody?
\n\nDAVID: Never. I'll let somebody else take the question, too, though. [laughs]
\n\nRAMSES: Yeah, not always. You never really know what you're about to learn. Like, it's not really super formal. So you just get together, do some discussions, and throw out different ideas, different solutions and see what you come up with. It's always an interesting and unexpected experience.
\n\nMIKE: Yes. So you set up to solve a problem. You're pairing to solve a problem, and you end up learning something. I was talking with some people about recursion earlier this week about a function calling itself. And we ended up talking a good deal about memory management, about how your computer manages memory, and the operating system, and addressing, and pages in memory, virtual memory, kind of far afield from recursion.
\n\nBut we talked about that so that we'd understand how that stack of function calls eventually is going to run out of space. So we went in with one goal in mind and ended up somewhere very different. But they're both useful. It always happens that way if you let it happen. You leave room for that spark.
\n\nDAVID: Yes, it's very important to not fall into the trap of trying to predict the spark. Or rather, you can absolutely predict that the spark will happen. I've done podcast episodes where everyone is sitting around going, "What are we going to talk about? I have no idea what we're going to get out of this." And I just told everyone on the call, "It's fine. Just sit down, relax. It will happen. Trust me; it will happen." Banking on the spark happening is absolutely doable.
\n\nBut if somebody sits down and says, "What are you going to learn today?" It's really hard. Mike, you might have sat down and said, "Well, we're going to learn about recursion. We're going to learn about creating base cases. We're going to get into mutual recursion where this function calls that, and that function calls back into this other one," and blah, blah, blah, and down the road, you go.
\n\nNowhere on your prospectus would you put we're going to learn about how memory management, dah, dah, dah, that the heap is well managed and the stack is not, and dah, dah, dah, and down you go. If you lock yourself into that predictive deductive thinking rather than walking in open-armed and ready for inductive learning, you'll cut yourself off from your own creativity. What's the rule from writing? You can't create and edit at the same time. You can't be an editor for your writing while you're writing everything you're writing. I've missed the conversations where I throw three metaphors at a problem at the same time; there you go.
\n\nMIKE: But we went there, this idea that pairing is a really great way to enhance learning. You don't go in there necessarily with a goal in mind. Instead, you create an environment where that curiosity and exchange of ideas can happen.
\n\nAFTON: I want to say that this learning from pairing is not limited to learning additional technical skills like some new coding trick or even a new design pattern or something, which are definitely valuable. But one thing I also get from pairing is getting to see how someone else's process works. What kinds of questions do they ask to navigate the problem we're trying to solve? Where do they go in the code? How do they figure out what questions to ask and where to look? And what are the steps that they take from start to finish to solve a problem? I think processes are super interesting, and having a good process can make you more effective.
\n\nThis kind of goes into what I was thinking about what I do to continue learning. I realized also recently that I have two different areas of learning that I focus on; one is on super technical skills, learning a new language, or refreshing my Ruby on Rails knowledge, or even studying algorithms, which we've been doing in our book club. But on the other hand, I'm also studying how to manage projects, how to communicate well with people I work with, like on my team. Right now, as a leadership, we're starting crucial conversations and learning about how important it is to be able to talk to people and communicate well your intentions and your ideas, and organize your thoughts and respectfully, and all those things.
\n\nAnd we mentioned in an earlier podcast episode; development is so much more than just writing code; we do so much more. We are teammates. We're working with other people. We're organizing projects. We need to know how to manage our time to be efficient and effective. And so I also study time management and figuring out your priorities, how to figure out your priorities, leadership skills, communication because I believe that all those things are also going to make me a better developer, a better teammate, more effective in my career.
\n\nDAVID: There's a thing...I believe it's called the synthesization step or integration. I can't remember. There are steps to learning ideas. And for me, the exciting thing is near the end when all of a sudden, you find out that these wildly disparate fields of study are 100% overlapping where you're getting into time management, and you're like, okay, this is important, and it's essential. And I have no control over where it's going, so I have to focus on the process and just let it go where it needs to go. Or this other thing is not important, but it needs to be done. So I need to focus on what is the fastest way to get to this outcome?
\n\nAnd then weeks later, you're having a conversation with a co-worker, and you realize I need you to write this to this API. I don't want to talk to you about your feelings about it. We'll do that at lunch. I just need you to do this, and I need it done quick. We've got this other deadline. It's like, I need to be efficient with you. I need to focus on the outcome, boom, boom, boom.
\n\nAnd then an hour later, you're talking to somebody else, and you realize they are wide open vulnerable. And you suddenly realize I can't be efficient right now. Efficient is the most deadly thing I can do to this conversation. I have to be effective in how I communicate with this person. And so you're like, you know what? I'm clearing my schedule because this is important, and I don't know how long it's going to take.
\n\nWhen you see those parallels, you study how to communicate with people. And then a week later, you're writing some code, and you're like, oh, how do I document this function? And all of a sudden, you realize, oh yeah, I know exactly how the person reading this...I know what they're going to be hungry for, what they're going to be looking for. I'm going to document that, or I'm going to write a unit test that expresses this.
\n\nAnd it's kind of nice to have somebody come back and find you and say, "I love that test that you wrote because I could not figure out what your system was doing until I saw that test. And all of a sudden, I could see the through line in all of your software." That's amazing. I've had that happen once in my career, and I'm still bragging about it on podcasts today.
\n\nI have a weird question for the group. You know me, I love weird questions. What is the weirdest, most out-there thing that you have learned that you've been able to bring into a professional situation with benefit? I mean, obviously, some of us bring weird stuff into the office just for the sake of bringing weird stuff into the office, and it doesn't always go well. But is there something that you guys can think of that you're like, I did not expect to use that at work today?
\n\nRAMSES: Yeah, that is a weird question, and I don't know if I have a good response for it. I spend a lot of my time trying to learn new things to improve my workflow and to improve my knowledge. I don't know if I have a better response for any weird things.
\n\nMIKE: I'm trying to think of a specific example. It feels like everything that I end up studying ends up crossing over. So here's a recent example. I'm going to take my kids out trick or treating. We'll probably release this next year in March or something. You're like, wait, what? [laughter] But we're recording this in October, and here in the U.S., we're doing Halloween in about a week. And we were talking about how to do a quicksort earlier this week, or I think it was last week. Recently, we were talking about how to do quicksort.
\n\nAnd I was trying to think about how can I represent the intuition behind this idea in a way that you can get your head wrapped around an event or two? And I thought, oh wait, okay, so it's Halloween. And you've just come home with your big bag of loot. You got your big bag of candy, and you want to know which is the worst candy, which is the best candy. You want to trade with your sister. And so you want to make sure you know that you're trading the bad stuff, keeping the good stuff. You want your tootsie rolls to be given away. You want the big candy bars. You get the idea. So you've got this big bag of candy. You want to sort it.
\n\nWell, how do you go about doing that when you got a whole big bag of candy? How could you possibly go through and sort that in a reasonable way? Well, here's what you do. You dump out your candy on the floor, and you pick out a random piece. And you say this piece is going to be the decision piece. It's going to be the pivotal piece. And I'm going to take everything that's worse than that piece, and I'm going to put it in a pile to the left. And then take everything better than this piece, and I'm going to put on a pile to the right. That's all you do.
\n\nSo I'm just going to put the ones worse than this to the left, better on the right. That's an easy decision to make. And I'm going to put this piece in the middle. Well, then I'm going to take the pile on the left, and I'm going to do the same thing. I'm going to pick out a random piece, and I'm going to take everything that's worse than that one and put it on the left and everything better than it on the right.
\n\nWell, now I've got three piles. And I'm going to do that to each of those piles and then any piles that come after that until I have gone through all of my piles, and all I have is a line of candy. And it's perfectly organized from worst to best, left to right. That is the Quicksort algorithm. For me, that illustrated, in my mind, in a way that I'm never going to forget. And that was a huge leap. It wasn't even a technical field at all. [chuckles] It was just something that came from life. But these intersecting ideas happen all the time, and being able to connect them gave me a huge aha moment.
\n\nDAVID: That is awesome. Do any of us have any thoughts that we want to throw out on this? Is there something that you wish you could have said at this point that you want to get in?
\n\nMIKE: Keep the joy of curiosity in your life. Find a channel where you can keep that curiosity alive. And I think it will serve you really well.
\n\nDAVID: For me, I would say don't be afraid to go way, far afield with things. If you want to be a better programmer, study a parenting book, pick up the guitar and learn music, go hiking, learn how to hike better, actually study hiking instead of just throwing at it. Pick stuff way, way, way out, and you're going to find parallels to the thing that you do every day. And it'll surprise you.
\n\nRAMSES: Yeah, that's a pretty good way to end it. Try to learn things that you're curious in and also things that scare you. [chuckles]
\n\nDAVID: Yeah. Well, all righty. Thank you, everyone. This has been fantastic. I've missed coming back and hanging out with you guys. I'm enjoying my time over in the database land, but I missed the front-end, back-end work. Thanks, everyone, for coming.
","summary":"","date_published":"2023-04-12T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/cae052a7-9bfb-4fa4-8b53-952aa659928a.mp3","mime_type":"audio/mpeg","size_in_bytes":39928854,"duration_in_seconds":2161}]},{"id":"fa0ed9b9-42ab-43d4-a677-656c6c5db128","title":"Episode 14: Teaching Kids to Code","url":"https://acima-development.fireside.fm/14","content_text":"We talk about a fun topic–teaching kids to code!\n\nTranscript:\n\nMIKE: Welcome to another episode of the Acima Development Podcast. I'm Mike. I'll be your host again this week. And we've got with us Eddy, Ramses, and Tad. Today is a fun topic. We're going to be talking about teaching kids to code. I thought that I might start the session [laughs] with a personal story, a couple of them actually that I think are relevant and will help inform our discussion. \n\nI remember my first experience coding as a kid. This is way back in the ye olden days of yore [laughs] when computing was different. When I was in about third grade, we got to use the school computer because the school had a computer, and classes would take turns playing with it. We had Logo, which is software that allows you to move a little turtle around the screen. You code it to walk around the screen. That was cool. It was real-time feedback. \n\nYou tell it to move; it moves. And you tell it to move again; it moves. But we learned that there was a way you could go into a back screen where you could type in loops. And I remember playing with that and thinking it was the coolest thing ever. [chuckles] I wanted to do that all the time. But I had to use my 10 minutes of computer time on the shared school computer, and that was it. [laughs] \n\nAnd I didn't really get to use a computer again for some time, except that I did have a couple of friends who had coded in BASIC and taught me some things, which I also thought was cool. I remember that in sixth grade, the teacher tried to show us how to code. They had the BASIC environment there. And I thought, oh, I remember how to do this. And I wrote line 10, and I had it print out my name, and line 20 GOTO 10. And I ran it because I remembered how to do that. And it just started printing my name endlessly. \n\nAnd the teacher, who was really unfamiliar and was just following a set of instructions and had no idea how to undo that couldn't stop it, had to restart the computer. And by the time the computer got restarted, our computer time was done, and we had to go back to class. [laughs] So I ruined the coding session for everybody. It wasn't a high point, [laughs] and the teacher was not at all happy with me. \n\nI can tell some other stories of learning to code later. But there's some commonality there. [laughs] Coding was fun when I had a chance to have fun. And it didn't work out very well, and there weren't resources for me to play. But also, there wasn't somebody around who could give me some guidance. The teacher wasn't able to find any help. It meant I did something fun and then got lost and frustrated, and that was kind of the end of it for everybody. And unfortunately, I ruined the day for not just myself but a bunch of other kids. \n\nThe kids love to explore. Kids explore by nature and want to go out exploring, and given the chance to do that in the right environment, will tend to latch on to it if they get the support that they need. With that context, let's go on and talk about some ideas for helping kids to code. We were talking a little bit before we started today about some experiences other people have had teaching kids to code. I've myself had a decent amount of experience. \n\nI've taught several kids to some degree how to code, including my own and those of friends and relatives. So I've got some background doing this, have some ideas but certainly don't have all the ideas. There's so much out there, and there's so much science of teaching that I'm sure there are all kinds of things that I'm missing. And I'd love to hear what other people have to say. First of all, any thoughts based on my story or thoughts to begin our podcast?\n\nTAD: Yeah, as I was thinking about this, there are maybe three things that really interest me when people talk about this kind of stuff because I'm curious how they got started. And those three things are, how did you first get access? What was your hook? What was the thing that got you interested and got you started? And the third thing is, who was your mentor, or who was the person who came along and gave you the nudge that got you in? \n\nBecause as I was listening to your stories, I'm like, these are some common elements that I've noticed in a lot of people's experiences. And so I'd be curious to hear from Eddy and Ramses because Mike, you, and I are both in our 40s. And so that first one, how did you first get access to a computer? Is [laughs] because they weren't ubiquitous when I was a kid, right?\n\nMIKE: No, they weren't.\n\nTAD: I remember when every teacher in my elementary school...I think I was in fourth grade. Every teacher got their own computer for their own classroom, and that was big. And you'd hear about computers, but they weren't really common and really accessible. So I'd like to hear other people's experiences; just how did you get access? What was the hook that got you interested? And who was the person who gave you the nudge? Maybe you don't have those three, but I've found those to be very common elements when talking to people about how they first learned or what got them into it.\n\nEDDY: Actually, it's kind of funny; you kind of struck a chord with me there because I'm like, dang, when did I get interested in that? To give some context, I'm hitting 30. And back in elementary school, there wasn't high-speed internet, so the only way we had access to the internet was connecting to the phone cord. And you had to switch back and forth between taking a phone call [laughs] and connecting to the internet. So it was like dial-up. \n\nAnd the problem was that cell phones weren't very prominent at the time. My mom would always go and scream at us, and she's like, \"Hey, disconnect from the internet. I need to make a phone call.\" When she wasn't on a call, we had no access to the internet. And so we dabbled around, my older brother and I, on how to change elements in HTML. And seeing little buttons and text being changed and rendered was my first exposure because that's the one thing I could do without internet access.\n\nMIKE: So the computer [laughs] was dial-up internet. The hook was being able to make changes in HTML so you could make a webpage. And is it your older brother who got you interested?\n\nEDDY: Yeah. Initially, it was him. And he kind of just flew with it for a while. I kind of just sat back and watched him modify some tags. But it was something that we could do while not having access to the internet. [laughs]\n\nMIKE: What about you, Ramses?\n\nRAMSES: I'm in my late 20s as well. I've always just been around computers. I think I was first exposed to computers when I was like five, probably. We got a home computer for Christmas one year. But yeah, it was a lot of fun. I don't really remember being super interested in coding when I was really young. But I think I was just always intrigued by technology and building things. Mid-20s, I got more interested in learning coding and taking it a lot more seriously. So I really enjoy it because you get that feedback like you mentioned. And it's great being able to build things and to build something and know that you're helping someone.\n\nMIKE: I'm with you on that feedback, that moment you realize you don't just have to be a consumer of what the computer gives you. You can make that a two-way conversation and ask this tool to do things for you and have it do that, and it's just magical.\n\nEDDY: Was there anybody who kind of nudged you into it, or are you kind of self-taught, self-discovered?\n\nRAMSES: Kind of a combo, like, self-motivated. I don't want to take all the credit myself. [laughs] I mean, I'm self-motivated, but I think I learn a lot from other people. There have been a lot of mentors that I've had. Mike was a prominent one early on and still is, you know, Afton, Tad, a lot of other people.\n\nTAD: My curiosity is, were you thinking about taking this track when you first started working for Acima, or was it you found a niche in QA, and then from QA, people kind of nudged you over into development?\n\nRAMSES: Yeah, it was exactly that. When I was in application support, I found kind of an opening that expanded my interest in learning software development. And I don't know if there was any single person that kind of pushed me. There were probably multiple. One of our old product managers, Jeff Madsen, was a pretty big proponent of that. Mike Challis was a proponent of that as well. I think he nudged me a little bit.\n\nMIKE: Something interesting to me about that is we all have different paths here, those who picked it up more as adults, and I'm going to talk about you, particularly Ramses. A lot of people potentially listening to this who may be coming from a background where like, well, yeah, I don't have a traditional computer science background. I've never really done coding, but I've started doing a little bit of work. \n\nBut there is this...not really the back door or the front door, like, the side door [laughs] where you're at someplace that's...it could be a business. It could be something that's not even specifically a business but any organization where you have an opportunity, maybe unexpectedly, you just start doing this work. A lot of times, people think, well, this is just kind of this side thing that maybe I'll pick up a little bit. But that can be a real gateway into a career. \n\nAnd I've known a lot of people now who've gotten into the career not by saying, \"Oh, I'm going to go to school. I'm going to get a four-year degree, and then I'm going to go do an internship, get a job,\" like have this really clear linear path. A lot of people don't come in that way. They are in application support, and they get an opportunity to expand their roles, start doing some coding, and eventually, they become a full-time developer. And this applies in actually kind of diverse fields. \n\nThere are biologists who have found that to understand their data better, they needed to learn how to do some coding and machine learning. And so they became coders and started building up the tools to do better analysis of their data. Now they're developers and biologists. And the same thing applies to doctors or...those are just some that come to the top of my head that I read about. And these are kind of high-prestige professions. But there are some things that are less prominent that are also important. \n\nBut there are many professions that don't necessarily have a lot of visibility but have need for some sort of software. And if you can get in that a little bit, it's surprising just how much that need is there. And you can step into it, again, through that side door and find yourself with a fairly different career because you latched on to that and just kept on working on it.\n\nTAD: Right. Yeah, I've met a lot of developers who came to it from one of these side doors, like you're talking about. Because it's really interesting to me, software is everywhere and really touches everything in our lives now: it's in your phone, it's in your car, it's in your...whatever appliance you're using to make your breakfast. [laughs] It's in your fridge, like, it's really surprising all the places that you find software now. \n\nAnd it's interesting because I worked with a guy who was a physics major, but he's like, \"Oh yeah, I had to model some things. And so I had to code some things, and I found out, oh, I really enjoy this more than I enjoy physics.\" I worked with a guy who was into accounting and uses Excel all the time. \"Oh, I've got to write macros for Excel. Oh, I'm going to learn some more Visual Basic so that I can write better macros for Excel. Oh, I actually prefer writing macros over my regular accounting job.\" Suddenly, they became a developer.\n\nOr I had a friend who was a journalism major in college, and he really liked to investigate and figure things out, and that led him to documentation and stuff, which led him into software development. So it really is everywhere. And it really is possible to transition from pretty much anything over into software development because it's so ubiquitous, I think. \n\nMIKE: I agree wholeheartedly.\n\nEDDY: I kind of want to touch a little bit, like, you mentioned before on this call that you were successful in teaching your kids how to code, and one of them is actually going to school for that. How did you engage or propose the idea to your kid? Because I'm sure you proposing that idea had some sort of influence.\n\nMIKE: Yeah, that's a great question. It's a perfect segue into talking about what you can do specifically for kids. We've talked some about adults here more than kids and then a little bit with kids. There's the same idea of that hook and how people get started. My oldest, my son, he is now 18. He's going to...he's in college, University of Illinois. \n\nWhen he was fairly young, I think the first coding that I exposed him to is that he would sometimes be working on math and want to have a better calculator than what he had. So he's working on his math homework, and he wanted to add some numbers together or do something like exponents, where it's a little more sophisticated, and you want to do a bunch of steps. \n\nOne thing about the way simple calculators work (I guess there are more sophisticated ones now and maybe even on your computer.) they usually perform the operations as you type them. So rather than being able to write out the entire program, you know, I say program but kind of the problem that you're working on and then execute it; instead, you do one step at a time. And it's very easy to lose context, and you kind of lose track of where you are. And you don't have a history of work that you can go back and check, which is frustrating. [laughs] \n\nSo I started showing him, \"Hey, you can come up to this console and do some live coding and interact with the computer that way.\" I made sure to teach him several languages at once so he can see there's more than one way to do it. And they are pretty similar. I remember showing him Haskell, which is [laughs] a more obscure language but very mathy. And I said, \"Hey, look, you can open this interactive console and just type in some Haskell, and you can get the results back.\" He's like, \"Oh, cool.\" And I think I showed him Python and Ruby. All of them have the read–eval–print loop where you do interactive coding, or REPL, people will call it. \n\nAnd I started showing him that, and he's like, \"Hey, this is really useful.\" So he'd be using this. He'd pull this up on a laptop for his math class. So he could write out the problem, check that he had written down the problem correctly before he executed it. So unlike a calculator where you don't get to check your work, you can go back and say, oh, which steps did I do wrong here? And that was really helpful to him. \n\nAnd once I had that hooked, well, now he knew that it was useful. Now he knew that there was a tool that he could use to make his life easier. And really, it wasn't super hardcore coding. It was just typing some simple arithmetic expressions. But that gave him the hook he needed to be able to start doing more. Beyond that, I started introducing him, when I had the opportunity, to some additional kind of sandboxes to play in.\n\nAnd there are several tools I'd like to call out here. There's a popular one that we never really did use called Scratch, which is not too far from the Logo I used when I was a kid, where you can give instructions to tell an animated character or some sort of avatar or icon to move around the screen. And Scratch is popular. It's widely used in education. Probably a good option if you can find somebody who's interested in it. It just never really spoke to kids I've worked with. But there have been some other things. \n\nOne thing that most kids seem to love is Minecraft. And Minecraft has a huge modding community. Huge. [laughs] I know that there's a similar game, Roblox. There are a lot of sub-games in Roblox that people have created by coding them up. Roblox is kind of designed around having this, hey, you build your own mini-games community, and a lot of people have done that as well. So I think that's also another great option. If you've got a kid who's into Roblox, well, great, they can build their own games. I would strongly recommend something like that. \n\nSo my son really was into the idea of Minecraft. I showed him how to mod a little bit, and it was kind of daunting. There was a company who provided several classes on how to do the modding. He went through their program and really enjoyed it. And he built his skills by learning how to mod Minecraft. And once he had that, then he was able to...I showed him some Python, so he was able to start doing some Python.\n\nAgain, I signed him up for some other classes that he had some interest in, and he just grew and grew. He writes scripts now to solve problems that he has. Like, he wrote a little Python program to give himself flashcards so he can study for a Spanish class which goes back to right where we first started. It was useful for him. He was able to use the computer to do something cool. He was going to come back to it because it helped him out. All of those tools have been really useful. \n\nThere's another one that I've used I'd maybe like to revisit in a little bit. When I've talked to a group of people, that tool...and there are probably others like it. This one that I've used is called Sonic Pi. I believe it's open source. Honestly, I haven't really looked into it. But it's a tool that was designed to run on a Raspberry Pi to be really accessible for educators because you can run it on minimal hardware. And it allows you to do fun stuff with audio. You can code audio and so be your own DJ with writing code and write your own music, which is fun.\n\nEDDY: That's interesting. You just found a way to engage them. And I think that's really important. In order for a kid to learn something, you make a game out of it and create activities around it to stimulate the brain. And that's really interesting, truly. And not only that, but sharing enthusiasm for their progress, I think it's important. That attributed to some of my little sister's advancements, too, the little she had. It was like, \"Oh, you got your character to move like one pixel to the right? Oh, that's awesome.\" [laughter]\n\nMIKE: Which sounds trivial, but it really is kind of awesome, isn't it? It really is this sort of magic that you can take this amazing device and have it animate things for you, automate tasks that historically was the domain of things that humans could do. And it may seem trivial to move it one pixel to the right, but can you imagine having to draw that by hand, trying to hand-animate anything [laughs] for that matter? The massive amount of tooling and experience that would be required to accomplish something like that would be prohibitive in almost all cases. Having a tool that can do that is amazing. And there really is a magic to having that character move a pixel to the right. \n\nEDDY: You're like the puppeteer. \n\nMIKE: Tad, I think you'd mentioned earlier that you've had some experience getting kids hooked on coding or giving them some experience. Do you have any tools or advice that you'd recommend?\n\nTAD: It's hard because there are so many things out there. You almost need to find...well, I keep talking about the hook. What are their interests? There's probably some hook you can find that will get them interested. To be fair, coding isn't for everybody. There are people that... [laughs] my oldest daughter just started college, and she's going into natural resources and wildlife management. And she very directly told me that she wants to be outdoors, and she doesn't want to sit in front of a computer, and she wants to do certain things. And I'm like, okay, yeah, you're probably never going to be a programmer. You'll definitely be using computers for things, but coding is not your thing, and that's fine. \n\nBut I used to help kids just tweak mods for Minecraft. They were really interested in Minecraft, and they're like, oh, regular Minecraft is interesting, but, man, I found this really cool mod for Minecraft that I really like. And then they start using mods and installing mods, and then they're like, oh, maybe I can make my own mod. And so they want to make their own mod, but they have to find a book or a person or somebody that can help them with something like that. Just for a kid to make a mod, they're just like, errr [laughs] \n\nI think it's just finding the right hook. It's interesting to me–a lot of kids come through video games where they're like, \"Oh yeah, when I was a kid, my uncle gave me a bunch of games, and I was playing a bunch of games.\" And my uncle was also a developer, and so I asked him, like, \"Can you make games?\" And he's like, \"Yeah, sure. You can make games.\" And he helped me make a simple game, and that's how I got hooked.\n\nEDDY: Tad, was there an attempt to get your older daughter into coding?\n\nTAD: A little bit. She had a lot of exposure to it just because her dad is a professional software developer. They did a few things in school, but for her, nothing really clicked. And so I'm like, you know what? Do your own thing. Follow your own interests. But for a lot of kids, it would click if you just find the right thing. \n\nI think there's a common misconception that people have and kids have. It's like, oh, I couldn't program because I'm not really good at math. Well, it's true that math is really important for certain parts of software development. Like, if you're coding a really complex physics simulation, or you're doing protein folding, [laughs] or one of these things, you absolutely have to have a dual major in computer science and math or something like that. \n\nBut if you want to make just a website...I was talking to this girl, and she got into programming because she really got into The Sims. And she really enjoyed making custom objects and custom outfits and things for different people. And she's like; I would love to share this with the world. I would love for people to download all my objects and all my Sims clothing. And she got into WordPress because she needed to make a website to do this. \n\nAnd from there, she got into PHP so that she could learn how to work her WordPress stuff a little bit more. And from there, she just became a regular general web developer [laughs] because she really enjoyed making objects for The Sims. That would be my advice is just figure out what the kid is interested in because there's probably something that is related that you can use to hook them. Because things like Scratch aren't maybe interesting for every kid. But being able to make a website and have your friend visit it and it does some animation might be what you're interested in, right?\n\nMIKE: Absolutely. Or music. There's that Sonic Pi that I keep mentioning, or like you said, the Minecraft mod. [laughs] There's a wide range of things that are out there if somebody has some inclination that you can get them hooked with.\n\nTAD: Well, one of the other things is some people come to it on their own. I think a lot of people need somebody they can model after or someone that will nudge them. Because I've talked to a few girls who are like, \"I always thought computer science, programming, whatever, wasn't for me until I got talked into it by this other woman. And she's like, 'No, women can code too.'\" [laughs] And they're like, \"Oh yeah, well, cool. You're showing me that you can do it, so I could probably do that.\"\n\nOr I've talked to a bunch of people who are just like, \"Oh yeah, my uncle was a programmer, so I saw that he had a lot of fun with his job. So I thought maybe I can be a programmer too.\" I think role models are sometimes an important part too.\n\nEDDY: Your kid, when you proposed the idea to start learning to code, how was the mom's perspective on that? Like, was she hesitant at first? Was she reluctant? Was she fully on board or committed? Because proposing coding to a kid can be daunting from like -- \n\nMIKE: It's an interesting question. So were my wife and I unified on this or was I proposing, and mom was like, \"Ah, I don't know?\" Is that the question? \n\nEDDY: Yeah, exactly. Was she like, \"Do you think this is the right idea?\" [laughs]\n\nMIKE: My wife has always been very encouraging of my career. My dad and his brothers worked in construction. My mom was a nurse. But I wasn't interested in nursing. But her dad was a handyman, so most of my role models were in the construction industry. And that affects the way you see your career path. [laughs] I did some school. I kind of ran out of money and went to make some more money and ended up doing construction-type work. I did a few different jobs in that field to make money.\n\nAnd it took me a while to go back to school because it was hard to save enough. [laughs] But also, I didn't necessarily see myself as a coder. And my wife was always very supportive in that aspect, saying, \"This is what you need to do.\" So when my son showed some interest, I think my wife was very much on board because she saw that it gave him so much potential. There's so much potential in pursuing that. \n\nShe was actually the one who went out and found the class for Minecraft modding and said, \"Hey, let's go get this. This looks like a good option.\" And then, of course, being a professional here, [laughs] I was able to help him out with it. But I think she if anything, was more supportive than I was because she saw the opportunities that were available there and tried to encourage us to do that. And I think that that was really helpful and important. \n\nShe also encouraged also with my other kids. My second oldest...there's a big gap between my oldest and the next. My second oldest just turned 10. My daughter is seven going on eight, and she has shown some interest. So I've shown her some coding. She's done some stuff on Khan Academy. She played around with it a little bit. It was a little bit beyond her reach. And so we're giving it a little bit of space, but she's had a taste. Not everybody is interested. So my second oldest, I don't think he is really ever going to be that interested, but my daughter, I think, is. So I'm going to try to give her all the opportunities that I can.\n\nEDDY: What I told my mom, like, even if they ultimately decide not to proceed with coding, I think it's a valuable asset to have in your arsenal.\n\nMIKE: Absolutely. Well, let me ask this in a different way: how often do you write essays in your career? Or how often do you solve algebra problems or use your calculus if you took calculus? I'm guessing the answer to all of those is never. They teach it in school anyway because learning to write an essay and learning to do algebra teach you a way of thinking, of decomposing a problem into smaller parts and taking the time to craft a quality solution and to understand how to break up that problem into small parts. \n\nAnd sometimes we forget that we learned that lesson, and we say, \"Oh yeah, I'm just going to do it all at once,\" and we get frustrated and lost. But those skills are very much useful, maybe not in and of themselves but in teaching broader skills. And I think coding is very much that way as well. It teaches you problem-solving skills.\n\nTAD: Even beyond that, it teaches you problem-solving vocabulary because I love to talk to other developers because I already have a shorthand for explaining the problem. Like, I could say it's X type of problem, or it's Y type of problem, or this is a certain type of approach to this problem. I've got all these words, and there's a very rich vocabulary that comes with understanding all these different problems and how to solve these problems that I wish more people had. \n\nSo I could say, \"Oh yeah, this is a problem of this type.\" And they'd be like, \"Oh, okay, now I see what you're talking about. If it's that type of problem, then maybe here are some of the solutions for that problem.\" I'm like, \"Yes.\" [laughs] Like, it would be so nice if I could use my rich problem-solving vocabulary in everyday life, and people would just kind of pick it up and understand it. And I wouldn't have to stop and say, \"Okay, here's a story. Here's an analogy. Here's a thing that explains why I'm about to tell you this.\"\n\nEDDY: I do have a question for Ramses. Do you have any kids? \n\nRAMSES: No. No kids. \n\nEDDY: Okay. So I'm currently married, and my wife and I are in talks of maybe making our family bigger. My question for you is like, I'm sure you've thought...or if you do have kids, are you going to also approach them with the idea of coding? \n\nRAMSES: Yeah, I probably would. I don't know if I'll have kids. [laughs] I think if I did, I'd want them to be curious and explore what they're interested in.\n\nEDDY: Awesome, yeah. Because my wife and I have talked about that too, and I'm like, \"Yeah, I think I'm going to expose our kid to coding, to the idea.\" She's like, \"Are you sure?\" Because she's super reluctant and she can't stare at a computer for longer than 10 minutes. And she's like, \"Are you sure?\" I'm like, \"Yeah, totally.\" [laughs] I'm like, \"I'm not going to shove it down his throat or anything, but have that as an option.\"\n\nMIKE: Well, I think, like you say, it's an option. Giving people opportunities is different from cramming it down their throat, taking that cramming-down-the-throat idea, giving somebody this smorgasbord. [laughs] They've got, look at all of this feast that you can draw from. It is very different from holding somebody's mouth open and trying to shove something down there. If you try to shove something down somebody's throat, they're not going to want to eat. But if you present that feast in front of them, they're probably not going to think twice, [laughs] like, yeah, I'll have some of that. And providing that presentation and opportunity so they can say, \"Hey, this looks appealing,\" is the key. \n\nAnd Tad has been talking a lot about the hook, getting people involved in something they're interested in. Children very much...and I think this is maybe universal to people that children hone this skill. They can tell when somebody's trying to make them do something. And they know like, oh yeah, you think this is going to be good for me, so you're going to make me do it. \n\nThey realize that they have independent ideas, and they want to exercise their agency to do what they want. And so they're not going to respond to making them do something. But if you say, \"Hey, do you want me to help you build a Minecraft mod?\" Well, that's an entirely different scenario. That's like, oh, wow, really? I can make my own? You're giving them that feast.\n\nEDDY: Or how about just saying, \"Hey, you're not allowed to create mods.\" \n\n[laughter]\n\nTAD: A little reverse psychology. [laughs] Yeah, I briefly taught some kids really basic HTML. And I'd teach them a little bit, and then I'd see their eyes kind of glaze over. I was like, \"Okay, well, here's how you can add an image to your page that you're working on. Here's how you can make the background color red,\" and then just let them go. \n\nAnd suddenly, they're like, \"Oh, man, I really want to add this funny picture from the internet to my personal webpage that I'm doing.\" I'm like, \"Okay, cool. We'll download it, and let's see if we can add it to your page.\" \"Oh, I really like the color pink. I want to make my background pink for my webpage.\" \"Oh yeah? How do you think...\" So you give them a little teaser, and then they're like, wait a second, I want to do this for myself. \n\nAnd suddenly, they're learning the hex code for pink [laughter] where before you're like, here's hex codes and dah, dah, dah, and they're like, er. But you give them a little taste and a little freedom, and suddenly they're eager, and they're teaching themselves. And you're like, oh yeah, here's a little online color wheel or whatever, and see how you can pick a color and see that there's a code next to it. You could choose that color and copy that code, and then you can make something on your web page that color.\n\nEDDY: You see, Tad, I initially started with that curiosity too. I was like, oh yeah, I want to add a link to another site. But there's a huge gap between learning how to do an inline href tag to doing some CSS styling [laughs] to adding some logic, one jump into another. And there are super huge gaps in between. And that's what initially turned me off the first time, which was like, well, it's like, what are variables? This is too hard. [chuckles]\n\nTAD: Yeah, I think that's why you need someone to come in and help kids over those gaps. I was talking to a guy, and he's like, \"I really wanted to make a game when I was a kid. And so I just opened up Notepad, and I started typing text into a thing, and I just saved it as .bat,\" or something. I forget how Windows works. But I think that's a batch file or something. And then he tried to run it. And he had just typed in, like, open a window, do a thing. [laughs] He just did it in English because he knew that you could tell computers things. And he knew that these certain types of files could make a computer do things. But he had no concept of programming. \n\nAnd as a little kid, he tried it, and then nothing worked, and he just got discouraged. And it wasn't until years later that he's like, \"Oh, [laughs] let's figure this out.\" But how cool would it have been if someone came along and was like, \"Oh, I see what you're trying to do. Let's start with something real simple and work up from there.\" Somewhere there's a point where they show the interest, and they take the initiative to act on the interest. And you need to be there to catch them when they can't figure something out, or they get discouraged and be like, \"Okay, let's fix it. And let's take you up barely to the next level.\"\n\nMIKE: You hit on a couple of things that I've been thinking about through this whole thing. You need to have somebody there. Presumably, most people who are listening here and all of us here have done some coding professionally, or maybe you've just dabbled in it a little bit, but you have some knowledge. I'm thinking about what Ramses said. Well, he doesn't have any kids. He might not ever have kids. That's true of a lot of people. [laughs] \n\nBut that doesn't mean you're not around people, around children, or maybe an adult who is wanting to grow their skills that needs that person to provide some scaffolding for them to help them get over that gap. And we can do that. We can be there and provide that bridge so they can get over those big hurdles and get to where it's fun again. And I think that we should be looking for those opportunities because, well, it's important, but it's also rewarding. It's rewarding for the person who's helping. \n\nOne other thing I thought about that you reminded me of earlier, Tad, is there's a nationwide organization, I think is what it is, called Girls Who Code. They provide get-togethers and resources and mentors for girls in particular, who are often underrepresented in this field, to see those heroes, those role models that they can see themselves in. And if there's a girl in your life who has some interest, there are some really good resources out there to help them see themselves in that role.\n\nTAD: Yeah. I've got two daughters. And that, I think, really opened my eyes to a blind spot that I had, meaning the first time I was going to play some games with my daughter, she's like, \"Why can't I play as a girl?\" I'm like, \"Oh, wait, what?\" [laughs] She's like, \"I want to play as a girl,\" and I think we were playing Minecraft. And I'm like, \"Oh, I guess Steve is the only option right now.\" \n\nThey added skins, and we helped her design a female skin for her Minecraft character. And she was just thrilled her character could have long hair and run around and whatever. Yeah, I think some real holes where girls don't want to play the game...I go back to this because a lot of guys that I know who became developers started out doing games stuff. But the girls didn't want to kill a bunch of things and save the princess, like, eh, [laughs] that has no appeal to me at all. \n\nThere's this game that my daughter loved called Aquaria, where you're this mermaid creature, and you sing different songs to create different magical effects. And you swim around in this underwater world, and I'm like, oh yeah. And this kind of goes back to the right hook. My daughter got interested in games. She got interested in computers because I found some games that appealed to her interests. And sadly, I think that's still tricky to find for girls.\n\nMIKE: I think it is, but there are things out there. We got to kind of make that extra effort, right?\n\nTAD: Yeah.\n\nMIKE: Making some extra effort to make sure she gets those opportunities to see herself.\n\nEDDY: I've always just been curious on the psychology behind child prodigies who have this nature, like, this knack of being able to pick up coding. And I saw a video on YouTube about this eight-year-old [chuckles] who was developing iOS apps and brought their family out of poverty. So I've always just been curious on the psychology behind what makes that kid different. That may be a topic for another time.\n\nMIKE: Yeah, that is a topic for another time. But I will point out that if you've got a prodigy, you've got somebody behind them who's been helping them get there.\n\nTAD: Yeah, even a prodigy needs access to computers and access to learning materials and probably someone who's there to guide them.\n\nMIKE: Absolutely. I think that everything we've talked about today is equally applicable for a kid who's got some strong natural inclination. Everything I've read about prodigies suggests that it's mostly they were just interested in it, so they practiced a lot. You don't learn things just without work. So if you find somebody who's deeply interested in something and you just give them as many resources as you can to pursue that, they can run with it. \n\nEverything we've talked about today, providing that hook, giving people the opportunities, giving them support when they get stuck, is applicable whether somebody is mildly interested and might not really run with it very far or is full on prodigy and is going to be building the next disruptive thing before they hit 20. The same rules apply, I believe. It's an interesting thought. \n\nIt's been an interesting session. We've talked about several tools that you can use. I'd invite anybody listening to go and find some child or adult in their life who could use some help and help them out. Give them a chance to grow and find the magic that's available in programming. See you next time.","content_html":"We talk about a fun topic–teaching kids to code!
\n\nTranscript:
\n\nMIKE: Welcome to another episode of the Acima Development Podcast. I'm Mike. I'll be your host again this week. And we've got with us Eddy, Ramses, and Tad. Today is a fun topic. We're going to be talking about teaching kids to code. I thought that I might start the session [laughs] with a personal story, a couple of them actually that I think are relevant and will help inform our discussion.
\n\nI remember my first experience coding as a kid. This is way back in the ye olden days of yore [laughs] when computing was different. When I was in about third grade, we got to use the school computer because the school had a computer, and classes would take turns playing with it. We had Logo, which is software that allows you to move a little turtle around the screen. You code it to walk around the screen. That was cool. It was real-time feedback.
\n\nYou tell it to move; it moves. And you tell it to move again; it moves. But we learned that there was a way you could go into a back screen where you could type in loops. And I remember playing with that and thinking it was the coolest thing ever. [chuckles] I wanted to do that all the time. But I had to use my 10 minutes of computer time on the shared school computer, and that was it. [laughs]
\n\nAnd I didn't really get to use a computer again for some time, except that I did have a couple of friends who had coded in BASIC and taught me some things, which I also thought was cool. I remember that in sixth grade, the teacher tried to show us how to code. They had the BASIC environment there. And I thought, oh, I remember how to do this. And I wrote line 10, and I had it print out my name, and line 20 GOTO 10. And I ran it because I remembered how to do that. And it just started printing my name endlessly.
\n\nAnd the teacher, who was really unfamiliar and was just following a set of instructions and had no idea how to undo that couldn't stop it, had to restart the computer. And by the time the computer got restarted, our computer time was done, and we had to go back to class. [laughs] So I ruined the coding session for everybody. It wasn't a high point, [laughs] and the teacher was not at all happy with me.
\n\nI can tell some other stories of learning to code later. But there's some commonality there. [laughs] Coding was fun when I had a chance to have fun. And it didn't work out very well, and there weren't resources for me to play. But also, there wasn't somebody around who could give me some guidance. The teacher wasn't able to find any help. It meant I did something fun and then got lost and frustrated, and that was kind of the end of it for everybody. And unfortunately, I ruined the day for not just myself but a bunch of other kids.
\n\nThe kids love to explore. Kids explore by nature and want to go out exploring, and given the chance to do that in the right environment, will tend to latch on to it if they get the support that they need. With that context, let's go on and talk about some ideas for helping kids to code. We were talking a little bit before we started today about some experiences other people have had teaching kids to code. I've myself had a decent amount of experience.
\n\nI've taught several kids to some degree how to code, including my own and those of friends and relatives. So I've got some background doing this, have some ideas but certainly don't have all the ideas. There's so much out there, and there's so much science of teaching that I'm sure there are all kinds of things that I'm missing. And I'd love to hear what other people have to say. First of all, any thoughts based on my story or thoughts to begin our podcast?
\n\nTAD: Yeah, as I was thinking about this, there are maybe three things that really interest me when people talk about this kind of stuff because I'm curious how they got started. And those three things are, how did you first get access? What was your hook? What was the thing that got you interested and got you started? And the third thing is, who was your mentor, or who was the person who came along and gave you the nudge that got you in?
\n\nBecause as I was listening to your stories, I'm like, these are some common elements that I've noticed in a lot of people's experiences. And so I'd be curious to hear from Eddy and Ramses because Mike, you, and I are both in our 40s. And so that first one, how did you first get access to a computer? Is [laughs] because they weren't ubiquitous when I was a kid, right?
\n\nMIKE: No, they weren't.
\n\nTAD: I remember when every teacher in my elementary school...I think I was in fourth grade. Every teacher got their own computer for their own classroom, and that was big. And you'd hear about computers, but they weren't really common and really accessible. So I'd like to hear other people's experiences; just how did you get access? What was the hook that got you interested? And who was the person who gave you the nudge? Maybe you don't have those three, but I've found those to be very common elements when talking to people about how they first learned or what got them into it.
\n\nEDDY: Actually, it's kind of funny; you kind of struck a chord with me there because I'm like, dang, when did I get interested in that? To give some context, I'm hitting 30. And back in elementary school, there wasn't high-speed internet, so the only way we had access to the internet was connecting to the phone cord. And you had to switch back and forth between taking a phone call [laughs] and connecting to the internet. So it was like dial-up.
\n\nAnd the problem was that cell phones weren't very prominent at the time. My mom would always go and scream at us, and she's like, "Hey, disconnect from the internet. I need to make a phone call." When she wasn't on a call, we had no access to the internet. And so we dabbled around, my older brother and I, on how to change elements in HTML. And seeing little buttons and text being changed and rendered was my first exposure because that's the one thing I could do without internet access.
\n\nMIKE: So the computer [laughs] was dial-up internet. The hook was being able to make changes in HTML so you could make a webpage. And is it your older brother who got you interested?
\n\nEDDY: Yeah. Initially, it was him. And he kind of just flew with it for a while. I kind of just sat back and watched him modify some tags. But it was something that we could do while not having access to the internet. [laughs]
\n\nMIKE: What about you, Ramses?
\n\nRAMSES: I'm in my late 20s as well. I've always just been around computers. I think I was first exposed to computers when I was like five, probably. We got a home computer for Christmas one year. But yeah, it was a lot of fun. I don't really remember being super interested in coding when I was really young. But I think I was just always intrigued by technology and building things. Mid-20s, I got more interested in learning coding and taking it a lot more seriously. So I really enjoy it because you get that feedback like you mentioned. And it's great being able to build things and to build something and know that you're helping someone.
\n\nMIKE: I'm with you on that feedback, that moment you realize you don't just have to be a consumer of what the computer gives you. You can make that a two-way conversation and ask this tool to do things for you and have it do that, and it's just magical.
\n\nEDDY: Was there anybody who kind of nudged you into it, or are you kind of self-taught, self-discovered?
\n\nRAMSES: Kind of a combo, like, self-motivated. I don't want to take all the credit myself. [laughs] I mean, I'm self-motivated, but I think I learn a lot from other people. There have been a lot of mentors that I've had. Mike was a prominent one early on and still is, you know, Afton, Tad, a lot of other people.
\n\nTAD: My curiosity is, were you thinking about taking this track when you first started working for Acima, or was it you found a niche in QA, and then from QA, people kind of nudged you over into development?
\n\nRAMSES: Yeah, it was exactly that. When I was in application support, I found kind of an opening that expanded my interest in learning software development. And I don't know if there was any single person that kind of pushed me. There were probably multiple. One of our old product managers, Jeff Madsen, was a pretty big proponent of that. Mike Challis was a proponent of that as well. I think he nudged me a little bit.
\n\nMIKE: Something interesting to me about that is we all have different paths here, those who picked it up more as adults, and I'm going to talk about you, particularly Ramses. A lot of people potentially listening to this who may be coming from a background where like, well, yeah, I don't have a traditional computer science background. I've never really done coding, but I've started doing a little bit of work.
\n\nBut there is this...not really the back door or the front door, like, the side door [laughs] where you're at someplace that's...it could be a business. It could be something that's not even specifically a business but any organization where you have an opportunity, maybe unexpectedly, you just start doing this work. A lot of times, people think, well, this is just kind of this side thing that maybe I'll pick up a little bit. But that can be a real gateway into a career.
\n\nAnd I've known a lot of people now who've gotten into the career not by saying, "Oh, I'm going to go to school. I'm going to get a four-year degree, and then I'm going to go do an internship, get a job," like have this really clear linear path. A lot of people don't come in that way. They are in application support, and they get an opportunity to expand their roles, start doing some coding, and eventually, they become a full-time developer. And this applies in actually kind of diverse fields.
\n\nThere are biologists who have found that to understand their data better, they needed to learn how to do some coding and machine learning. And so they became coders and started building up the tools to do better analysis of their data. Now they're developers and biologists. And the same thing applies to doctors or...those are just some that come to the top of my head that I read about. And these are kind of high-prestige professions. But there are some things that are less prominent that are also important.
\n\nBut there are many professions that don't necessarily have a lot of visibility but have need for some sort of software. And if you can get in that a little bit, it's surprising just how much that need is there. And you can step into it, again, through that side door and find yourself with a fairly different career because you latched on to that and just kept on working on it.
\n\nTAD: Right. Yeah, I've met a lot of developers who came to it from one of these side doors, like you're talking about. Because it's really interesting to me, software is everywhere and really touches everything in our lives now: it's in your phone, it's in your car, it's in your...whatever appliance you're using to make your breakfast. [laughs] It's in your fridge, like, it's really surprising all the places that you find software now.
\n\nAnd it's interesting because I worked with a guy who was a physics major, but he's like, "Oh yeah, I had to model some things. And so I had to code some things, and I found out, oh, I really enjoy this more than I enjoy physics." I worked with a guy who was into accounting and uses Excel all the time. "Oh, I've got to write macros for Excel. Oh, I'm going to learn some more Visual Basic so that I can write better macros for Excel. Oh, I actually prefer writing macros over my regular accounting job." Suddenly, they became a developer.
\n\nOr I had a friend who was a journalism major in college, and he really liked to investigate and figure things out, and that led him to documentation and stuff, which led him into software development. So it really is everywhere. And it really is possible to transition from pretty much anything over into software development because it's so ubiquitous, I think.
\n\nMIKE: I agree wholeheartedly.
\n\nEDDY: I kind of want to touch a little bit, like, you mentioned before on this call that you were successful in teaching your kids how to code, and one of them is actually going to school for that. How did you engage or propose the idea to your kid? Because I'm sure you proposing that idea had some sort of influence.
\n\nMIKE: Yeah, that's a great question. It's a perfect segue into talking about what you can do specifically for kids. We've talked some about adults here more than kids and then a little bit with kids. There's the same idea of that hook and how people get started. My oldest, my son, he is now 18. He's going to...he's in college, University of Illinois.
\n\nWhen he was fairly young, I think the first coding that I exposed him to is that he would sometimes be working on math and want to have a better calculator than what he had. So he's working on his math homework, and he wanted to add some numbers together or do something like exponents, where it's a little more sophisticated, and you want to do a bunch of steps.
\n\nOne thing about the way simple calculators work (I guess there are more sophisticated ones now and maybe even on your computer.) they usually perform the operations as you type them. So rather than being able to write out the entire program, you know, I say program but kind of the problem that you're working on and then execute it; instead, you do one step at a time. And it's very easy to lose context, and you kind of lose track of where you are. And you don't have a history of work that you can go back and check, which is frustrating. [laughs]
\n\nSo I started showing him, "Hey, you can come up to this console and do some live coding and interact with the computer that way." I made sure to teach him several languages at once so he can see there's more than one way to do it. And they are pretty similar. I remember showing him Haskell, which is [laughs] a more obscure language but very mathy. And I said, "Hey, look, you can open this interactive console and just type in some Haskell, and you can get the results back." He's like, "Oh, cool." And I think I showed him Python and Ruby. All of them have the read–eval–print loop where you do interactive coding, or REPL, people will call it.
\n\nAnd I started showing him that, and he's like, "Hey, this is really useful." So he'd be using this. He'd pull this up on a laptop for his math class. So he could write out the problem, check that he had written down the problem correctly before he executed it. So unlike a calculator where you don't get to check your work, you can go back and say, oh, which steps did I do wrong here? And that was really helpful to him.
\n\nAnd once I had that hooked, well, now he knew that it was useful. Now he knew that there was a tool that he could use to make his life easier. And really, it wasn't super hardcore coding. It was just typing some simple arithmetic expressions. But that gave him the hook he needed to be able to start doing more. Beyond that, I started introducing him, when I had the opportunity, to some additional kind of sandboxes to play in.
\n\nAnd there are several tools I'd like to call out here. There's a popular one that we never really did use called Scratch, which is not too far from the Logo I used when I was a kid, where you can give instructions to tell an animated character or some sort of avatar or icon to move around the screen. And Scratch is popular. It's widely used in education. Probably a good option if you can find somebody who's interested in it. It just never really spoke to kids I've worked with. But there have been some other things.
\n\nOne thing that most kids seem to love is Minecraft. And Minecraft has a huge modding community. Huge. [laughs] I know that there's a similar game, Roblox. There are a lot of sub-games in Roblox that people have created by coding them up. Roblox is kind of designed around having this, hey, you build your own mini-games community, and a lot of people have done that as well. So I think that's also another great option. If you've got a kid who's into Roblox, well, great, they can build their own games. I would strongly recommend something like that.
\n\nSo my son really was into the idea of Minecraft. I showed him how to mod a little bit, and it was kind of daunting. There was a company who provided several classes on how to do the modding. He went through their program and really enjoyed it. And he built his skills by learning how to mod Minecraft. And once he had that, then he was able to...I showed him some Python, so he was able to start doing some Python.
\n\nAgain, I signed him up for some other classes that he had some interest in, and he just grew and grew. He writes scripts now to solve problems that he has. Like, he wrote a little Python program to give himself flashcards so he can study for a Spanish class which goes back to right where we first started. It was useful for him. He was able to use the computer to do something cool. He was going to come back to it because it helped him out. All of those tools have been really useful.
\n\nThere's another one that I've used I'd maybe like to revisit in a little bit. When I've talked to a group of people, that tool...and there are probably others like it. This one that I've used is called Sonic Pi. I believe it's open source. Honestly, I haven't really looked into it. But it's a tool that was designed to run on a Raspberry Pi to be really accessible for educators because you can run it on minimal hardware. And it allows you to do fun stuff with audio. You can code audio and so be your own DJ with writing code and write your own music, which is fun.
\n\nEDDY: That's interesting. You just found a way to engage them. And I think that's really important. In order for a kid to learn something, you make a game out of it and create activities around it to stimulate the brain. And that's really interesting, truly. And not only that, but sharing enthusiasm for their progress, I think it's important. That attributed to some of my little sister's advancements, too, the little she had. It was like, "Oh, you got your character to move like one pixel to the right? Oh, that's awesome." [laughter]
\n\nMIKE: Which sounds trivial, but it really is kind of awesome, isn't it? It really is this sort of magic that you can take this amazing device and have it animate things for you, automate tasks that historically was the domain of things that humans could do. And it may seem trivial to move it one pixel to the right, but can you imagine having to draw that by hand, trying to hand-animate anything [laughs] for that matter? The massive amount of tooling and experience that would be required to accomplish something like that would be prohibitive in almost all cases. Having a tool that can do that is amazing. And there really is a magic to having that character move a pixel to the right.
\n\nEDDY: You're like the puppeteer.
\n\nMIKE: Tad, I think you'd mentioned earlier that you've had some experience getting kids hooked on coding or giving them some experience. Do you have any tools or advice that you'd recommend?
\n\nTAD: It's hard because there are so many things out there. You almost need to find...well, I keep talking about the hook. What are their interests? There's probably some hook you can find that will get them interested. To be fair, coding isn't for everybody. There are people that... [laughs] my oldest daughter just started college, and she's going into natural resources and wildlife management. And she very directly told me that she wants to be outdoors, and she doesn't want to sit in front of a computer, and she wants to do certain things. And I'm like, okay, yeah, you're probably never going to be a programmer. You'll definitely be using computers for things, but coding is not your thing, and that's fine.
\n\nBut I used to help kids just tweak mods for Minecraft. They were really interested in Minecraft, and they're like, oh, regular Minecraft is interesting, but, man, I found this really cool mod for Minecraft that I really like. And then they start using mods and installing mods, and then they're like, oh, maybe I can make my own mod. And so they want to make their own mod, but they have to find a book or a person or somebody that can help them with something like that. Just for a kid to make a mod, they're just like, errr [laughs]
\n\nI think it's just finding the right hook. It's interesting to me–a lot of kids come through video games where they're like, "Oh yeah, when I was a kid, my uncle gave me a bunch of games, and I was playing a bunch of games." And my uncle was also a developer, and so I asked him, like, "Can you make games?" And he's like, "Yeah, sure. You can make games." And he helped me make a simple game, and that's how I got hooked.
\n\nEDDY: Tad, was there an attempt to get your older daughter into coding?
\n\nTAD: A little bit. She had a lot of exposure to it just because her dad is a professional software developer. They did a few things in school, but for her, nothing really clicked. And so I'm like, you know what? Do your own thing. Follow your own interests. But for a lot of kids, it would click if you just find the right thing.
\n\nI think there's a common misconception that people have and kids have. It's like, oh, I couldn't program because I'm not really good at math. Well, it's true that math is really important for certain parts of software development. Like, if you're coding a really complex physics simulation, or you're doing protein folding, [laughs] or one of these things, you absolutely have to have a dual major in computer science and math or something like that.
\n\nBut if you want to make just a website...I was talking to this girl, and she got into programming because she really got into The Sims. And she really enjoyed making custom objects and custom outfits and things for different people. And she's like; I would love to share this with the world. I would love for people to download all my objects and all my Sims clothing. And she got into WordPress because she needed to make a website to do this.
\n\nAnd from there, she got into PHP so that she could learn how to work her WordPress stuff a little bit more. And from there, she just became a regular general web developer [laughs] because she really enjoyed making objects for The Sims. That would be my advice is just figure out what the kid is interested in because there's probably something that is related that you can use to hook them. Because things like Scratch aren't maybe interesting for every kid. But being able to make a website and have your friend visit it and it does some animation might be what you're interested in, right?
\n\nMIKE: Absolutely. Or music. There's that Sonic Pi that I keep mentioning, or like you said, the Minecraft mod. [laughs] There's a wide range of things that are out there if somebody has some inclination that you can get them hooked with.
\n\nTAD: Well, one of the other things is some people come to it on their own. I think a lot of people need somebody they can model after or someone that will nudge them. Because I've talked to a few girls who are like, "I always thought computer science, programming, whatever, wasn't for me until I got talked into it by this other woman. And she's like, 'No, women can code too.'" [laughs] And they're like, "Oh yeah, well, cool. You're showing me that you can do it, so I could probably do that."
\n\nOr I've talked to a bunch of people who are just like, "Oh yeah, my uncle was a programmer, so I saw that he had a lot of fun with his job. So I thought maybe I can be a programmer too." I think role models are sometimes an important part too.
\n\nEDDY: Your kid, when you proposed the idea to start learning to code, how was the mom's perspective on that? Like, was she hesitant at first? Was she reluctant? Was she fully on board or committed? Because proposing coding to a kid can be daunting from like --
\n\nMIKE: It's an interesting question. So were my wife and I unified on this or was I proposing, and mom was like, "Ah, I don't know?" Is that the question?
\n\nEDDY: Yeah, exactly. Was she like, "Do you think this is the right idea?" [laughs]
\n\nMIKE: My wife has always been very encouraging of my career. My dad and his brothers worked in construction. My mom was a nurse. But I wasn't interested in nursing. But her dad was a handyman, so most of my role models were in the construction industry. And that affects the way you see your career path. [laughs] I did some school. I kind of ran out of money and went to make some more money and ended up doing construction-type work. I did a few different jobs in that field to make money.
\n\nAnd it took me a while to go back to school because it was hard to save enough. [laughs] But also, I didn't necessarily see myself as a coder. And my wife was always very supportive in that aspect, saying, "This is what you need to do." So when my son showed some interest, I think my wife was very much on board because she saw that it gave him so much potential. There's so much potential in pursuing that.
\n\nShe was actually the one who went out and found the class for Minecraft modding and said, "Hey, let's go get this. This looks like a good option." And then, of course, being a professional here, [laughs] I was able to help him out with it. But I think she if anything, was more supportive than I was because she saw the opportunities that were available there and tried to encourage us to do that. And I think that that was really helpful and important.
\n\nShe also encouraged also with my other kids. My second oldest...there's a big gap between my oldest and the next. My second oldest just turned 10. My daughter is seven going on eight, and she has shown some interest. So I've shown her some coding. She's done some stuff on Khan Academy. She played around with it a little bit. It was a little bit beyond her reach. And so we're giving it a little bit of space, but she's had a taste. Not everybody is interested. So my second oldest, I don't think he is really ever going to be that interested, but my daughter, I think, is. So I'm going to try to give her all the opportunities that I can.
\n\nEDDY: What I told my mom, like, even if they ultimately decide not to proceed with coding, I think it's a valuable asset to have in your arsenal.
\n\nMIKE: Absolutely. Well, let me ask this in a different way: how often do you write essays in your career? Or how often do you solve algebra problems or use your calculus if you took calculus? I'm guessing the answer to all of those is never. They teach it in school anyway because learning to write an essay and learning to do algebra teach you a way of thinking, of decomposing a problem into smaller parts and taking the time to craft a quality solution and to understand how to break up that problem into small parts.
\n\nAnd sometimes we forget that we learned that lesson, and we say, "Oh yeah, I'm just going to do it all at once," and we get frustrated and lost. But those skills are very much useful, maybe not in and of themselves but in teaching broader skills. And I think coding is very much that way as well. It teaches you problem-solving skills.
\n\nTAD: Even beyond that, it teaches you problem-solving vocabulary because I love to talk to other developers because I already have a shorthand for explaining the problem. Like, I could say it's X type of problem, or it's Y type of problem, or this is a certain type of approach to this problem. I've got all these words, and there's a very rich vocabulary that comes with understanding all these different problems and how to solve these problems that I wish more people had.
\n\nSo I could say, "Oh yeah, this is a problem of this type." And they'd be like, "Oh, okay, now I see what you're talking about. If it's that type of problem, then maybe here are some of the solutions for that problem." I'm like, "Yes." [laughs] Like, it would be so nice if I could use my rich problem-solving vocabulary in everyday life, and people would just kind of pick it up and understand it. And I wouldn't have to stop and say, "Okay, here's a story. Here's an analogy. Here's a thing that explains why I'm about to tell you this."
\n\nEDDY: I do have a question for Ramses. Do you have any kids?
\n\nRAMSES: No. No kids.
\n\nEDDY: Okay. So I'm currently married, and my wife and I are in talks of maybe making our family bigger. My question for you is like, I'm sure you've thought...or if you do have kids, are you going to also approach them with the idea of coding?
\n\nRAMSES: Yeah, I probably would. I don't know if I'll have kids. [laughs] I think if I did, I'd want them to be curious and explore what they're interested in.
\n\nEDDY: Awesome, yeah. Because my wife and I have talked about that too, and I'm like, "Yeah, I think I'm going to expose our kid to coding, to the idea." She's like, "Are you sure?" Because she's super reluctant and she can't stare at a computer for longer than 10 minutes. And she's like, "Are you sure?" I'm like, "Yeah, totally." [laughs] I'm like, "I'm not going to shove it down his throat or anything, but have that as an option."
\n\nMIKE: Well, I think, like you say, it's an option. Giving people opportunities is different from cramming it down their throat, taking that cramming-down-the-throat idea, giving somebody this smorgasbord. [laughs] They've got, look at all of this feast that you can draw from. It is very different from holding somebody's mouth open and trying to shove something down there. If you try to shove something down somebody's throat, they're not going to want to eat. But if you present that feast in front of them, they're probably not going to think twice, [laughs] like, yeah, I'll have some of that. And providing that presentation and opportunity so they can say, "Hey, this looks appealing," is the key.
\n\nAnd Tad has been talking a lot about the hook, getting people involved in something they're interested in. Children very much...and I think this is maybe universal to people that children hone this skill. They can tell when somebody's trying to make them do something. And they know like, oh yeah, you think this is going to be good for me, so you're going to make me do it.
\n\nThey realize that they have independent ideas, and they want to exercise their agency to do what they want. And so they're not going to respond to making them do something. But if you say, "Hey, do you want me to help you build a Minecraft mod?" Well, that's an entirely different scenario. That's like, oh, wow, really? I can make my own? You're giving them that feast.
\n\nEDDY: Or how about just saying, "Hey, you're not allowed to create mods."
\n\n[laughter]
\n\nTAD: A little reverse psychology. [laughs] Yeah, I briefly taught some kids really basic HTML. And I'd teach them a little bit, and then I'd see their eyes kind of glaze over. I was like, "Okay, well, here's how you can add an image to your page that you're working on. Here's how you can make the background color red," and then just let them go.
\n\nAnd suddenly, they're like, "Oh, man, I really want to add this funny picture from the internet to my personal webpage that I'm doing." I'm like, "Okay, cool. We'll download it, and let's see if we can add it to your page." "Oh, I really like the color pink. I want to make my background pink for my webpage." "Oh yeah? How do you think..." So you give them a little teaser, and then they're like, wait a second, I want to do this for myself.
\n\nAnd suddenly, they're learning the hex code for pink [laughter] where before you're like, here's hex codes and dah, dah, dah, and they're like, er. But you give them a little taste and a little freedom, and suddenly they're eager, and they're teaching themselves. And you're like, oh yeah, here's a little online color wheel or whatever, and see how you can pick a color and see that there's a code next to it. You could choose that color and copy that code, and then you can make something on your web page that color.
\n\nEDDY: You see, Tad, I initially started with that curiosity too. I was like, oh yeah, I want to add a link to another site. But there's a huge gap between learning how to do an inline href tag to doing some CSS styling [laughs] to adding some logic, one jump into another. And there are super huge gaps in between. And that's what initially turned me off the first time, which was like, well, it's like, what are variables? This is too hard. [chuckles]
\n\nTAD: Yeah, I think that's why you need someone to come in and help kids over those gaps. I was talking to a guy, and he's like, "I really wanted to make a game when I was a kid. And so I just opened up Notepad, and I started typing text into a thing, and I just saved it as .bat," or something. I forget how Windows works. But I think that's a batch file or something. And then he tried to run it. And he had just typed in, like, open a window, do a thing. [laughs] He just did it in English because he knew that you could tell computers things. And he knew that these certain types of files could make a computer do things. But he had no concept of programming.
\n\nAnd as a little kid, he tried it, and then nothing worked, and he just got discouraged. And it wasn't until years later that he's like, "Oh, [laughs] let's figure this out." But how cool would it have been if someone came along and was like, "Oh, I see what you're trying to do. Let's start with something real simple and work up from there." Somewhere there's a point where they show the interest, and they take the initiative to act on the interest. And you need to be there to catch them when they can't figure something out, or they get discouraged and be like, "Okay, let's fix it. And let's take you up barely to the next level."
\n\nMIKE: You hit on a couple of things that I've been thinking about through this whole thing. You need to have somebody there. Presumably, most people who are listening here and all of us here have done some coding professionally, or maybe you've just dabbled in it a little bit, but you have some knowledge. I'm thinking about what Ramses said. Well, he doesn't have any kids. He might not ever have kids. That's true of a lot of people. [laughs]
\n\nBut that doesn't mean you're not around people, around children, or maybe an adult who is wanting to grow their skills that needs that person to provide some scaffolding for them to help them get over that gap. And we can do that. We can be there and provide that bridge so they can get over those big hurdles and get to where it's fun again. And I think that we should be looking for those opportunities because, well, it's important, but it's also rewarding. It's rewarding for the person who's helping.
\n\nOne other thing I thought about that you reminded me of earlier, Tad, is there's a nationwide organization, I think is what it is, called Girls Who Code. They provide get-togethers and resources and mentors for girls in particular, who are often underrepresented in this field, to see those heroes, those role models that they can see themselves in. And if there's a girl in your life who has some interest, there are some really good resources out there to help them see themselves in that role.
\n\nTAD: Yeah. I've got two daughters. And that, I think, really opened my eyes to a blind spot that I had, meaning the first time I was going to play some games with my daughter, she's like, "Why can't I play as a girl?" I'm like, "Oh, wait, what?" [laughs] She's like, "I want to play as a girl," and I think we were playing Minecraft. And I'm like, "Oh, I guess Steve is the only option right now."
\n\nThey added skins, and we helped her design a female skin for her Minecraft character. And she was just thrilled her character could have long hair and run around and whatever. Yeah, I think some real holes where girls don't want to play the game...I go back to this because a lot of guys that I know who became developers started out doing games stuff. But the girls didn't want to kill a bunch of things and save the princess, like, eh, [laughs] that has no appeal to me at all.
\n\nThere's this game that my daughter loved called Aquaria, where you're this mermaid creature, and you sing different songs to create different magical effects. And you swim around in this underwater world, and I'm like, oh yeah. And this kind of goes back to the right hook. My daughter got interested in games. She got interested in computers because I found some games that appealed to her interests. And sadly, I think that's still tricky to find for girls.
\n\nMIKE: I think it is, but there are things out there. We got to kind of make that extra effort, right?
\n\nTAD: Yeah.
\n\nMIKE: Making some extra effort to make sure she gets those opportunities to see herself.
\n\nEDDY: I've always just been curious on the psychology behind child prodigies who have this nature, like, this knack of being able to pick up coding. And I saw a video on YouTube about this eight-year-old [chuckles] who was developing iOS apps and brought their family out of poverty. So I've always just been curious on the psychology behind what makes that kid different. That may be a topic for another time.
\n\nMIKE: Yeah, that is a topic for another time. But I will point out that if you've got a prodigy, you've got somebody behind them who's been helping them get there.
\n\nTAD: Yeah, even a prodigy needs access to computers and access to learning materials and probably someone who's there to guide them.
\n\nMIKE: Absolutely. I think that everything we've talked about today is equally applicable for a kid who's got some strong natural inclination. Everything I've read about prodigies suggests that it's mostly they were just interested in it, so they practiced a lot. You don't learn things just without work. So if you find somebody who's deeply interested in something and you just give them as many resources as you can to pursue that, they can run with it.
\n\nEverything we've talked about today, providing that hook, giving people the opportunities, giving them support when they get stuck, is applicable whether somebody is mildly interested and might not really run with it very far or is full on prodigy and is going to be building the next disruptive thing before they hit 20. The same rules apply, I believe. It's an interesting thought.
\n\nIt's been an interesting session. We've talked about several tools that you can use. I'd invite anybody listening to go and find some child or adult in their life who could use some help and help them out. Give them a chance to grow and find the magic that's available in programming. See you next time.
","summary":"We talk about a fun topic–teaching kids to code!","date_published":"2023-03-29T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/fa0ed9b9-42ab-43d4-a677-656c6c5db128.mp3","mime_type":"audio/mpeg","size_in_bytes":46037008,"duration_in_seconds":2355}]},{"id":"c7e8b062-7586-4182-be80-1680c4a41f05","title":"Episode 13: Skills Clinics","url":"https://acima-development.fireside.fm/13","content_text":"We talk about something specific here at Acima with the hope that other companies will replicate our skills clinics because it's been an extremely valuable thing that we've done. \n\nTranscript:\n\nMIKE: Hello and welcome to another episode of The Acima Development Podcast. I'm Mike Challis. I'm hosting today. We've got a group here that I think has been here before, so I won't start with introductions. But I'll say names as people speak so that listeners can know who they're listening to. \n\nToday we have a topic that I'm excited about. I'm generally excited about the topics, but today is one that's kind of close to my heart, and it's what we call our Skills Clinic. Usually, we try to keep things general. Today we're going to be talking about something specifically that we do at Acima that I hope other companies will replicate this idea because I think it's been an extremely valuable thing that we've done. \n\nLet me give some history. About, I don't know, a year and a half ago, the beginning of the summer of 2021, we hosted an internship. And one thing that we've noticed...and this applies to the internship but it also applies to a lot of other situations in which new developers come into software development. Now, there are people who come through a very traditional path into software. They go to a four-year university. They get a degree in computer science or something similar. They do an internship somewhere, and they go, and they get a job. \n\nBut there are a lot of people who don't follow that path to get into software development. And there are a lot of programs out there to try to bridge that gap. One thing that exists is software bootcamps; a lot of people have used those, which tries to very quickly get you knowledgeable in software. This applies to people who've maybe got a degree somewhere else, or have work experience or, you know, years living adulting. [laughs] So they have a good sense of how to do things in life and maybe have experience in computing but haven't learned the tools of software. \n\nSo they'll go, and they'll do a really intense bootcamp for two or four months, something like that, and then move on to getting a job, you know, an expedited path. That's a great way to get into software if it works for you. Certainly, there are going to be some things left out compared to what you get with traditional computer science.\n\nA lot of people complain about computer science programs that they teach a lot of theory and not much practical experience. People can come out of a computer science degree and really have no idea [laughs] how to work in a real-world setting and have to learn those skills. So there are some advantages to both sides. But there are some gaps if you've gone to bootcamp so basic theory things you don't know that can sometimes hold you back. \n\nOne thing that we've done a lot is provide mentorship and internships so people internally who have not worked in software can kind of learn the ropes and move into coding and build their skills as they go. I think it's a great way to learn. A lot of people out there in the industry learn that way. And I strongly encourage it if that's something that interests you. But once again, there's often this feeling that like, oh, there are these things I didn't learn. There's not a bootcamp for people who are already working. It's something that gets you up and running but doesn't follow up after there.\n\nPeople who come from a traditional computer science background as well maybe they want to learn things outside of what they learned in school or outside of what they're doing at work and build their skills. All of these people have this need to have ongoing development, ongoing learning. Oftentimes, the work environment doesn't necessarily provide that. It gives you hands-on experience but not necessarily the theory, you know, things that would build those fundamental skills. A lot of background here; I'll give one more piece of background. \n\nWhen we were looking to do this internship, there was a product manager who worked with us who mentioned that his daughter was really an avid volleyball player. And during the summer, she really wanted to build her skills, and there were lots of programs around. I don't know about lots, but several programs around that will provide that opportunity, and what they call themselves is a skills clinic. \n\nA skills clinic is not for people who've never played volleyball before. And this exists in other sports as well. It's not for somebody who's never played before. It's for somebody who knows what they're doing but wants to do drills, wants to build their fundamentals so that when they go back and play the real game, they're better at it. We said, \"Well, that is the perfect name. That's the perfect name.\" \n\nWe need to have something like that. We need to have a skills clinic for software so that we have an opportunity to build our fundamentals to do that practice outside of our normal routine that builds the fundamental skills so that when we go back to our work, we are stronger, better, more confident, and can be better coders. So we started a program where an hour or so each day for the internship and for anybody interested...there have been a lot of junior developers, but there have also been more senior developers who've joined to get together and work on some fundamental skill, and we've called that skills clinic.\n\nWe did it during that internship and just kept it going. So for about a year and a half, we've been doing more or less daily, I'd say more, [laughs] almost always daily, a skills clinic where we get together and work on something. We started with some almost lecture-like formats where we did a presentation, talked about a computer science concept, and we've actually, by design, moved away from that. Asked for feedback and found that, yeah, that's great, but it's really hard to engage with a presentation like that. \n\nAnd over time, we've moved more and more toward hands-on experience. So we're writing code, but we're writing code outside of what we'd normally do at work in a way that would teach us something new. So we have learned some basic computer science concepts and learned about how computers work, [laughs] the basics of a processor. Then I think we learned a lot more by writing some machine code [laughs] to learn how that works, not very much because that's a pain. \n\nBut then we wrote some Assembly. We looked up the specs for, you know, x86 computer and figured out the Assembly language to do a basic addition operation and then moved on. We wrote some other low-level languages. And then, we thought of low-level code in a low-level language. And then we took some time writing our own languages. We split up into several groups, and we wrote our own programming languages. I thought that was a lot of fun. \n\nWe've gone beyond that point to work on a number of different projects. And it's a great opportunity for people to get in and build their skills. It's important to me because I helped launched it, but honestly, I have not been as involved with it for a while. My role has changed somewhat. But we do have Tad on the call with us, who has really pushed it forward, as well as Ramses, who's helped a lot with that.\n\nAnd they have kept this going, and they've been a great asset, I think, to the other developers and to the company. I'm curious to hear what Tad and Ramses...what do you think? I've kind of talked about how we launched it. I'm curious what you've been doing for the last several months as well as your thoughts about the value of skills clinic.\n\nTAD: Well, what we've been working on primarily is a chatbot for our company's Slack channel. The interesting thing is that we kind of just do whatever people need to be done. We have a default project that we work on every day. But there have been a few times we just barely finished our internship program for the summer, but I've just talked to the interns and been like, \"Hey, what do you need? Like, what holes do you have? What are you missing?\"\n\nAnd some of the days we just talk to the interns and let's say like I don't get this CSS thing, or I don't get this JavaScript thing, or I don't get this, whatever. And it's just kind of an open forum for people to come in and say, \"I'm curious about this,\" or \"I feel like I have this kind of hole in my knowledge,\" or things like that. And we'll fill those in. But it's been really nice to just have a default project that we work on every day.\n\nThe project that I mentioned, the chatbot, has been really interesting. I chose the project because I wanted to do something that had a really good feedback loop, meaning you can write some code and get an immediate response and some satisfaction from what you're doing. And chatbots are kind of like that where you can write...in our chatbot framework, they're called handlers where they just handle...you say if you see this certain string or if you match this regular expression, then do something with it. And so to be able to, in 10 minutes, write a handler that can return a dad joke when you ask for a dad joke, or something like that has been really interesting. \n\nWe do primarily Rails development. And so I chose a project that wasn't Rails just because Rails does a lot of things for you and has a lot of opinions. And so I wanted to choose a project that we could kind of build-up from scratch and make decisions as we went and get into the nuts and bolts of things without that kind of Rails [laughs] paradigms and Rails convention and everything kind of hanging over us. So it's been really interesting. We've encountered tons of little things that I don't think you would encounter working on a Rails project but are very common problems that developers have to wrestle with, just generally speaking. So it's just been really interesting.\n\nMIKE: I think you said a couple of things that I noticed when working on this that are important for keeping a program like this going in the long term. You said you have a long-term project that provides opportunities for learning.\n\nTAD: Yeah.\n\nMIKE: I found that getting things started as well to be exceptionally valuable. At first, I was preparing a presentation every day, which was fine. And I guess you could do that if you had time. But that wasn't as engaging. [laughs] When people had an interesting project to come back to, it kept that continuity. And it's not that we would do that every day, but that continuity was really helpful to allow people to continue. And if you have an off day where you didn't have time to prepare, well, that's great; people can pick up where they left off.\n\nTAD: Yeah, I started out the same as you when I was doing the skills clinic, where I was constantly trying to figure out material to present. And it was taking a lot of research, and I was going back through old college notes and stuff. And like, oh man, what are all the things that I could teach these folks? You touched on it where it's like, okay when you come through a bootcamp, you get a lot of experience, but it's very narrow and how do you broaden that out? \n\nAnd so it's like, okay, well, what are all these topics that I can do to broaden out their understanding into all these things? And it turns out that just working on a project that is not the same as what you're doing in your regular day-to-day work was just, well, I don't know if it's serendipity. It's just surprising how many common developer problems and patterns came out of just working on a project together. \n\nAnd I didn't have to sit and research all these things. It's just like, oh, yeah, we've hit a snag, or we've hit an issue. How do we solve it? Oh, you know, there are already patterns or solutions out there. Let's talk about it and figure out which one works for us. And that has been really surprising to me almost.\n\nMIKE: I've had a similar experience that you actually get your hands on the keyboard...this applies beyond software, you know, we talked about this skills clinic. When you go out into the real world and do real things rather than just talking about them, it's remarkable how much you notice that you don't notice when you're just trying to explain to somebody. \n\nYou notice this a lot when onboarding somebody who's just started somewhere that, oh yeah, you do this to set up. Oh wait, and then there's this other thing. Oh yeah, then there's this other thing you've got to do. Oh yeah, you have to install this. And oh yeah, well, you have to download this. You know, all of these things start coming to mind and becoming apparent that you just gloss over in your mind when you've done it a thousand times. That hands-on work surfaces those learning opportunities that you wouldn't get otherwise.\n\nTAD: Well, I'm curious because we have several people that also participate in the skills clinic; just throwing it out as a question to the rest of you here. What are some of the things that you've learned from skills clinic that you don't get from regular work?\n\nJASON: Right out of the gate, the first thing that came to mind is direct interaction with Redis constantly. And working in a Rails project we just take for granted a gem like ActiveModel and ActiveRecord and how those work together to give you this seamless interface where suddenly you don't have that...you don't even have a database anymore to enforce cardinality. And you're suddenly trying to figure out, okay, how can we implement a model where I just want to implement some sort of find by functionality where I want to find a record of some model by an attribute? \n\nWe're getting an introduction to lookup tables. And, again, it's a basic idea, and I think everybody's aware of it. But it's like so infrequently...I've never had to implement a lookup table. And we got to do that together as a group. Tad kind of walked us through the basics of that. So some of the most basic things that are provided to you and you take for granted you have to surrender to that and implement basic functionality so that you can proceed with the project. So that was the first thing that came to mind, no database, having to interact with Redis, and doing everything from memory.\n\nTAD: Yeah, just to give a little context, we're using a gem called Lita, L-I-T-A that was just barely recently abandoned [laughs] but we worked with it, and we're still going with it. And it doesn't have anything behind it except for Redis is kind of the brains or the storage for the bot. And to have something that's primitive is a really interesting constraint. \n\nBecause, like Jason said, you don't have indexes. You don't have joins. You don't have a lot of the things that a traditional database will give you. So it's like, I can put data in; I can pull data out. How do we solve these problems? It was a really interesting...just out of curiosity, how familiar are you guys with Redis now as compared to a year ago? Is that something you felt like you've learned a bunch about?\n\nRAMSES: Yeah, quite a bit.\n\nJASON: Yeah, quite a bit more. I'm comfortable with the different primitive data types that Redis supports. But not only that, but a recent problem we ran into was a timeout issue where we would have, you know, we'd ask our chatbot to do something, and in a development environment, it works great. And it would perform its task. It was the expected output. And then we tried doing the same thing from Slack, and it would do the same thing like ten times in a row. And it just kept repeating itself over and over and performing the same task with no obvious reasons as to why. \n\nAnd I think the problem was that there was a timeout. So Slack was expecting a response or acknowledgment within a certain amount of time. Our main thread was busy, and wasn't able to respond. So we realized, okay, we've got to offload this task and perform it asynchronously. Long story short, we did say, hey, what library exists out there that does thread management better than we could write it and handling locks better than we could do it? Let's implement Sidekiq. So we go and implement Sidekiq. \n\nAnd there's a configuration problem where, you know, we need an instance of the robot itself that Sidekiq would need to be able to complete the job, so one rolling problem into the next leads to these different design patterns. And long story short, being able to interact with Redis directly where we're able to basically...we don't need to pass an entire configuration to Sidekiq now. We can have a Sidekiq worker write essentially to a response queue. And we can have another loop that is always checking that queue and can read things back. So without being able to interface directly with it, that solution wouldn't have been as obvious. That wouldn't have been a more or less trivial thing we completed in one skills clinic session.\n\nTAD: Yeah, that was really interesting. To give our listeners (I don't know how many listeners we have, maybe just one.) some context, so Slack gives you a WebSocket. So they've got a new API where you basically send some information to Slack and say, \"Hey, I would like to connect.\" And they give you a URL for a WebSocket. And then you connect to that WebSocket and you send a message, hey, I'm here. I'm connecting to this WebSocket. And then you tell your app in Slack (There's a little checkbox list.) all the events you want it to tell you about that are happening in all the channels. \n\nAnd for all those events that you signed up for, it will send you a chunk of JSON down this WebSocket as one of their event structures. They send you an event, and we had our bot grab that event, parse it, pass it along to all the handlers, and then do a response. We also have to give an acknowledgment back to Slack, like, yes, I got this message, or else Slack is like, oh, you didn't acknowledge the message. I'm going to resend it; I'm going to resend it, I'm going to resend it. And it's going to keep resending it until it sees an acknowledgment. \n\nWell, if you get a message, yes, you can acknowledge it. But then, if you go and do a bunch of work that takes a while, then the next message that comes through, you are still busy doing work, and you won't be able to send that acknowledgment back. And Slack will start doing all these retries on you. And so we realized, okay, we've got this loop that is just checking for events. If we block that event loop, we're going to have to figure out...either store up all these messages or do something because Slack is going to start sending us a whole bunch of retries, and we don't want to do that. \n\nWe want to have that event loop looping as fast as we can. And the solution, like Jason said, is let's offload the long-running processes to Sidekiq. And I was actually really thrilled by this because having an event loop and being careful not to block your event loop or [laughs] slow things down in your event loop is actually a fairly common problem. Even on your phone, if you tap a button and if you don't get a response right away, if it doesn't do something right away, then you think it's frozen up. You're like, oh no, I locked up my app. \n\nSo responsiveness and making sure that you respond and handle those things right away is really important. But I don't think anyone had ever encountered that kind of a problem in day-to-day work. So I'm like, oh man, yeah, like, making sure your event loop is fast and responsive is a really cool problem to solve. And so I was kind of thrilled that we hit that because then we could talk through it and talk through some different solutions to fixing it.\n\nMIKE: That's really cool. Event loops they're everywhere, right? \n\nTAD: Yeah.\n\nMIKE: JavaScript has taken over the world. In JavaScript, the world revolves around that event loop. [laughs] That's kind of a big deal.\n\nTAD: What else have we done? I'm trying to figure out what are just some of the challenges we've had lately. Oh, one thing I'd be curious to have you guys talk about is your scheduling algorithms that you guys worked out. So a little context before I throw this out is one of the handlers we want to have this bot do is figure out pull requests assignments. So we want to be able to say to the bot, \"Hey, I've got this PR that I've just finished. I need reviewers for it. Will you assign some reviewers to it in a fair way?\" And it will look through the reviewers. \n\nAnd someone like me can say, like, \"Oh, I'm going on vacation. Hey, bot, don't assign me any PRs for a while.\" And then when I get back from vacation, I'm like, \"Okay, bot, I'm ready to accept PRs again.\" Things like that. So I'd be curious for you guys to talk about how you figured out that problem.\n\nJASON: Part of the problem with the PR assignments is we have a concept of full reviews and code reviews. So when we get work per project coming through, full reviews typically take a long time. There's a lot of manual testing. You want to make sure that a feature that it could be [inaudible 20:53]. Whereas in code review, you don't need to do manual testing, but your primary focus is on code. Typically, a full review also includes a code review, so it's just more work. And we try to rotate or make those fair. \n\nAnd right now, it's a random approach. Over time, it tends to even out, but there actually was an issue with our bot assignment basically that we have integrated with GitHub where it wasn't being fair because...it had to do with alphabetical name sorting. So some people, like another developer, we had Steve where we actually have an Easter egg for him in the codebase with a flag [crosstalk 21:31] where that would indicate, okay, we're only going to be assigning code reviews. So if you pass on that flag, we're just going to do code reviews because Steve had discovered this kind of unfair assignment. \n\nSo anyway, we decided that there was a lot of work that was done considering how are we going to do this? How are we going to keep it most fair? But in the long run, we have two queues. And we basically came to an approach where we're rotating people through the queues. And we're always checking to make sure that we have the most recent updated list of team members for the given team that were performing an assignment. So that's part of the command we can pass as the team. We update that. \n\nIf we have people in the queue that are no longer on that team after the most recent call, we have to remove them from the queue and redistribute that queue in a fair way. And when people are unavailable, that's another thing. You know, we could have people on the team, like you said, Tad, that \"I'm going on vacation. Please don't assign me any.\" You can tell Robbie to make you unavailable, and we'll account for that as well. We have to make sure that it's fair. And then, when you come back, what's the fairest approach to getting full review assignments again or code review assignments. So there are different options and flags that you can pass through. \n\nBut queue management has been a big topic that has required a lot of thoughtful consideration and considering different approaches to that. Ultimately, we have a kind of first-in, first-out approach. So it's a general queue structure for these lines, but it's a rotating queue. So anyway, I don't want to get...I feel like it'd be really boring talking about the individual queue structure unless you want to talk about it.\n\nBut there's a lot of iteration and a lot of discussion. We probably took probably almost six or seven skills clinic sessions just developing a fair queue structure and then, with every action that you take, making sure that we maintain the fairest approach for those PR assignments. As an aside, from just the queue structure, the cool feature about the PRs and the handler is we've created an API client with GitHub that has all this base functionality built out. \n\nSo it's a simple, almost trivial way of once we do that PR assignment, we update the actual description on the PR itself. So the developer doesn't need to add those people. It adds the people to the assignment then adds him in the description with an @ mention. And then, in the Slack channel, we'll use their Slack @ mention name to call their attention to the PR they were just assigned to. So kind of as an aside, and I feel like I'm very long-winded with this, but the queue structure itself that's a problem that I don't think we would have encountered in our core work. It took a lot of thought.\n\nTAD: To me...I didn't work on that directly. Sometimes in the skills clinic, we kind of break into teams and work on our individual parts. For me, one of the more fascinating things was when I learned about queues, it was in a college setting in a class. And they just said, \"Here's a data structure. Call the queue. Here's your homework assignment, implement a queue, and implement a queue using a linked list and implement a queue using an array. You'll be graded on it on Friday.\"\n\nAnd so we got queue theory, and we got a queue assignment, but we didn't have any use for it. We just kind of did one, and then we were done. And we moved on to the next data structure. And yours was really interesting to me because it came about organically because you were talking about, okay, how do we distribute this? How do we make it fair? How do we do these different things? And it's just like, so we have code reviews, and we have full reviews. What if we had essentially two lines that people were standing in and waiting to be up for these things? And that kind of just matches a queue perfectly. And we've just implemented queues in Redis, and that worked. \n\nThe other thing that was really fascinating to me is scheduling problems are, I think, a pretty common problem to encounter just as a developer in general. And to see you guys working through the scheduling problems making sure that, you know, because I learned these things in a formal classroom, and so we learned terms like starvation. Like, what if this job never takes place on accident, or what about all these different things? \n\nAnd you guys didn't necessarily have that same vocabulary, but you guys encountered the same problem. And you found solutions for the same kind of problems as you would in just regular scheduling. And I thought that was really interesting to just see that just having a real-world project introduced all these concepts to you just organically, and you had to just solve them and work through them just organically. So that was a really interesting thing for me to observe just from the outside.\n\nMIKE: Such great stuff. I'm curious; we have Mark with us, who was part of our inaugural cohort, to say it in [laughs] fancy words. He was part of our first group in an internship that did the skills clinic, and then he's come back. And he's done it more recently. I'm curious, Mark, what parts of the skills clinic have you found most useful that you would recommend other companies implement in order to help people who are wanting to grow their skills, from your perspective at least?\n\nMARK: Hello, I'm Mark. I guess the part that I find most useful is the explanations that my teammates give when they're editing the code right in front of me because they can explain what they're doing, as well as explaining how they've come to this conclusion, as well as other things like explaining how to debug something. Because you can tell someone to debug something and give them tools but giving someone tools to debug something and actually showing them how to debug something and what to look for when debugging something are very different.\n\nTAD: Something that's been funny to me is we usually do a shared session using VS Code, which I think is crazy. Like, I love it that everyone can code and type and talk to each other at the same time. And one person could be working at the top of the file, and the other person can be working at the bottom of the file. But that's just an aside. \n\nWhat's been really interesting to me is I'll present something, and I'll talk about it, and I'll just be doing my regular thing. And I'll be like, oh man, I need to debug something, or I need to do something. And afterwards, people will tell me, \"Oh, I totally learned some little debugging technique,\" or \"I learned some programming technique just by watching you.\" And it wasn't necessarily even related to what I was talking about. But people afterwards will be like, \"Oh yeah, I didn't know Pry could do that.\" Pry is like a Ruby REPL that has a lot of cool stuff built in. And I'm like, oh yeah, well, I use that every day. \n\nBut it's interesting to see just working together with people, with other developers, and you can just pick up on the little things that they do to make their life easier, or make their debugging faster, or something like that. And you could just be like, oh, wow, that's really cool. I'm going to squirrel that away, or I'm going to put that in my toolbox too. That's been really interesting to me.\n\nMIKE: Well, that's interesting. So you're saying that oftentimes, the most valuable...and this seems to be a recurring theme as we've talked about this. Oftentimes, the most valuable opportunities come unexpectedly; you've mentioned serendipity. You're working on a problem, and this side thing comes up, and everybody learns way more from that side opportunity [laughs] than what you had planned initially. You're exploring around, and you find these gems that you wouldn't find if you were just focused on going to your original destination.\n\nTAD: Yeah. And just seeing all the different approaches that people are taking to something has really helped me broaden my thinking about certain stuff that I've been doing as well, which was kind of like a side effect that I didn't expect. \n\nI'm probably one of the more senior people on the team, and I expected it to be kind of like I'm teaching them. But I am surprised at how many little things I learn or understand better just based on what they're doing, or their conversations, or their questions. I'm like, oh wow, I kind of expected it to be kind of single-directional. But we're all working together and teaching each other simultaneously, which has been really fun for me.\n\nJASON: Adding to that, it's one of those environments where I don't think anybody hesitates to ask a question or even to casually [laughs] just be honest and say, \"I get that you guys get all of what's going on right now. But I looked up at my screen for 20 seconds to answer a question, and I have no clue what's going on.\" And everybody having that kind of friendly almost, you know, just pure vibe. We're all working on the same problem. We're all trying to achieve the same objective. \n\nAnd there's absolutely no problem with someone saying, \"I do not understand what you're talking about. Please teach me.\" That's the entire idea of the skills clinic. And so knowing that that's the entire idea, I don't think anyone's afraid of speaking up and saying, \"I don't understand something.\" And it's led everybody to get a lot closer. \n\nOne of the awesome side effects that I've encountered is just another...and this has come up in previous podcasts, but just that getting-to-know-you sort of thing. It's just another avenue where those social interactions are so important because you can't learn from other people if you don't talk to them. [laughs] And you don't talk to them if you don't feel comfortable talking to them. So I often ask everyone pretty much on the call for help independently off-screen people who have been in the skills clinic.\n\nTAD: Yeah, I really like here at Acima; we talk a lot about psychological safety. And I think we even turn that up in skills clinic where we all come in, and we're just like, the whole reason we're here is because we're ignorant about something, and we want to learn more about everything. So there's no shaming. There's no like, \"Oh my gosh, you didn't know that?\" nothing like that. It's really exciting to say, \"Oh, you didn't know about that? Well, this is exciting because today is the day you get to learn about...\" and then, you know, something.\n\nWe're excited to share with each other as opposed to putting each other down or, I don't know. I'm curious to ask, maybe Eddy, what have you learned from skills clinic, or what things have you gotten out of it? And I'm asking you because you're someone who's in our QA department who knows somewhat about programming but doesn't have any formal programming experience.\n\nEDDY: What I find valuable is how someone uses their resources to find a solution to a problem. It's really easy to get assigned a pull request, but you never really get to see the cycle of what it went through in the back end to get that successful outcome. So I think it's been really integral and critical for me to...or more valuable rather to see the different approaches for individual problems and how they're unique and how we can use you as a resource or the Atlas mentoring channel, or Stack Overflow and such. So to me, that has been super valuable to see how everyone's approach is different.\n\nTAD: Yeah, that's interesting. Something that I've noticed is that it's not lack of skill; it's lack of experience, probably, that slows people down or blocks people. So when I say that, for example, I've talked to you and maybe some of the other people coming in. And if you're new coming in and you don't really have context or experience, so a lot of times you're just like, I don't know, Google, and then, I don't know, Google again. I don't know, Stack Overflow. \n\nAnd that could take you like an hour before you get to the answer or figure out what you need to do. But if someone else who's familiar with it comes along and is like, \"Oh yeah, I know exactly the documentation that you probably want to read,\" Or \"I know exactly which library you could use to fix that or solve that problem,\" then suddenly, it's like, oh, [laughs] blindly searching for an hour just got replaced with 10 minutes of talking to somebody and getting a recommendation.\n\nEDDY: I just wanted to kind of echo what you said. I think it's...I saw a video from what makes someone successful. And one of those topics was, like, reach out to someone who's in that same profession, who's been there longer. It's like a cheat code, like a shortcut. It's like, you can eventually stumble through that same problem through sweat, and agony, and blood, you know, and stress, or you can reach out to someone who's already been through that map, you know, and cut it significantly to get the answer. So why wouldn't you use someone who has run into that problem? It's like a real-life cheat code, you know.\n\nJASON: [inaudible 35:13] was a senior developer at Acima for a long time. And I had a conversation with him once, and he oversimplified it, or he may have been facetious, but I think there's a kernel of truth in this. He said the only difference between a junior dev and a senior is how proficient they are at finding the answers that they're looking for. They learn to learn better, or they learn to find those answers or search better. There could be a number of different things, but that just came to mind as we were talking about this.\n\nMIKE: More than a kernel of truth. It's remarkable how true that is.\n\nTAD: Well, that's funny because what was it? Like a couple of weeks ago, you were implementing some JavaScript stuff and some marketing and tracking and things like that. And you reached out to me, and I was like, \"Oh my gosh, Jason, I've got scar tissue. I've got stories. [laughs] I see you're about to step on a path that I've been down. And let me tell you, it's not pretty at the other end, but here's how it will go. And here's how you're going to get there.\" \n\nThat was just kind of funny to me is that I think we all have scar tissue from some gnarly problems we've had to deal with and a story to tell, and then just like, oh yeah, I see what path you're on. [laughs] Here you go, like, good luck. And here's where you're going to end up.\n\nJASON: Exactly as it was mentioned. It's kind of funny. What you were saying and what you were explaining to me about the problem we were encountering is exactly what was happening. And it sounds like it's just something everybody has to deal with.\n\nMIKE: We've talked about the origin of this skills clinic idea, a lot of things we've worked on, and what has made it useful. And it sounds like, if I were to summarize what I've heard, a lot of what has made it useful is not necessarily the overt this is what we plan to talk about, but the incidental benefits of having developers work together and watch each other and learn. Of course, you can get that from pairing. There are other scenarios that that come up. \n\nBut in skills clinic, you're actively going and looking for these new experiences that you might not encounter otherwise. From my perception, I think it's been a very valuable thing that we've done, and I would recommend that others try it. Is that a universal sentiment? Would you recommend that other companies try this idea, start up a skills clinic, you know, and start this daily pattern to improve your skills together?\n\nTAD: Absolutely. I've learned a ton. And I've hit things that I didn't expect to hit and learned things I didn't expect to learn. And like I mentioned earlier, I kind of expected it to be me teaching them, and it's us teaching us, which was awesome. \n\nEDDY: I wanted to say as someone who has a year under their belt as far as learning how to code, it was incremental learning until skills clinic, in which case I feel like my skill has grown exponentially, so yes.\n\nJASON: For those concerned that it's a wasted hour every day, [laughs] you get 100 fold back out of that invested hour. It's amazing how much you can get back. Like Tad was saying, it's serendipitous that you talked about this topic incidentally on Tuesday, and Thursday, that solution came up in my actual work. And that just saved me more than the hour I invested in skills clinic. So it's this compounding effect.\n\nMARK: I think skills clinic is very useful, at least as a coder. For other jobs, they might not do it as often or might structure it differently. But I do think implementing some sort of skill clinic session placed once a week would be good for other companies as well.\n\nTAD: I really like the regularity that we've set up that now I know every day at 10:00 o'clock I'm going to be doing this. I think when we had alternating mornings and afternoons and only some of the days and stuff like that, we kind of lost something. But having it as a regular part of our day and having it as something to look forward to and having it blocked out so we're not having meetings on top of it and stuff like that has really made it much better.\n\nMIKE: And maybe that's a good place to land is that if you want to make this work, you got to be consistent. You should come up with something that you can work on for a while, something out of band that you're not necessarily working on in your daily work to give people different experiences. And just be consistent about it. And we've heard some witness testimonials that it's an investment that has a high return. \n\nThose who are listening who are in a position to try something like this, I highly recommend that you try it. And the worst thing that happens is it doesn't work out for you. But this opportunity to improve the skills of the people you work with and help everybody build them as they have and grow them and become more effective is extremely worthwhile. Thank you, everybody, for being here. Thank you to our listeners. I hope you can put this into practice. See you next time.","content_html":"We talk about something specific here at Acima with the hope that other companies will replicate our skills clinics because it's been an extremely valuable thing that we've done.
\n\nTranscript:
\n\nMIKE: Hello and welcome to another episode of The Acima Development Podcast. I'm Mike Challis. I'm hosting today. We've got a group here that I think has been here before, so I won't start with introductions. But I'll say names as people speak so that listeners can know who they're listening to.
\n\nToday we have a topic that I'm excited about. I'm generally excited about the topics, but today is one that's kind of close to my heart, and it's what we call our Skills Clinic. Usually, we try to keep things general. Today we're going to be talking about something specifically that we do at Acima that I hope other companies will replicate this idea because I think it's been an extremely valuable thing that we've done.
\n\nLet me give some history. About, I don't know, a year and a half ago, the beginning of the summer of 2021, we hosted an internship. And one thing that we've noticed...and this applies to the internship but it also applies to a lot of other situations in which new developers come into software development. Now, there are people who come through a very traditional path into software. They go to a four-year university. They get a degree in computer science or something similar. They do an internship somewhere, and they go, and they get a job.
\n\nBut there are a lot of people who don't follow that path to get into software development. And there are a lot of programs out there to try to bridge that gap. One thing that exists is software bootcamps; a lot of people have used those, which tries to very quickly get you knowledgeable in software. This applies to people who've maybe got a degree somewhere else, or have work experience or, you know, years living adulting. [laughs] So they have a good sense of how to do things in life and maybe have experience in computing but haven't learned the tools of software.
\n\nSo they'll go, and they'll do a really intense bootcamp for two or four months, something like that, and then move on to getting a job, you know, an expedited path. That's a great way to get into software if it works for you. Certainly, there are going to be some things left out compared to what you get with traditional computer science.
\n\nA lot of people complain about computer science programs that they teach a lot of theory and not much practical experience. People can come out of a computer science degree and really have no idea [laughs] how to work in a real-world setting and have to learn those skills. So there are some advantages to both sides. But there are some gaps if you've gone to bootcamp so basic theory things you don't know that can sometimes hold you back.
\n\nOne thing that we've done a lot is provide mentorship and internships so people internally who have not worked in software can kind of learn the ropes and move into coding and build their skills as they go. I think it's a great way to learn. A lot of people out there in the industry learn that way. And I strongly encourage it if that's something that interests you. But once again, there's often this feeling that like, oh, there are these things I didn't learn. There's not a bootcamp for people who are already working. It's something that gets you up and running but doesn't follow up after there.
\n\nPeople who come from a traditional computer science background as well maybe they want to learn things outside of what they learned in school or outside of what they're doing at work and build their skills. All of these people have this need to have ongoing development, ongoing learning. Oftentimes, the work environment doesn't necessarily provide that. It gives you hands-on experience but not necessarily the theory, you know, things that would build those fundamental skills. A lot of background here; I'll give one more piece of background.
\n\nWhen we were looking to do this internship, there was a product manager who worked with us who mentioned that his daughter was really an avid volleyball player. And during the summer, she really wanted to build her skills, and there were lots of programs around. I don't know about lots, but several programs around that will provide that opportunity, and what they call themselves is a skills clinic.
\n\nA skills clinic is not for people who've never played volleyball before. And this exists in other sports as well. It's not for somebody who's never played before. It's for somebody who knows what they're doing but wants to do drills, wants to build their fundamentals so that when they go back and play the real game, they're better at it. We said, "Well, that is the perfect name. That's the perfect name."
\n\nWe need to have something like that. We need to have a skills clinic for software so that we have an opportunity to build our fundamentals to do that practice outside of our normal routine that builds the fundamental skills so that when we go back to our work, we are stronger, better, more confident, and can be better coders. So we started a program where an hour or so each day for the internship and for anybody interested...there have been a lot of junior developers, but there have also been more senior developers who've joined to get together and work on some fundamental skill, and we've called that skills clinic.
\n\nWe did it during that internship and just kept it going. So for about a year and a half, we've been doing more or less daily, I'd say more, [laughs] almost always daily, a skills clinic where we get together and work on something. We started with some almost lecture-like formats where we did a presentation, talked about a computer science concept, and we've actually, by design, moved away from that. Asked for feedback and found that, yeah, that's great, but it's really hard to engage with a presentation like that.
\n\nAnd over time, we've moved more and more toward hands-on experience. So we're writing code, but we're writing code outside of what we'd normally do at work in a way that would teach us something new. So we have learned some basic computer science concepts and learned about how computers work, [laughs] the basics of a processor. Then I think we learned a lot more by writing some machine code [laughs] to learn how that works, not very much because that's a pain.
\n\nBut then we wrote some Assembly. We looked up the specs for, you know, x86 computer and figured out the Assembly language to do a basic addition operation and then moved on. We wrote some other low-level languages. And then, we thought of low-level code in a low-level language. And then we took some time writing our own languages. We split up into several groups, and we wrote our own programming languages. I thought that was a lot of fun.
\n\nWe've gone beyond that point to work on a number of different projects. And it's a great opportunity for people to get in and build their skills. It's important to me because I helped launched it, but honestly, I have not been as involved with it for a while. My role has changed somewhat. But we do have Tad on the call with us, who has really pushed it forward, as well as Ramses, who's helped a lot with that.
\n\nAnd they have kept this going, and they've been a great asset, I think, to the other developers and to the company. I'm curious to hear what Tad and Ramses...what do you think? I've kind of talked about how we launched it. I'm curious what you've been doing for the last several months as well as your thoughts about the value of skills clinic.
\n\nTAD: Well, what we've been working on primarily is a chatbot for our company's Slack channel. The interesting thing is that we kind of just do whatever people need to be done. We have a default project that we work on every day. But there have been a few times we just barely finished our internship program for the summer, but I've just talked to the interns and been like, "Hey, what do you need? Like, what holes do you have? What are you missing?"
\n\nAnd some of the days we just talk to the interns and let's say like I don't get this CSS thing, or I don't get this JavaScript thing, or I don't get this, whatever. And it's just kind of an open forum for people to come in and say, "I'm curious about this," or "I feel like I have this kind of hole in my knowledge," or things like that. And we'll fill those in. But it's been really nice to just have a default project that we work on every day.
\n\nThe project that I mentioned, the chatbot, has been really interesting. I chose the project because I wanted to do something that had a really good feedback loop, meaning you can write some code and get an immediate response and some satisfaction from what you're doing. And chatbots are kind of like that where you can write...in our chatbot framework, they're called handlers where they just handle...you say if you see this certain string or if you match this regular expression, then do something with it. And so to be able to, in 10 minutes, write a handler that can return a dad joke when you ask for a dad joke, or something like that has been really interesting.
\n\nWe do primarily Rails development. And so I chose a project that wasn't Rails just because Rails does a lot of things for you and has a lot of opinions. And so I wanted to choose a project that we could kind of build-up from scratch and make decisions as we went and get into the nuts and bolts of things without that kind of Rails [laughs] paradigms and Rails convention and everything kind of hanging over us. So it's been really interesting. We've encountered tons of little things that I don't think you would encounter working on a Rails project but are very common problems that developers have to wrestle with, just generally speaking. So it's just been really interesting.
\n\nMIKE: I think you said a couple of things that I noticed when working on this that are important for keeping a program like this going in the long term. You said you have a long-term project that provides opportunities for learning.
\n\nTAD: Yeah.
\n\nMIKE: I found that getting things started as well to be exceptionally valuable. At first, I was preparing a presentation every day, which was fine. And I guess you could do that if you had time. But that wasn't as engaging. [laughs] When people had an interesting project to come back to, it kept that continuity. And it's not that we would do that every day, but that continuity was really helpful to allow people to continue. And if you have an off day where you didn't have time to prepare, well, that's great; people can pick up where they left off.
\n\nTAD: Yeah, I started out the same as you when I was doing the skills clinic, where I was constantly trying to figure out material to present. And it was taking a lot of research, and I was going back through old college notes and stuff. And like, oh man, what are all the things that I could teach these folks? You touched on it where it's like, okay when you come through a bootcamp, you get a lot of experience, but it's very narrow and how do you broaden that out?
\n\nAnd so it's like, okay, well, what are all these topics that I can do to broaden out their understanding into all these things? And it turns out that just working on a project that is not the same as what you're doing in your regular day-to-day work was just, well, I don't know if it's serendipity. It's just surprising how many common developer problems and patterns came out of just working on a project together.
\n\nAnd I didn't have to sit and research all these things. It's just like, oh, yeah, we've hit a snag, or we've hit an issue. How do we solve it? Oh, you know, there are already patterns or solutions out there. Let's talk about it and figure out which one works for us. And that has been really surprising to me almost.
\n\nMIKE: I've had a similar experience that you actually get your hands on the keyboard...this applies beyond software, you know, we talked about this skills clinic. When you go out into the real world and do real things rather than just talking about them, it's remarkable how much you notice that you don't notice when you're just trying to explain to somebody.
\n\nYou notice this a lot when onboarding somebody who's just started somewhere that, oh yeah, you do this to set up. Oh wait, and then there's this other thing. Oh yeah, then there's this other thing you've got to do. Oh yeah, you have to install this. And oh yeah, well, you have to download this. You know, all of these things start coming to mind and becoming apparent that you just gloss over in your mind when you've done it a thousand times. That hands-on work surfaces those learning opportunities that you wouldn't get otherwise.
\n\nTAD: Well, I'm curious because we have several people that also participate in the skills clinic; just throwing it out as a question to the rest of you here. What are some of the things that you've learned from skills clinic that you don't get from regular work?
\n\nJASON: Right out of the gate, the first thing that came to mind is direct interaction with Redis constantly. And working in a Rails project we just take for granted a gem like ActiveModel and ActiveRecord and how those work together to give you this seamless interface where suddenly you don't have that...you don't even have a database anymore to enforce cardinality. And you're suddenly trying to figure out, okay, how can we implement a model where I just want to implement some sort of find by functionality where I want to find a record of some model by an attribute?
\n\nWe're getting an introduction to lookup tables. And, again, it's a basic idea, and I think everybody's aware of it. But it's like so infrequently...I've never had to implement a lookup table. And we got to do that together as a group. Tad kind of walked us through the basics of that. So some of the most basic things that are provided to you and you take for granted you have to surrender to that and implement basic functionality so that you can proceed with the project. So that was the first thing that came to mind, no database, having to interact with Redis, and doing everything from memory.
\n\nTAD: Yeah, just to give a little context, we're using a gem called Lita, L-I-T-A that was just barely recently abandoned [laughs] but we worked with it, and we're still going with it. And it doesn't have anything behind it except for Redis is kind of the brains or the storage for the bot. And to have something that's primitive is a really interesting constraint.
\n\nBecause, like Jason said, you don't have indexes. You don't have joins. You don't have a lot of the things that a traditional database will give you. So it's like, I can put data in; I can pull data out. How do we solve these problems? It was a really interesting...just out of curiosity, how familiar are you guys with Redis now as compared to a year ago? Is that something you felt like you've learned a bunch about?
\n\nRAMSES: Yeah, quite a bit.
\n\nJASON: Yeah, quite a bit more. I'm comfortable with the different primitive data types that Redis supports. But not only that, but a recent problem we ran into was a timeout issue where we would have, you know, we'd ask our chatbot to do something, and in a development environment, it works great. And it would perform its task. It was the expected output. And then we tried doing the same thing from Slack, and it would do the same thing like ten times in a row. And it just kept repeating itself over and over and performing the same task with no obvious reasons as to why.
\n\nAnd I think the problem was that there was a timeout. So Slack was expecting a response or acknowledgment within a certain amount of time. Our main thread was busy, and wasn't able to respond. So we realized, okay, we've got to offload this task and perform it asynchronously. Long story short, we did say, hey, what library exists out there that does thread management better than we could write it and handling locks better than we could do it? Let's implement Sidekiq. So we go and implement Sidekiq.
\n\nAnd there's a configuration problem where, you know, we need an instance of the robot itself that Sidekiq would need to be able to complete the job, so one rolling problem into the next leads to these different design patterns. And long story short, being able to interact with Redis directly where we're able to basically...we don't need to pass an entire configuration to Sidekiq now. We can have a Sidekiq worker write essentially to a response queue. And we can have another loop that is always checking that queue and can read things back. So without being able to interface directly with it, that solution wouldn't have been as obvious. That wouldn't have been a more or less trivial thing we completed in one skills clinic session.
\n\nTAD: Yeah, that was really interesting. To give our listeners (I don't know how many listeners we have, maybe just one.) some context, so Slack gives you a WebSocket. So they've got a new API where you basically send some information to Slack and say, "Hey, I would like to connect." And they give you a URL for a WebSocket. And then you connect to that WebSocket and you send a message, hey, I'm here. I'm connecting to this WebSocket. And then you tell your app in Slack (There's a little checkbox list.) all the events you want it to tell you about that are happening in all the channels.
\n\nAnd for all those events that you signed up for, it will send you a chunk of JSON down this WebSocket as one of their event structures. They send you an event, and we had our bot grab that event, parse it, pass it along to all the handlers, and then do a response. We also have to give an acknowledgment back to Slack, like, yes, I got this message, or else Slack is like, oh, you didn't acknowledge the message. I'm going to resend it; I'm going to resend it, I'm going to resend it. And it's going to keep resending it until it sees an acknowledgment.
\n\nWell, if you get a message, yes, you can acknowledge it. But then, if you go and do a bunch of work that takes a while, then the next message that comes through, you are still busy doing work, and you won't be able to send that acknowledgment back. And Slack will start doing all these retries on you. And so we realized, okay, we've got this loop that is just checking for events. If we block that event loop, we're going to have to figure out...either store up all these messages or do something because Slack is going to start sending us a whole bunch of retries, and we don't want to do that.
\n\nWe want to have that event loop looping as fast as we can. And the solution, like Jason said, is let's offload the long-running processes to Sidekiq. And I was actually really thrilled by this because having an event loop and being careful not to block your event loop or [laughs] slow things down in your event loop is actually a fairly common problem. Even on your phone, if you tap a button and if you don't get a response right away, if it doesn't do something right away, then you think it's frozen up. You're like, oh no, I locked up my app.
\n\nSo responsiveness and making sure that you respond and handle those things right away is really important. But I don't think anyone had ever encountered that kind of a problem in day-to-day work. So I'm like, oh man, yeah, like, making sure your event loop is fast and responsive is a really cool problem to solve. And so I was kind of thrilled that we hit that because then we could talk through it and talk through some different solutions to fixing it.
\n\nMIKE: That's really cool. Event loops they're everywhere, right?
\n\nTAD: Yeah.
\n\nMIKE: JavaScript has taken over the world. In JavaScript, the world revolves around that event loop. [laughs] That's kind of a big deal.
\n\nTAD: What else have we done? I'm trying to figure out what are just some of the challenges we've had lately. Oh, one thing I'd be curious to have you guys talk about is your scheduling algorithms that you guys worked out. So a little context before I throw this out is one of the handlers we want to have this bot do is figure out pull requests assignments. So we want to be able to say to the bot, "Hey, I've got this PR that I've just finished. I need reviewers for it. Will you assign some reviewers to it in a fair way?" And it will look through the reviewers.
\n\nAnd someone like me can say, like, "Oh, I'm going on vacation. Hey, bot, don't assign me any PRs for a while." And then when I get back from vacation, I'm like, "Okay, bot, I'm ready to accept PRs again." Things like that. So I'd be curious for you guys to talk about how you figured out that problem.
\n\nJASON: Part of the problem with the PR assignments is we have a concept of full reviews and code reviews. So when we get work per project coming through, full reviews typically take a long time. There's a lot of manual testing. You want to make sure that a feature that it could be [inaudible 20:53]. Whereas in code review, you don't need to do manual testing, but your primary focus is on code. Typically, a full review also includes a code review, so it's just more work. And we try to rotate or make those fair.
\n\nAnd right now, it's a random approach. Over time, it tends to even out, but there actually was an issue with our bot assignment basically that we have integrated with GitHub where it wasn't being fair because...it had to do with alphabetical name sorting. So some people, like another developer, we had Steve where we actually have an Easter egg for him in the codebase with a flag [crosstalk 21:31] where that would indicate, okay, we're only going to be assigning code reviews. So if you pass on that flag, we're just going to do code reviews because Steve had discovered this kind of unfair assignment.
\n\nSo anyway, we decided that there was a lot of work that was done considering how are we going to do this? How are we going to keep it most fair? But in the long run, we have two queues. And we basically came to an approach where we're rotating people through the queues. And we're always checking to make sure that we have the most recent updated list of team members for the given team that were performing an assignment. So that's part of the command we can pass as the team. We update that.
\n\nIf we have people in the queue that are no longer on that team after the most recent call, we have to remove them from the queue and redistribute that queue in a fair way. And when people are unavailable, that's another thing. You know, we could have people on the team, like you said, Tad, that "I'm going on vacation. Please don't assign me any." You can tell Robbie to make you unavailable, and we'll account for that as well. We have to make sure that it's fair. And then, when you come back, what's the fairest approach to getting full review assignments again or code review assignments. So there are different options and flags that you can pass through.
\n\nBut queue management has been a big topic that has required a lot of thoughtful consideration and considering different approaches to that. Ultimately, we have a kind of first-in, first-out approach. So it's a general queue structure for these lines, but it's a rotating queue. So anyway, I don't want to get...I feel like it'd be really boring talking about the individual queue structure unless you want to talk about it.
\n\nBut there's a lot of iteration and a lot of discussion. We probably took probably almost six or seven skills clinic sessions just developing a fair queue structure and then, with every action that you take, making sure that we maintain the fairest approach for those PR assignments. As an aside, from just the queue structure, the cool feature about the PRs and the handler is we've created an API client with GitHub that has all this base functionality built out.
\n\nSo it's a simple, almost trivial way of once we do that PR assignment, we update the actual description on the PR itself. So the developer doesn't need to add those people. It adds the people to the assignment then adds him in the description with an @ mention. And then, in the Slack channel, we'll use their Slack @ mention name to call their attention to the PR they were just assigned to. So kind of as an aside, and I feel like I'm very long-winded with this, but the queue structure itself that's a problem that I don't think we would have encountered in our core work. It took a lot of thought.
\n\nTAD: To me...I didn't work on that directly. Sometimes in the skills clinic, we kind of break into teams and work on our individual parts. For me, one of the more fascinating things was when I learned about queues, it was in a college setting in a class. And they just said, "Here's a data structure. Call the queue. Here's your homework assignment, implement a queue, and implement a queue using a linked list and implement a queue using an array. You'll be graded on it on Friday."
\n\nAnd so we got queue theory, and we got a queue assignment, but we didn't have any use for it. We just kind of did one, and then we were done. And we moved on to the next data structure. And yours was really interesting to me because it came about organically because you were talking about, okay, how do we distribute this? How do we make it fair? How do we do these different things? And it's just like, so we have code reviews, and we have full reviews. What if we had essentially two lines that people were standing in and waiting to be up for these things? And that kind of just matches a queue perfectly. And we've just implemented queues in Redis, and that worked.
\n\nThe other thing that was really fascinating to me is scheduling problems are, I think, a pretty common problem to encounter just as a developer in general. And to see you guys working through the scheduling problems making sure that, you know, because I learned these things in a formal classroom, and so we learned terms like starvation. Like, what if this job never takes place on accident, or what about all these different things?
\n\nAnd you guys didn't necessarily have that same vocabulary, but you guys encountered the same problem. And you found solutions for the same kind of problems as you would in just regular scheduling. And I thought that was really interesting to just see that just having a real-world project introduced all these concepts to you just organically, and you had to just solve them and work through them just organically. So that was a really interesting thing for me to observe just from the outside.
\n\nMIKE: Such great stuff. I'm curious; we have Mark with us, who was part of our inaugural cohort, to say it in [laughs] fancy words. He was part of our first group in an internship that did the skills clinic, and then he's come back. And he's done it more recently. I'm curious, Mark, what parts of the skills clinic have you found most useful that you would recommend other companies implement in order to help people who are wanting to grow their skills, from your perspective at least?
\n\nMARK: Hello, I'm Mark. I guess the part that I find most useful is the explanations that my teammates give when they're editing the code right in front of me because they can explain what they're doing, as well as explaining how they've come to this conclusion, as well as other things like explaining how to debug something. Because you can tell someone to debug something and give them tools but giving someone tools to debug something and actually showing them how to debug something and what to look for when debugging something are very different.
\n\nTAD: Something that's been funny to me is we usually do a shared session using VS Code, which I think is crazy. Like, I love it that everyone can code and type and talk to each other at the same time. And one person could be working at the top of the file, and the other person can be working at the bottom of the file. But that's just an aside.
\n\nWhat's been really interesting to me is I'll present something, and I'll talk about it, and I'll just be doing my regular thing. And I'll be like, oh man, I need to debug something, or I need to do something. And afterwards, people will tell me, "Oh, I totally learned some little debugging technique," or "I learned some programming technique just by watching you." And it wasn't necessarily even related to what I was talking about. But people afterwards will be like, "Oh yeah, I didn't know Pry could do that." Pry is like a Ruby REPL that has a lot of cool stuff built in. And I'm like, oh yeah, well, I use that every day.
\n\nBut it's interesting to see just working together with people, with other developers, and you can just pick up on the little things that they do to make their life easier, or make their debugging faster, or something like that. And you could just be like, oh, wow, that's really cool. I'm going to squirrel that away, or I'm going to put that in my toolbox too. That's been really interesting to me.
\n\nMIKE: Well, that's interesting. So you're saying that oftentimes, the most valuable...and this seems to be a recurring theme as we've talked about this. Oftentimes, the most valuable opportunities come unexpectedly; you've mentioned serendipity. You're working on a problem, and this side thing comes up, and everybody learns way more from that side opportunity [laughs] than what you had planned initially. You're exploring around, and you find these gems that you wouldn't find if you were just focused on going to your original destination.
\n\nTAD: Yeah. And just seeing all the different approaches that people are taking to something has really helped me broaden my thinking about certain stuff that I've been doing as well, which was kind of like a side effect that I didn't expect.
\n\nI'm probably one of the more senior people on the team, and I expected it to be kind of like I'm teaching them. But I am surprised at how many little things I learn or understand better just based on what they're doing, or their conversations, or their questions. I'm like, oh wow, I kind of expected it to be kind of single-directional. But we're all working together and teaching each other simultaneously, which has been really fun for me.
\n\nJASON: Adding to that, it's one of those environments where I don't think anybody hesitates to ask a question or even to casually [laughs] just be honest and say, "I get that you guys get all of what's going on right now. But I looked up at my screen for 20 seconds to answer a question, and I have no clue what's going on." And everybody having that kind of friendly almost, you know, just pure vibe. We're all working on the same problem. We're all trying to achieve the same objective.
\n\nAnd there's absolutely no problem with someone saying, "I do not understand what you're talking about. Please teach me." That's the entire idea of the skills clinic. And so knowing that that's the entire idea, I don't think anyone's afraid of speaking up and saying, "I don't understand something." And it's led everybody to get a lot closer.
\n\nOne of the awesome side effects that I've encountered is just another...and this has come up in previous podcasts, but just that getting-to-know-you sort of thing. It's just another avenue where those social interactions are so important because you can't learn from other people if you don't talk to them. [laughs] And you don't talk to them if you don't feel comfortable talking to them. So I often ask everyone pretty much on the call for help independently off-screen people who have been in the skills clinic.
\n\nTAD: Yeah, I really like here at Acima; we talk a lot about psychological safety. And I think we even turn that up in skills clinic where we all come in, and we're just like, the whole reason we're here is because we're ignorant about something, and we want to learn more about everything. So there's no shaming. There's no like, "Oh my gosh, you didn't know that?" nothing like that. It's really exciting to say, "Oh, you didn't know about that? Well, this is exciting because today is the day you get to learn about..." and then, you know, something.
\n\nWe're excited to share with each other as opposed to putting each other down or, I don't know. I'm curious to ask, maybe Eddy, what have you learned from skills clinic, or what things have you gotten out of it? And I'm asking you because you're someone who's in our QA department who knows somewhat about programming but doesn't have any formal programming experience.
\n\nEDDY: What I find valuable is how someone uses their resources to find a solution to a problem. It's really easy to get assigned a pull request, but you never really get to see the cycle of what it went through in the back end to get that successful outcome. So I think it's been really integral and critical for me to...or more valuable rather to see the different approaches for individual problems and how they're unique and how we can use you as a resource or the Atlas mentoring channel, or Stack Overflow and such. So to me, that has been super valuable to see how everyone's approach is different.
\n\nTAD: Yeah, that's interesting. Something that I've noticed is that it's not lack of skill; it's lack of experience, probably, that slows people down or blocks people. So when I say that, for example, I've talked to you and maybe some of the other people coming in. And if you're new coming in and you don't really have context or experience, so a lot of times you're just like, I don't know, Google, and then, I don't know, Google again. I don't know, Stack Overflow.
\n\nAnd that could take you like an hour before you get to the answer or figure out what you need to do. But if someone else who's familiar with it comes along and is like, "Oh yeah, I know exactly the documentation that you probably want to read," Or "I know exactly which library you could use to fix that or solve that problem," then suddenly, it's like, oh, [laughs] blindly searching for an hour just got replaced with 10 minutes of talking to somebody and getting a recommendation.
\n\nEDDY: I just wanted to kind of echo what you said. I think it's...I saw a video from what makes someone successful. And one of those topics was, like, reach out to someone who's in that same profession, who's been there longer. It's like a cheat code, like a shortcut. It's like, you can eventually stumble through that same problem through sweat, and agony, and blood, you know, and stress, or you can reach out to someone who's already been through that map, you know, and cut it significantly to get the answer. So why wouldn't you use someone who has run into that problem? It's like a real-life cheat code, you know.
\n\nJASON: [inaudible 35:13] was a senior developer at Acima for a long time. And I had a conversation with him once, and he oversimplified it, or he may have been facetious, but I think there's a kernel of truth in this. He said the only difference between a junior dev and a senior is how proficient they are at finding the answers that they're looking for. They learn to learn better, or they learn to find those answers or search better. There could be a number of different things, but that just came to mind as we were talking about this.
\n\nMIKE: More than a kernel of truth. It's remarkable how true that is.
\n\nTAD: Well, that's funny because what was it? Like a couple of weeks ago, you were implementing some JavaScript stuff and some marketing and tracking and things like that. And you reached out to me, and I was like, "Oh my gosh, Jason, I've got scar tissue. I've got stories. [laughs] I see you're about to step on a path that I've been down. And let me tell you, it's not pretty at the other end, but here's how it will go. And here's how you're going to get there."
\n\nThat was just kind of funny to me is that I think we all have scar tissue from some gnarly problems we've had to deal with and a story to tell, and then just like, oh yeah, I see what path you're on. [laughs] Here you go, like, good luck. And here's where you're going to end up.
\n\nJASON: Exactly as it was mentioned. It's kind of funny. What you were saying and what you were explaining to me about the problem we were encountering is exactly what was happening. And it sounds like it's just something everybody has to deal with.
\n\nMIKE: We've talked about the origin of this skills clinic idea, a lot of things we've worked on, and what has made it useful. And it sounds like, if I were to summarize what I've heard, a lot of what has made it useful is not necessarily the overt this is what we plan to talk about, but the incidental benefits of having developers work together and watch each other and learn. Of course, you can get that from pairing. There are other scenarios that that come up.
\n\nBut in skills clinic, you're actively going and looking for these new experiences that you might not encounter otherwise. From my perception, I think it's been a very valuable thing that we've done, and I would recommend that others try it. Is that a universal sentiment? Would you recommend that other companies try this idea, start up a skills clinic, you know, and start this daily pattern to improve your skills together?
\n\nTAD: Absolutely. I've learned a ton. And I've hit things that I didn't expect to hit and learned things I didn't expect to learn. And like I mentioned earlier, I kind of expected it to be me teaching them, and it's us teaching us, which was awesome.
\n\nEDDY: I wanted to say as someone who has a year under their belt as far as learning how to code, it was incremental learning until skills clinic, in which case I feel like my skill has grown exponentially, so yes.
\n\nJASON: For those concerned that it's a wasted hour every day, [laughs] you get 100 fold back out of that invested hour. It's amazing how much you can get back. Like Tad was saying, it's serendipitous that you talked about this topic incidentally on Tuesday, and Thursday, that solution came up in my actual work. And that just saved me more than the hour I invested in skills clinic. So it's this compounding effect.
\n\nMARK: I think skills clinic is very useful, at least as a coder. For other jobs, they might not do it as often or might structure it differently. But I do think implementing some sort of skill clinic session placed once a week would be good for other companies as well.
\n\nTAD: I really like the regularity that we've set up that now I know every day at 10:00 o'clock I'm going to be doing this. I think when we had alternating mornings and afternoons and only some of the days and stuff like that, we kind of lost something. But having it as a regular part of our day and having it as something to look forward to and having it blocked out so we're not having meetings on top of it and stuff like that has really made it much better.
\n\nMIKE: And maybe that's a good place to land is that if you want to make this work, you got to be consistent. You should come up with something that you can work on for a while, something out of band that you're not necessarily working on in your daily work to give people different experiences. And just be consistent about it. And we've heard some witness testimonials that it's an investment that has a high return.
\n\nThose who are listening who are in a position to try something like this, I highly recommend that you try it. And the worst thing that happens is it doesn't work out for you. But this opportunity to improve the skills of the people you work with and help everybody build them as they have and grow them and become more effective is extremely worthwhile. Thank you, everybody, for being here. Thank you to our listeners. I hope you can put this into practice. See you next time.
","summary":"We talk about something specific here at Acima with the hope that other companies will replicate our skills clinics because it's been an extremely valuable thing that we've done. ","date_published":"2023-03-15T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/c7e8b062-7586-4182-be80-1680c4a41f05.mp3","mime_type":"audio/mpeg","size_in_bytes":43870363,"duration_in_seconds":2440}]},{"id":"a40de273-aa6c-4b99-b2d5-e5c4e379e6c2","title":"Episode 12: How Can Remote Developers Fit Into a Team?","url":"https://acima-development.fireside.fm/12","content_text":"Have you been through a global pandemic recently? This episode is for you. Today we're going to talk about fitting remote developers into a team.\n\nTranscript:\n\nDAVID: Hello and good morning. Welcome to The Acima Development Podcast. Today we're going to talk about fitting remote developers into a team. And if you have not recently lived through a global pandemic, you don't need to hear anything that we have to say, so more power to you. \n\nToday we're going to talk with...I'm just going to read through the panel, and then people can speak up and shut up as they go through. But we've got Mike Challis. We've got Kyle Archer. We've got Jason Loutensock. We've got Ramses Bateman. We've got Eddy Lopez and Mark...oh, Mark, I'm going to mess up your last name, Kendzior?\n\nMARK: Pretty close, Kendzior.\n\nDAVID: All right. So remote development, what do you think?\n\nMIKE: This one is interesting to me. I have been doing remote development most of my career. At first, it was almost an accident. My wife was gravely ill while pregnant, and I wanted to be close to her. So I tried to be home as much as I could. But I was mostly working in the office at the time, like work through lunch and get home as soon as I could. \n\nAnd after my son was born, I tried to be there to do what I could as much as I could. And around the same time, the company I was working at went through some change of management. And basically, nobody that I had been working with closely previously was there anymore, so I just worked in the office less and less until I just wasn't working there anymore. And I've never really gone back. \n\nSo I've been working remotely for a long time. And so I was well-positioned for this pandemic because I was used to it more than a lot of people were. I know that, for me, being remote has a lot of obligations on the developer that is remote that you don't have as much when you're in the office. You might want me to say, oh yeah, well, there are all these things that the office needs to do to support the remote people, and that's probably a lot of what we'll talk about. And I think the opposite is very much true. \n\nIf you're remote, there are certain things that you just have to do. You have to actively be more present in ways than if you were in person because you lose all of those visual and social cues that you would have otherwise. If you're on, let's say, Slack, you need to really be available there, make sure that you're around, and you respond quickly. And then, if you're in a meeting, you maybe speak up more than you would normally do to kind of push against your instinct to sit in the back of the class. \n\nBecause if you don't push against those sorts of things, then you tend to disappear, not just to the others but even to yourself. You lose some of that social engagement. As a remote developer, the things that have been most important to me are being really proactive in that way and really making sure that I am present. And I feel like that has helped quite a bit for myself.\n\nDAVID: That is awesome. I think it's interesting that you've had kind of the opposite conversation as me. The last few times that I've done the how to fit remote devs into a team, I've come from the thing that you've just described. Like, all the previous conversations I've had have been in the context of the company kind of doesn't like remote work, so they're not going to give you an inch. It's up to you to make it work and convince the team in the company that it works. So, yeah, the last few times that I've been on this topic on a call, it is entirely been how can you fit yourself into a team when you're remote?\n\nAnd 100%, there are things that casually happen at the office that have to be explicit, and I'm going to use the word premeditated because it sounds a little bit sinister. And it certainly is conscious and a deliberate thing. There are things that, if you don't pay attention to them, they will run away from you. There are things that happen at the water cooler that nobody at the water cooler thinks is part of the regular workday. \n\nBut if you're not part of it and you find out everyone is in on this story or this joke or has heard about the upgrade that IT did to the network entirely at the water cooler [laughs], and you're the only one who can't get on the network, right? If you don't consciously and deliberately inject yourself into certain conversations, those conversations will just quietly happen far away from you, and you'll get cut off out of that information. \n\nSo I'm kind of excited to explore both sides of this, like, what can we do to be better into it as when we're remote. But also, are there some things that we can say, okay, company, we're remote now. We really need you to start doing this or stop doing that.\n\nMIKE: I think that's where we're thinking would be the biggest focus today. I don't know; we can talk about whatever you want; it's our podcast. [laughs] We conceived this idea from the company side. I think that there are some...I've read some things that other companies have said about this. And I've watched what people have done, and there are definitely some things that a company can do. And the pandemic has definitely pushed remote work forward, particularly in tech, where you've got a job that a lot of people can do remotely. \n\nI haven't looked at statistics in the last few months, but last I looked at them, a majority of people in our industry were at least somewhat remote, and that's a major change. And the companies that are not accommodating then they're losing the opportunity to have people contribute that would otherwise not just losing employees but losing a portion of the employee that they have working with them. And that's unfortunate for everyone. I've got some thoughts as to some vital things that a company should do. But I've been talking some, so I'll be quiet for a moment and see if anybody else wants to pipe in here before I say anything.\n\nJASON: I don't really have any thoughts about what the company should be doing but kind of just off-the-cuff thoughts. I find myself actually working more and maybe even feeling a little bit more anxiety about needing to be present, kind of touching on what Mike was saying how you have to be present. You have to keep your eyes on all the different channels. And recently, when I've had to go into the office, I've found it majorly distracting. \n\nAnd there's a lot to be said for social interaction that's wonderful and great for your mental health, but I've just found it's really hard to get work done because all of your co-workers want to come and say, \"Hi. I haven't seen you in a while.\" Or otherwise, maybe you see them every day, and they just want to chitchat. I just find, in general, especially with a development-type of job, I need my focus on what I'm trying to do. \n\nIt's kind of funny; I found myself working more and checking my phone even more, and being concerned about our team's projects even more simply because I'm there. I always have access. I don't have an excuse for not trying to pitch in and look.\n\nMIKE: I relate to all of that, [laughs] which is a topic for another podcast. But maintaining boundaries [laughs] is something that we should talk about sometime. You have to say, \"You know what? It's the end of my day. I need to sign off, even if that means absolutely nothing.\" If you're still sitting on the same couch or generally going to the office, you got to say, \"Okay, now I'm putting down my laptop, and I'm going to go do something else,\" because otherwise, it will just consume all of your time. \n\nDAVID: There's a really good concept that I learned years and years and years ago that was based on something a doctor told me. There was a problem with my health that was being...and I don't want to get into too much details. But what was happening is I was pushing too hard into one direction, and that was sort of setting a pendulum effect where I would swing back to the other side, and I would crash to the other side of the pendulum. So you can imagine not getting enough sleep, like staying up all night to push on a deadline, and then you swing back the next day, this pendulum effect. \n\nThe pendulum itself isn't bad. In fact, there are certain things where you need that pendulum effect. I realize this is an obscure, abstract metaphor. I'm going to make it concrete here in a sec. There are times when the pendulum can get stilled, and that's just as bad as having it swinging out of control. And for remote development, this notion that I can get up, I can take 17 steps from my bedroom to my office; I can put my butt in a seat, and I cannot move for 16 hours straight really stills a pendulum. \n\nAnd one of the ways to force that pendulum to pick up and swing again is to have a schedule to say I'm going to get to work at 8:00. I'm going to quit work at 5:00. I mean, you don't have to be rigid about it, but having a set thing of, like, I'm going to get up, and I'm going to get this done before work o'clock starts. And I'm going to do this after work. And I am; I'm going to log out. \n\nThere's a separate idea I have about being available versus being present in terms of being available on Slack and that sort of thing. But for me, my days just turned into this bland gray smear just one day after, and the days blurred together because I would work through the weekends. And there was no punctuation to my life. It was just get up, work, sleep, get up, work, sleep, get up, work, sleep. \n\nAnd then all of a sudden, I was 38, and I was like, where did my 30s go? And it was all just one big blur. And it wasn't until somebody said, You have to push yourself.\" I could have said this all very, very succinctly. If you want to sleep better at night, go exercise during the day. Swing that pendulum, push it hard in the opposite direction, and you can make it swing back on you in the other way. \n\nMIKE: So much truth there and even just that last piece. I don't sleep well unless I exercise during the day. [laughs] That's a very real aspect of my life and that schedule as well. I try to get some exercise in before work. As I mentioned before we started recording, I went out and mowed the lawn this morning. \n\nIt sounds like you thought, oh boy, that sounds awful, but that means I have sleep tonight, and [laughs] not only that, but I'm much clearer headed in the day if I get some exercise in the morning. If I do something that's not work in the period before work...and I do, I usually get up pretty early and get a lot in before my workday starts. And I feel like that makes me more effective working on this.\n\nEDDY: Mike, that's funny. I mowed my lawn earlier this week. And there was something fulfilling about putting all that cut grass in the garbage, and you're like, yeah.\n\nMIKE: [laughs] Yeah, change your pace. I know a lot of developers who are musicians, a lot of them who are gardeners. They have a hobby that's very different than software development. And I think they're kind of mutually reinforcing I need to switch that pendulum to the other side to let it swing and do something else. It's refreshing to your mind. Switching to one side and then the other allows you to go back with a cleaner head than if you just, I don't know, watch Netflix.\n\nDAVID: A slightly related tangent to that is I have found that if I can't get my head unfoggy, getting up and walking away from the desk for 10 minutes, just walk out the front door and just start walking, getting some sunlight and some fresh air and getting your quadriceps moving, largest muscle mass on the body, getting the tiniest hint of cardiovascular can really jumpstart your brain. So whenever I need about ten more IQ points to bring to a problem, I will get up and go for a walk. It's that contrast of activities that really, really helps.\n\nEDDY: And I am curious, though, coming from someone...myself, right? This job is their first experience in the remote work area. I wonder if other people experience this phenomenon to where I found that it took some discipline at first to keep myself accountable while getting my job done because suddenly, I had the liberty to get up whenever I wanted to go to the bathroom or pick up my phone suddenly because someone sent me a message. And before I knew it, I was going through YouTube videos or a Twitter feed. Also, I tend to forget to eat. So I found myself setting a reminder to, like, hey, get some food, you dummy. I'm curious if people can relate to that.\n\nDAVID: I think you just revealed both sides of that sword. It's like, sometimes, I get distracted, and I look at things that I shouldn't. And other times, I forget to eat. You have just revealed both sides of that sword, right? Your attention is going somewhere that you don't want it to go. But in both directions, there are times when you need to be taking care of yourself, and you don't because you blur over into work, and that, again, it gets into boundaries and into sharpness. And you not only have to be disciplined to focus on your work, but you have to be disciplined to focus on yourself when it's appropriate. \n\nMIKE: I have the same responsibilities that it's like, you got both sides there, [laughs] and they're related. I tend to struggle more with the forget to eat side or working too late, or checking the phone at all hours. I think, oh, okay, I got to take care of this problem. It's still on my mind. And almost reflexively, I'm checking and keeping my mind on that, which doesn't give the mind a chance to rest. \n\nBut that's really not much different than getting focused on something that's not work and letting the work slide. Both of them are about a lack of boundaries. You're cutting off your freedom a bit when you set up a schedule, like, hey, I want to be able to do whatever I want. If I have a schedule, well, that makes me work for the man, right? That's really not how it ends up working. When you set that schedule, well, you're the one who set the schedule.\n\nDAVID: Mm-hmm. You're the man. [laughs]\n\nMIKE: Exactly. You're the man or the woman. You make yourself in charge, and you're the one setting those guidelines. You're still in charge. You're just doing it consciously rather than by the seat of your pants. And if you do it consciously, you're probably going to do a better job like saying, \"This is the choice I want to make, so I'm going to make it.\" When you make that choice with foresight and thought, you're probably going to do pretty decently and set yourself up well. \n\nIf you let it slide a little bit around the edges because, you know, I feel like sleeping an extra five minutes a day or whatever it is, fine. But having those guidelines that you set for yourself is empowering. It isn't somebody taking something away from you. It's you giving yourself your best efforts at time management when you are conscious about it. And it works out. Yeah, I'd strongly encourage anybody who's doing remote work to create a schedule that they'd like to have and then follow it because it's surprisingly liberating.\n\nDAVID: That is amazing. I just had an epiphany as you were saying that. I find it endlessly fascinating that you take an office job where you are required to go to a certain place, and you're required to sit in a cubicle or in an office. You're required to get work done from this time to this time and then take a break at this time and then work from this time to this time. And we give that back to you when you're remote. \n\nYou can fudge when you show up to work. You can decide where you want to sit. You can decide how you want to work. You can decide how you allocate. You have ownership over all of these details of your job. And the first thing you lose is yourself. Isn't that interesting? All of a sudden, I'm in my office doing my work on my time, and I lose myself. That blows my mind a little tiny bit. \n\nMIKE: Yeah, it's a big discussion about freedom and what that consists of. So there is a metaphor I like to think about regarding this idea, which is semiconductor manufacturing. So the current generation of chips that they make of processors, what are they? Under three nanometers nowadays? Something unbelievably small. And if you ever see any video of those facilities where they make those chips, it's crazy. Everyone is walking around in what looks like hazmat suits, the bunny suits they have to wear, so they don't get any particles off their bodies anywhere in the building.\n\nThey'll have a building the size of a big-box store or bigger. It's all laminar flow, like, you've got fans in the floor and the ceiling that keep all the air moving vertically rather than horizontally, so no dust moves from side to side. And they get exceptionally pure crystals of exactly the right chemical makeup and slice them into these incredibly thin wafers. And then, they go through an amazingly precise photographic process to etch channels in them. \n\nAnd here's just where I'm going with all this, the level of precision that is required to make those chips is mind-boggling. And the billions of dollars in investment to build the facilities to get to that degree of precision is mind-boggling. Sometimes we perceive freedom as being able to do whatever we want, and I'm thinking here in the context of remote work. Hey, I'm remote. I can make whatever schedule I want. I can do whatever I want. \n\nAnd we think, oh, whatever we want means whatever our whims are at the moment. There is a kind of freedom that says I can do what I feel like in the moment. But the freedom that we have to do things because of those semiconductors is phenomenal. I can carry better than the Library of Alexandria in my pocket all the time. I can search all of the world's knowledge and get back results in less than a second. I can look at cat videos.\n\nThere's just this vast quantity of things, a pool of information that's available to me, not because people did whatever they felt like in the moment but because people abstained, right? Found the very exact set of steps to follow and followed it. And that precision, that resistance to moving away from the exact set of instructions, actually was incredibly empowering for the companies that make the chips but also for everybody else. \n\nTechnology is not based on doing what we want in the moment but on precision and following a very precise set of instructions. Thinking about freedom in that sense, in terms of empowerment, empowerment doesn't come from following the whims of the moment but by hard work and precision. And in that definition of freedom, you gain power. You gain the ability to do, not by removing constraints but by adding them, the very specific constraints that you have chosen.\n\nDAVID: I just closed another loop in my brain here as well that, ostensibly, the topic that we were going to talk about today...and I love it when the podcast goes slightly in a different tangent. But we had started off talking about what can companies do to help fit remote devs into a team better? And I realized that we've actually circled back around to that very answer, which is the big resistance to remote work 5-10 years ago was, well, you might just go home and sit on your thumbs and do nothing, and we have no way to watch you and that kind of thing, the whole Overwatch Overlord kind of thing, which isn't great. \n\nBut when you're remote, I definitely feel this pressure to...I got to get stuff done; I got to get stuff done; I got to get stuff done. And every time I think about my output at work, I think about it in a very static way of like, oh, I only moved two tickets today, or I only moved this much work, or I only did this much work. And so anytime I think about what do I need to do at work when I'm at home, it is, oh, I got to do work which, again, is a very low contrast kind of idea. It's just, oh, just push on this. \n\nIf I take the time to step away from the computer, get some contrast, go for a walk, get some oxygen, do these things that I don't like doing...I'm not an exercise-loving person. I'm wildly sedentary. What can an employer do to help fit remote devs? I think it might be to remind and encourage those remote devs to get some contrast in your life. Maybe the best thing you can do to move this project forward is log out and go to bed. Get your head down; get eight hours of sleep under your pillow. \n\nStep away from the computer. Go for a walk, go eat lunch, go out to lunch. Get away from your house and go out to lunch. Rather than just sitting down and saying, \"Well, the Jira burndown chart shows that you've only moved 17 points of velocity in the last two sprints,\" or whatever. Instead of just making everything homogenous and uniform, encourage contrast, both in and out of work. \n\nMIKE: I like your references to the contrast. Keep your life colorful. That seems like good advice, not just remote work but in general. [laughs] It sounds like the kind of job you'd want to have, colorful rather than dull.\n\nDAVID: And maybe that's not for everybody. My wife and I have wildly different personalities that complement each other very well. She kind of keeps me anchored, and steady, and stable. And I'm the creative, flighty, occasionally disastrously non-foresight having. [laughs] I'm the dangerous one in the marriage. But she likes things with regularity. She was studying to be an accountant when we got married, and, I mean, that was about as much adventure as she wanted to have in her life was adding and subtracting numbers all day. Like, that's her idea of a good time, and, for me, it's mind-numbing. It's terrifying. \n\nI say this because there are people who may be listening to this podcast who are listening to our stories of get contrasts, do these wildly disparate things. And you may be thinking, I don't want to do that, and that's fine. You don't have to do that. Do what you want to do. The whole point is to choose for yourself what is going to make you effective and happy.\n\nMIKE: And if you've been spending all day adding, maybe you can spend some time subtracting.\n\nDAVID: That's right. That's right. That big multiply and divide, whoa, whoa, whoa, let's not get crazy. Let's not get crazy. [laughs]\n\nEDDY: I actually have a question; for those who have found comfort in working remote now, would you ever consider going back into the office?\n\nMIKE: I think I'm the most remote person here, and I'd definitely consider it. Yeah, I enjoy interacting with my colleagues. The biggest downside, to me, to being in the office is probably the commute. There are distractions as well. But the commute takes some time every day. I have other reasons in that I live nowhere near the office. [laughs] And it's non-trivial for me to move for various reasons. But I would definitely consider it. I have no particular animosity toward the office.\n\nDAVID: I hung out my shingle. We had a big tech recession in 2002 out here in Utah, and I got laid off from a government contracting job, and I hung out my shingle to do development. And I ended up landing a temporary gig, and then a remote gig, and then another temporary in-office gig. And I cycled. I would work from home for three months, then I would work in an office for six, and then I would work from home for nine months, then I'd worked in an office for four weeks. \n\nAnd for me, it's all blurred together. Like, I have habits that I have learned to adopt, and it's just like changing your code. If it's raining, you put on your raincoat. If it's sunny, you put on a short-sleeved t-shirt. And there are certain habits that I have developed for in-office that I can't do when I'm at home. And there are certain habits that I have to adopt at home to be productive, habits that I cannot use when I'm in the office. And no, it's not just the whole wearing pants today. That's the standard joke about remote, right? \n\nIt's things like I don't have to be as conscious about socializing. I'm a naturally gregarious person. I like other people. Ironically, I'm an introvert. I don't seek people to recharge. But I'm a naturally gregarious person. So when I'm in the office, ironically, I actually have to check myself a little bit so that I don't end up being the distraction for everyone around me because I love being that guy. And when I'm at home, I don't have to worry about that. \n\nBut when I've been home long enough, you have to start seeking people out, or else you start going funny around the edges. You realize I have not stepped outside the front door of my house. And then you realize that your answer is the name of a month instead of hours. So, to answer your question, Eddy, yes, I absolutely would consider going back. I enjoy going back. \n\nIt's kind of like saying, you've been eating brownies. Would you ever consider going back and eating salad? And the answer is if you've eaten nothing but brownies for 18 months, you start gasping for salads. You're like; please give me a green vegetable. Please give me something with some structure and some fiber. And that, for me, is switching environments. There's definitely a sense of, like, if you're trapped in an office or if you don't know what it's like to get away from the office, you can be like, ah, I really, really want to try the greener grass on the other side of the fence. And it certainly...a change is great. And the grass is greener on both sides of the fence. \n\nBut having hopped the fence multiple, multiple times over my career, especially when I was freelancing, I had some customers who wanted me to freelance at their site and other customers who wanted me to freelance at home. So yeah, I've switched back and forth enough that, for me, it's just a change of wallpaper. There are coworkers in my wallpaper sometimes, not a sentence I thought I would say when I woke up this morning. \n\nEDDY: I think I'm a little bit more on the other side of the fence. I wouldn't push back per se on going into the office, but I'm very comfortable with being remote right now. And I'm actually making plans to strive more in that direction rather than plans I'll ever have to go back, you know, just kind of got into my routines. It's definitely...I think I would look for the benefits companies that provide that remote work as a benefit type thing.\n\nJASON: It's kind of funny. Anecdotally, my father in law in the pandemic...he's a very sociable person. When the pandemic hit, he was forced to work from home and was miserable. He was palpably irritable, just did not like it. He's one of those people who's got to be around other people. And I know a lot of people do this, but he, I mean, he already had a home office setup. But he went out and rented a space. We all kind of pitched him and helped move his office over so that he could still have a place where he could be...and he was still isolated and was as responsible as he could be with going through the pandemic. \n\nBut now it's kind of funny. He's since switched companies, and that kind of broadened his horizons. He has his own office now, and he ended up taking a remote job and still has that external office. He needs to get out and drive and get out. And I think it's for that mental health reason, you know, you need to contrast.\n\nDAVID: Kind of a best-of-both-worlds situation. \n\nJASON: Yeah, absolutely.\n\nDAVID: Which, I mean, if you do it badly, you could turn it into the worst of both worlds, right? You could end up with a long commute to an office where you're lonely anyway. So yeah, if you do pick a co-working space, pick one that's close by. [laughs]\n\nMARK: Yeah, I think for me, so I'm kind of like Dave. I've had both types of jobs. But I think over the last couple of years, where you've just been at home, it's still nice to go to the office, but I like the ability to do both, so combined. And I don't really push one way or the other. I do feel when I do go to the office, because it's not very often, it's a lot of catching up and talking, so I don't get a whole lot done at all. Then I go home and work for a couple of hours just to get some work done. \n\nSo if that's more consistent, I think that wouldn't happen as much. But I definitely like the ability to work from home. I got a dedicated office at home. I go in. I still kind of try to do, like you guys talked about, my same routine. I get up in the morning. I get ready for work, and it's ten steps down the hallway. And for me, it's not a commute. I'm five minutes from the office. So I don't have that excuse that it's a long way to get in there, but definitely like the ability to do both for sure.\n\nDAVID: You just said something, Mark, that really hooked my ear there. What you said was you go into the office, and you don't feel like...you're socializing, and you don't feel like you get much work done. And, yes, in terms of advancing the project and meeting the deadline, that kind of work doesn't get done. \n\nAll the side things that we do that support work that are work-adjacent, like socializing with your co-workers, that might not happen if you're full-time remote. You do end up getting those things done when you're in the office. It doesn't come up in your performance reviews like, well, 20% of your raise is based on how much time you spent at the water cooler and how contributing you were to the conversation. That doesn't happen. But I think it's really, really interesting. \n\nI had an event recently where I said something that was accidentally offensive to someone else in the conversation. And the timing of me saying it and the way I said it made it sound like I was intentionally trying to mock this person. And fortunately, I had spent enough time...I had not spent enough time with that person for them to know that I was completely not trying to embarrass them. I was not trying to point a joke at them. It was literally there were two completely different ways to interpret what I said. And I didn't realize that the offensive context even existed. \n\nAnd they kind of took it as like, oh, that was intentional, or maybe you deliberately set up the double entendre because I use those in my humor all the time. So it sounded like I was setting it up. Fortunately, there were people in the room who went, \"Dave.\" And I'm like, \"What?\" And they're like, \"Did you...\" And I went, \"Oh my gosh, no, no,\" and I was able to back it out. But if I had not had socialization time with the other people in the room, they would have run me out of the group. And I think I would have deserved it, I mean, not in terms of my intention but in what I had done. \n\nAnd all of that was due to time spent not doing work with these people but instead bonding and gelling with them and getting to know them and them getting to know my sense of humor. And also to know, I'm not super proud of this, but I will tell a joke with dirty words in it, and I will tell filthy jokes, not at work. But I don't like to tell jokes that are mean to people. And even if they're perfectly clean, I don't like to tell mean jokes. \n\nAnd the double entendre that I made was mean in its other interpretation, and there were people in the room who went, \"That's not Dave. Dave did not mean to say that.\" So they grabbed me by the ear and said, \"Stop that. You need to go say you're sorry. Don't ask why. Just go say you're sorry.\" I'm like, \"Okay.\" Sorry, that's kind of a weird tangent. \n\nBut what you said, sometimes we go to the office...what I would say is it's not that you're not getting work done, it's that you are doing different work-adjacent things. And when we work from home, there are other work-adjacent things that we can do. We can refill our emotional batteries by having access to our families or by being able to take the dog for a walk that we don't get when we're in the office, especially if we've got, you know, your commute is what? Like three and a half days if you jump in the car and head west?\n\nMIKE: Right there. [laughs]\n\nDAVID: Yeah. So, I don't know; I guess what it is is there's a contrast at work that is imposed. But there are other activities that we think of as, like, this is not part of the work. It's not officially part of your job description to get along with people and contribute. But it certainly shapes the direction of your career if you know how to socialize with people, if you know how to interact with people. \n\nMIKE: Well, I would take that a little further. One of the things that I've seen be very effective at fostering remote teams is actively scheduling time, scheduling time to do, I would say, non-productive but to do things that don't create code [laughs] but are just there for social interaction. On our team, we've talked to some leadership about how to do this, actively been looking. What are some things we can do to let people have some fun together? \n\nAnd that sounds maybe like a very forced way of making people feel like [laughs] it's a good place to work. That's really not the purpose. I mean, sure, we want it to be a more fun place to work. But, you know, if you want to go play games, you could do that at home too. Sometimes you got to have fun together because that actually has some real social utility. You get to know each other better and to trust each other sometimes by activities that are not just coding, and you have to make space for that. \n\nNow, what that looks like for different people may be very different. There's a range of things that people may find appealing, and maybe some of the activities you do aren't what everybody would consider as fun. [laughs] It may feel like work. But that doesn't mean it doesn't have utility and value. Having every person on your team tell some interesting story about their background or playing some sort of group game together, not everybody enjoys those things. \n\nBeing put on the spotlight to tell something, and maybe you have a very troubled history, and that's very difficult for you. You don't want to put somebody in a really bad position, and so you talk to them first. But it's a level of uncomfortable and not painful, that's still uncomfortable. It may not even be pleasant. You may not be doing it for fun, per se, but it still provides value to the team. \n\nDAVID: Yeah, finding that line between what is normal and safe versus what is slightly risky versus what is [laughs] way over the line, finding that. Having something that is just slightly risky or slightly vulnerable that you can share and if your team reciprocates that with empathy and compassion, that is a great bonding experience. If you never share that, your relationship will be kind of...I think antiseptic is the right word there. It's a little bit of wordplay, but it's completely true. If your work environment is emotionally antiseptic, you can never grow a culture.\n\nJASON: Yeah, I know some of the social things that we've done on the Atlas team was, I don't know, a couple of weeks ago; I don't quite recall. We played a round of Codewords and just getting to know some of the interns that we had. And hearing them in kind of a new light and getting to socialize outside of the context of here's an answer to your question or some strictly informative conversation was fun. Like Michael Webster, one of our interns, he's hilarious. \n\nI wouldn't have gotten to hear or understand some of the humor and jokes if we hadn't been socializing. And that's fun just to reach out and talk if you need something. It really kind of opens things up, makes things easier to even reach out to people in general when you have that social context or kind of friendship context.\n\nDAVID: Absolutely. When you have a problem that might not be important...I shared a story before the call. I won't go into all the details. But TL;DR, I was having a problem that everyone else was having and was minimizing. And it was really making me crazy. And I finally compared it to someone else, and they went, \"Oh my gosh, you have a terrible problem. Go take care of this.\" And because I knew somebody in the IT department, it was so much easier to just reach out and say, \"Hey, Mike, what's going on with this?\" \n\nAnd to ask them is this, you know because this might be a low-priority thing. I don't want to go to the help desk. I don't want to open a ticket. I don't want to have, you know, full tracking on this. And he looked at that and went, \"Oh yeah, that's serious, go open a help ticket. And I will jump on it for you.\" And I'm like, cool, we can follow the process and also have that monitoring and meeting. \n\nSorry to dovetail two stories back to back, but there's a pattern that's emerging from what we're talking about. We're all talking about time that we have spent in kind of play meetings as remote developers, which meant we had to make an appointment with each other. We had to schedule some mandatory fun, which just sounds like a death march, doesn't it? Doesn't it just sound terrible? \n\nBut my boss, Zack, isn't here today, so I can talk a story behind his back here a little bit. He invited me to come work on the data team. And he said, \"We've got a really, really great team.\" And I said, \"Great,\" and I came, and I joined the team. Now, we're coming off the back of the pandemic, and we're all full-time remote. And I dove into the data stuff that we needed to learn. And then, three months later, I realized I'd still not met anybody on my team. \n\nAnd I had kind of a one-on-one with...not kind of I had a one-on-one with Zack. And I said, \"You keep telling me this team is really great, but I've never met them.\" And the next day, there was an appointment on the calendar. For every other Wednesday for an hour, we're going to get together and just play games. And so I've been able to meet with my co-workers and hang out and tell stories. And find out, you know, some teams everything is straight-laced and starched collars, and other teams are, you know, the humor is very colorful. And I'm getting to find out what colors of humor are okay on this team. And it's been super, super, incredibly awesome. \n\nSo what I would say to any employer that's trying to figure out how do I grow a culture when everybody's remote, and we're unintentionally pouring, you know, antiseptic on places where we were growing culture, schedule some time. Don't make it mandatory. If somebody's pushing a deadline, don't force them to stress out about their job by putting down getting work done to go to some stupid meeting where people are going to joke around and shoot the BS when I really need to get, you know, don't make me do that. \n\nBut if you do say this is a meeting and if you come, you get credit for being at work, and you don't have to do work, right? We all, you know, sometimes like to take a fun break like that. Because he scheduled that time, I've been able to hang out with my co-workers. I'd still like to hang out with them a lot more, but I've now actually met them. I could tell you their names without [laughs] having to look up an org chart. So that would be my advice (Way too long of a story.), but yeah, schedule some time. Don't make it mandatory but make it fun enough. Make it attractive to people to want to come to the somewhat mandatory fun.\n\nJASON: I think that's huge that you said, \"Don't make it mandatory.\" I was going to say that that's a key component, in my opinion, of making it fun is they are there...people are participating because they want to be there and can be there. And they've never been mandatory, and I've never felt like they were mandatory. And most of the time, I haven't attended because there were other things that were going on. But knowing that it was there and the opportunity I always want to now, especially the last couple that we've done, it's been fun to be a part of, you know, if you can make it.\n\nDAVID: I worked at a shop way too long ago, gosh, 1999, I think. They had a thing called beat burnout. And the fact that we needed it was a solid demonstration that they were...it was in the video game industry. We were working 100-hour weeks, except for when they wanted us to work more. [chuckles] And they would have beat burnout. And they would do big things. They were always off-site. We would rent out a movie theater and then go to dinner at a nice restaurant or go to lunch at a nice restaurant. \n\nAnd we'd rent out the room at the place. Every summer, they would rent out the amusement park. There's an amusement park near here that is very expensive to go to. It's taking you and your wife and go to this thing is going to be, you know, or you and your partner and go to this thing it's going to be 100 bucks to go do that. And they're like, \"No, you get in for free. We're going to run a tab at this restaurant inside the park. We're going to run a tab at this cafeteria where you can get snacks.\" Go have fun, and you get an all-access ride pass. And that was fantastic. It was really, really cool. \n\nAnd I was way behind on a major deadline that was going to cost me my job, [laughs] so I stayed at home, and I worked through it. And there were a couple of other co-workers who also stayed at home because they don't like amusement parks. And they didn't show up at the office, and they got reprimanded. And we got an official note from the CEO saying, \"If you are not at beat burnout, you must be at your desk working.\" And attendance at beat burnout fell through the floor. \n\nEven though they were doing great, fun things, after that, people were like, \"Screw you, guys. I don't want to play this game.\" I do not want to be handcuffed to the roller coaster, which in this case is a literal roller coaster at an actual amusement park where you're supposed to be having fun. \n\nEDDY: Basically, all I've gathered from talking to you guys [laughs] is that people can be less productive while in the office. So my question is, how the heck were any of you guys getting the job done before the pandemic?\n\nDAVID: Oh, I wasn't. I wasn't.\n\nEDDY: [laughs]\n\nDAVID: The reason I had so many jobs is I'd go to a place, I get fired. No, I'm kidding. I'm kidding. It's different work, right? It's a different way of approaching. When I go into the office, I don't have to structure my day anymore because I have to be there at a certain time. That means I've got to get up at a certain time, take a shower, get dressed, eat some breakfast. I've got to commute at a certain time. And that structures out my day. Lunchtime is a certain hour; go home at a certain hour. And that gives me some of that necessary structure to my day, some of that necessary contrast to my day. \n\nBut when I work from home, there's this wonderful thing where sometimes the structure has sharp corners, and that corner is going to gouge straight out of my eyeball. Instead of supporting me and giving me a framework to support my day, it's an overhead beam that I smack my head on. And it's just emotionally taxing, and it takes ten times as much emotional energy to be present during this particular hour of the day where if I was at home, I could...you know what? I really need to just go take a nap. And I can't do that in the office, that kind of thing. \n\nSo knowing what things you have to build for yourself in each environment is crucial. Knowing what things can support you in each environment is crucial. And they are different things, and you can be productive. There's a book called \"Peopleware\" and a software called Peopleware and a company called PeopleSoft, I think. But there's an old, old book...I can't remember the names of the authors. But the book is called \"Peopleware.\" DeMarco and Lister, I think, might be the authors. They wrote this book in the '90s, and it was all about how to be productive, how to manage people in a technological environment. \n\nAnd their premise was technology does not solve any people problems. It doesn't solve any human problems. It just makes them happen faster. And there's just one sentence...they were walking through studying this great big cube farm. And the boss was giving them a tour of the place, and he was saying, \"I like having everybody here in the cube farm,\" and they had low-walled cubicles. \"I like the low-walled cubicles because I can look out over and I can see who's working and I can see who's not because I've got to stay on top of these people to keep them busy and keep them focused and on task.\" \n\nAnd as they walked, they noticed...they looked into one of the conference rooms, and there was an engineer in the conference room with papers strewn. This was before laptops. This was in the '90s or '80s, sorry. He had papers strewn all across the conference table and was poring over them intently. They took note of it, and they continued to tour. They dropped the CEO back in his office and said, \"If you don't mind, we'd like to tour your office unsupervised.\" And he said, \"Sure, go on. I got nothing to hide.\" \n\nAnd they went straight back to the conference room. And they poked their heads, and they said, \"Sorry for disturbing you, but why are you in the conference room?\" And he looked up, and he said, \"Oh, I'm hiding in here.\" And they're like, \"Why are you hiding in here?\" And he said, \"So I can get some work done.\" And that became kind of the spark for these guys to go write this book because they realized there's this boss who thinks all of his employees are lazy and distractible and work-shy peasants kind of thing. \n\nIf that's true, why does he have people that are sneaking off to quiet rooms so they can get work done? Maybe we need to think about work in terms of maybe employees actually want to get work done. Maybe if we want to accomplish things in whichever environment you're in, we need to empower that and make that happen. So that was kind of a long, wild, rambly tangent. I highly recommend the \"Peopleware\" book if you haven't heard of that or haven't read it. \n\nTo give you an idea of how...I want to use the phrase eternal truth. [laughs] It's a phrase of, like, how long-lasting their advice and how evergreen their advice is. They wrote the book before the internet existed. And when the internet came out, they went back to them and said, \"Okay, okay, you studied those people without computers in their offices and all these things. Now that the internet is here, we need a version 2.0 of the book that changes all the things that you've learned about how people are productive and how they think and how they work.\" \n\nAnd they went back and went through their book, and they compared everything to the internet age. And they added half a chapter on dealing with the distraction of email. And they said, \"Other than that, the internet has done nothing to the things that we said back in the '80s. People want to get work done. And if you throw technology at them, it just distracts them,\" which I thought was fantastic and fascinating.\n\nKYLE: I'd like to throw my two cents on Eddy's question too.\n\nDAVID: Please do.\n\nKYLE: What I've kind of noticed is when I was in the office, I would get work done, but there was the quote, unquote, \"water cooler time.\" And this kind of goes back to Mark's concern when he goes in the office. I think, yeah, I do get more work done when I'm at home. But I think that water cooler time you'd have everyday kind of builds up to where if you're going in every once in a while, it appears as though you're not getting anything done in the office because all that water cooler time has built up, and you're getting it done in that day or in the few days that you are there that would normally naturally just be getting done day by day if you were there in the office every day. \n\nI've also seen, too, a lot of the older offices don't have them, at least from my experience. But the newer offices, like when I was at InsideSales or the new building that we went to at Acima, they've got these isolated self-cube rooms. I'm not sure what to call them, like, solo conference rooms or whatever. And part of those, at least from my understanding, is if you need to get away, if you need to be isolated, you can go into those rooms and work, and those are there for a reason because there are distractions in an office. You need somewhere where you can just go and be heads down.\n\nAnd I think that's just a trend that has kind of taken off in the technology space. I don't know how common that is in a normal office environment outside of technology, but I've definitely had to use those a few times just to, okay, I need somewhere where I can't be distracted, which is something I don't need at home. I can just close my door, and nobody comes and bugs me.\n\nDAVID: I've worked at a couple of shops where they moved to an open floor plan or what, agile with a lowercase a, what agile refers to as a bullpen environment. And the idea in the bullpen is to make it so that everybody overhears everything because it's valuable. It's like, \"Oh, man, I can't connect to the database. Can you connect to the database?\" And somebody two seats over goes, \"Oh yeah, they changed the connector from eight-bit to seven-bit. Turn on parity, and you'll be fine.\" \n\nThere's like this side-channel thing. And they just saved you three hours of debugging, and it's fantastic. The problem is that you're trying to solve this problem that's like seven layers of recursion deep. And the person three chairs down says they can't connect to the database. And you know the answer, so you're going to tell them. Well, you just got distracted. \n\nAnd in places that have bullpens, the chief complaint is you don't have any place where you can go to think, and especially you don't have any place where you can take a phone call without disrupting everybody around you. And so what I've seen are open floor plans with little three-foot by three-foot or four-foot by four-foot cubicles. They have a door. They have a big, tall window so you can see if it's occupied. And it's just enough space for a laptop and for you to put a sheet of paper next...and it's tiny. It's a tiny, tiny room. There are no monitors in there. \n\nBut notably, there's also acoustic foam on the walls so that if you want to take a phone call or if you want to jump on a podcast with somebody and you're in the middle of a bullpen, you can go to the privacy rooms, booths, really like little phone booths all along the side. I thought that was a fantastic way to make it so that you could elect whether you wanted zero distractions for an hour or whether you wanted to take a phone call without distracting your neighbors. I thought that was a neat way to deal with that.\n\nJASON: It's kind of funny how ironic that is that you build offices to get people into the office to work so they won't be distracted, and now we have to build sub-offices essentially where people can go to be alone and work.\n\nDAVID: [laughs] Was it George Carlin that did the joke about humans didn't like it was cold, so they built a box to live in where it was warm? And then their food went bad, so they built a box inside the box to keep things cold. And then, the butter kept getting too hard, so they built a box inside the box inside the box to keep the butter warm. Those booths are basically the butter dishes of our office complex. [laughs]\n\nJASON: True.\n\nKYLE: And I've always thought the idea of a bullpen was kind of funny because you build the bullpens so that the communication can be heard, and then they complain about it being too noisy. And, at this point, I've never been in a bullpen that hasn't had a white noise generator.\n\nDAVID: Oh.\n\nJASON: Well, you and me were both in sales, Kyle. And it's funny because you have everybody in that environment, and you have merchants who are getting this or retailers rather that we work with who get some background noise. So it's kind of funny. I'm sure that's changed since the office is larger and you have those white noise generators. It's kind of ironic, I guess. \n\nDAVID: I will say that in my experience, bullpens don't work well once you've got more than about ten people in it, also, if it's a focused team. If you've got 30 people in a room, and you've got the IT team, and you've got the sales team, and you've got the engineering team all working in the same room, then the things that you're overhearing have nothing to do with your job, and they're just pure distraction. \n\nI believe that white noise generators are of the devil. They're just the most evil thing in the world. The auditory processors in your brain cannot shut off. And any species that shuts off their auditory processors while they sleep are now extinct because they get eaten in their sleep, and humans are no different. That part of your brain never ever shuts off. And so if you put on white noise to sleep or put on a fan to sleep, it doesn't give you as restful sleep as having total silence. \n\nAnd trying to think about an engineering problem...I have ADD. I love having music on. I love having people to talk to. I love having stuff. And I had to train myself to sit in silence, and when I did, I noticed I had an extra 40 horsepower in the brain engine compartment. That's a weird metaphor. You can think better when you free up those neurons. If you have an open bullpen to encourage communication, and then you turn on a white noise generator to jam communication, fire your floor planner, please. Just, yeah, give people offices at that point; give them silence when they crave it.\n\nMIKE: So, as we're finishing here, I'm noticing a recurring theme about being deliberate about things, scheduling time, creating spaces to do things. And this applies not just to remote work but in-person work. And it's been about the need to have some structure that it's...I'm going to say mandatory, but it is not the best word for it. If you want to be successful, you need a surprising amount of structure. And it can be completely and probably should be self-imposed. But you're making that choice for yourself so that you can be effective.\n\nDAVID: Absolutely. When I try to schedule my exercise, I hate doing that. So I look at it from the thing of, like, I want to fill up this bucket with this much quantity of exercise over this amount of time, which makes it nice because now if I fall down the rabbit hole and I start chasing this really interesting problem at work and all of a sudden I accidentally seven hours, I don't feel like, oh, I missed my workout time. It's like, oh, no, I wanted to do some walking today, and I've got a minute now. I'll go for a walk. \n\nAnd at the end of the week, if I haven't done much walking that week, I can say I need to do more walking this week. That's my way as a very fluid kind of eclectic person of saying I'm going to own my schedule because I can say I want to put this in my schedule, and I want to get it done. But I don't actually need to make an appointment for it. And if somebody else makes an appointment for something to happen, I absolutely am going to resist that because of just the way my ego works.\n\nMIKE: Either way, though, you did set some time aside to yourself. You did it in the way --\n\nDAVID: Yeah, yeah. I am 100% agreeing with you that what we're touching on here is owning the schedule, and owning your life, owning your career, owning what you do in a day, 100% agree, yes.\n\nJASON: Can say I love how Acima has done things, kind of putting the ownership on the engineer and the employee.\n\nDAVID: Yeah, trusting people to get it done, and then people get it done. And it feels great. Well, fantastic. Ramses had to drop off a minute early. But Kyle, Jason, Eddy, Mark, Mike, thank you so much for coming. This was a lot of fun. And I'm looking forward to our next episode. And we'll see you guys soon.","content_html":"Have you been through a global pandemic recently? This episode is for you. Today we're going to talk about fitting remote developers into a team.
\n\nTranscript:
\n\nDAVID: Hello and good morning. Welcome to The Acima Development Podcast. Today we're going to talk about fitting remote developers into a team. And if you have not recently lived through a global pandemic, you don't need to hear anything that we have to say, so more power to you.
\n\nToday we're going to talk with...I'm just going to read through the panel, and then people can speak up and shut up as they go through. But we've got Mike Challis. We've got Kyle Archer. We've got Jason Loutensock. We've got Ramses Bateman. We've got Eddy Lopez and Mark...oh, Mark, I'm going to mess up your last name, Kendzior?
\n\nMARK: Pretty close, Kendzior.
\n\nDAVID: All right. So remote development, what do you think?
\n\nMIKE: This one is interesting to me. I have been doing remote development most of my career. At first, it was almost an accident. My wife was gravely ill while pregnant, and I wanted to be close to her. So I tried to be home as much as I could. But I was mostly working in the office at the time, like work through lunch and get home as soon as I could.
\n\nAnd after my son was born, I tried to be there to do what I could as much as I could. And around the same time, the company I was working at went through some change of management. And basically, nobody that I had been working with closely previously was there anymore, so I just worked in the office less and less until I just wasn't working there anymore. And I've never really gone back.
\n\nSo I've been working remotely for a long time. And so I was well-positioned for this pandemic because I was used to it more than a lot of people were. I know that, for me, being remote has a lot of obligations on the developer that is remote that you don't have as much when you're in the office. You might want me to say, oh yeah, well, there are all these things that the office needs to do to support the remote people, and that's probably a lot of what we'll talk about. And I think the opposite is very much true.
\n\nIf you're remote, there are certain things that you just have to do. You have to actively be more present in ways than if you were in person because you lose all of those visual and social cues that you would have otherwise. If you're on, let's say, Slack, you need to really be available there, make sure that you're around, and you respond quickly. And then, if you're in a meeting, you maybe speak up more than you would normally do to kind of push against your instinct to sit in the back of the class.
\n\nBecause if you don't push against those sorts of things, then you tend to disappear, not just to the others but even to yourself. You lose some of that social engagement. As a remote developer, the things that have been most important to me are being really proactive in that way and really making sure that I am present. And I feel like that has helped quite a bit for myself.
\n\nDAVID: That is awesome. I think it's interesting that you've had kind of the opposite conversation as me. The last few times that I've done the how to fit remote devs into a team, I've come from the thing that you've just described. Like, all the previous conversations I've had have been in the context of the company kind of doesn't like remote work, so they're not going to give you an inch. It's up to you to make it work and convince the team in the company that it works. So, yeah, the last few times that I've been on this topic on a call, it is entirely been how can you fit yourself into a team when you're remote?
\n\nAnd 100%, there are things that casually happen at the office that have to be explicit, and I'm going to use the word premeditated because it sounds a little bit sinister. And it certainly is conscious and a deliberate thing. There are things that, if you don't pay attention to them, they will run away from you. There are things that happen at the water cooler that nobody at the water cooler thinks is part of the regular workday.
\n\nBut if you're not part of it and you find out everyone is in on this story or this joke or has heard about the upgrade that IT did to the network entirely at the water cooler [laughs], and you're the only one who can't get on the network, right? If you don't consciously and deliberately inject yourself into certain conversations, those conversations will just quietly happen far away from you, and you'll get cut off out of that information.
\n\nSo I'm kind of excited to explore both sides of this, like, what can we do to be better into it as when we're remote. But also, are there some things that we can say, okay, company, we're remote now. We really need you to start doing this or stop doing that.
\n\nMIKE: I think that's where we're thinking would be the biggest focus today. I don't know; we can talk about whatever you want; it's our podcast. [laughs] We conceived this idea from the company side. I think that there are some...I've read some things that other companies have said about this. And I've watched what people have done, and there are definitely some things that a company can do. And the pandemic has definitely pushed remote work forward, particularly in tech, where you've got a job that a lot of people can do remotely.
\n\nI haven't looked at statistics in the last few months, but last I looked at them, a majority of people in our industry were at least somewhat remote, and that's a major change. And the companies that are not accommodating then they're losing the opportunity to have people contribute that would otherwise not just losing employees but losing a portion of the employee that they have working with them. And that's unfortunate for everyone. I've got some thoughts as to some vital things that a company should do. But I've been talking some, so I'll be quiet for a moment and see if anybody else wants to pipe in here before I say anything.
\n\nJASON: I don't really have any thoughts about what the company should be doing but kind of just off-the-cuff thoughts. I find myself actually working more and maybe even feeling a little bit more anxiety about needing to be present, kind of touching on what Mike was saying how you have to be present. You have to keep your eyes on all the different channels. And recently, when I've had to go into the office, I've found it majorly distracting.
\n\nAnd there's a lot to be said for social interaction that's wonderful and great for your mental health, but I've just found it's really hard to get work done because all of your co-workers want to come and say, "Hi. I haven't seen you in a while." Or otherwise, maybe you see them every day, and they just want to chitchat. I just find, in general, especially with a development-type of job, I need my focus on what I'm trying to do.
\n\nIt's kind of funny; I found myself working more and checking my phone even more, and being concerned about our team's projects even more simply because I'm there. I always have access. I don't have an excuse for not trying to pitch in and look.
\n\nMIKE: I relate to all of that, [laughs] which is a topic for another podcast. But maintaining boundaries [laughs] is something that we should talk about sometime. You have to say, "You know what? It's the end of my day. I need to sign off, even if that means absolutely nothing." If you're still sitting on the same couch or generally going to the office, you got to say, "Okay, now I'm putting down my laptop, and I'm going to go do something else," because otherwise, it will just consume all of your time.
\n\nDAVID: There's a really good concept that I learned years and years and years ago that was based on something a doctor told me. There was a problem with my health that was being...and I don't want to get into too much details. But what was happening is I was pushing too hard into one direction, and that was sort of setting a pendulum effect where I would swing back to the other side, and I would crash to the other side of the pendulum. So you can imagine not getting enough sleep, like staying up all night to push on a deadline, and then you swing back the next day, this pendulum effect.
\n\nThe pendulum itself isn't bad. In fact, there are certain things where you need that pendulum effect. I realize this is an obscure, abstract metaphor. I'm going to make it concrete here in a sec. There are times when the pendulum can get stilled, and that's just as bad as having it swinging out of control. And for remote development, this notion that I can get up, I can take 17 steps from my bedroom to my office; I can put my butt in a seat, and I cannot move for 16 hours straight really stills a pendulum.
\n\nAnd one of the ways to force that pendulum to pick up and swing again is to have a schedule to say I'm going to get to work at 8:00. I'm going to quit work at 5:00. I mean, you don't have to be rigid about it, but having a set thing of, like, I'm going to get up, and I'm going to get this done before work o'clock starts. And I'm going to do this after work. And I am; I'm going to log out.
\n\nThere's a separate idea I have about being available versus being present in terms of being available on Slack and that sort of thing. But for me, my days just turned into this bland gray smear just one day after, and the days blurred together because I would work through the weekends. And there was no punctuation to my life. It was just get up, work, sleep, get up, work, sleep, get up, work, sleep.
\n\nAnd then all of a sudden, I was 38, and I was like, where did my 30s go? And it was all just one big blur. And it wasn't until somebody said, You have to push yourself." I could have said this all very, very succinctly. If you want to sleep better at night, go exercise during the day. Swing that pendulum, push it hard in the opposite direction, and you can make it swing back on you in the other way.
\n\nMIKE: So much truth there and even just that last piece. I don't sleep well unless I exercise during the day. [laughs] That's a very real aspect of my life and that schedule as well. I try to get some exercise in before work. As I mentioned before we started recording, I went out and mowed the lawn this morning.
\n\nIt sounds like you thought, oh boy, that sounds awful, but that means I have sleep tonight, and [laughs] not only that, but I'm much clearer headed in the day if I get some exercise in the morning. If I do something that's not work in the period before work...and I do, I usually get up pretty early and get a lot in before my workday starts. And I feel like that makes me more effective working on this.
\n\nEDDY: Mike, that's funny. I mowed my lawn earlier this week. And there was something fulfilling about putting all that cut grass in the garbage, and you're like, yeah.
\n\nMIKE: [laughs] Yeah, change your pace. I know a lot of developers who are musicians, a lot of them who are gardeners. They have a hobby that's very different than software development. And I think they're kind of mutually reinforcing I need to switch that pendulum to the other side to let it swing and do something else. It's refreshing to your mind. Switching to one side and then the other allows you to go back with a cleaner head than if you just, I don't know, watch Netflix.
\n\nDAVID: A slightly related tangent to that is I have found that if I can't get my head unfoggy, getting up and walking away from the desk for 10 minutes, just walk out the front door and just start walking, getting some sunlight and some fresh air and getting your quadriceps moving, largest muscle mass on the body, getting the tiniest hint of cardiovascular can really jumpstart your brain. So whenever I need about ten more IQ points to bring to a problem, I will get up and go for a walk. It's that contrast of activities that really, really helps.
\n\nEDDY: And I am curious, though, coming from someone...myself, right? This job is their first experience in the remote work area. I wonder if other people experience this phenomenon to where I found that it took some discipline at first to keep myself accountable while getting my job done because suddenly, I had the liberty to get up whenever I wanted to go to the bathroom or pick up my phone suddenly because someone sent me a message. And before I knew it, I was going through YouTube videos or a Twitter feed. Also, I tend to forget to eat. So I found myself setting a reminder to, like, hey, get some food, you dummy. I'm curious if people can relate to that.
\n\nDAVID: I think you just revealed both sides of that sword. It's like, sometimes, I get distracted, and I look at things that I shouldn't. And other times, I forget to eat. You have just revealed both sides of that sword, right? Your attention is going somewhere that you don't want it to go. But in both directions, there are times when you need to be taking care of yourself, and you don't because you blur over into work, and that, again, it gets into boundaries and into sharpness. And you not only have to be disciplined to focus on your work, but you have to be disciplined to focus on yourself when it's appropriate.
\n\nMIKE: I have the same responsibilities that it's like, you got both sides there, [laughs] and they're related. I tend to struggle more with the forget to eat side or working too late, or checking the phone at all hours. I think, oh, okay, I got to take care of this problem. It's still on my mind. And almost reflexively, I'm checking and keeping my mind on that, which doesn't give the mind a chance to rest.
\n\nBut that's really not much different than getting focused on something that's not work and letting the work slide. Both of them are about a lack of boundaries. You're cutting off your freedom a bit when you set up a schedule, like, hey, I want to be able to do whatever I want. If I have a schedule, well, that makes me work for the man, right? That's really not how it ends up working. When you set that schedule, well, you're the one who set the schedule.
\n\nDAVID: Mm-hmm. You're the man. [laughs]
\n\nMIKE: Exactly. You're the man or the woman. You make yourself in charge, and you're the one setting those guidelines. You're still in charge. You're just doing it consciously rather than by the seat of your pants. And if you do it consciously, you're probably going to do a better job like saying, "This is the choice I want to make, so I'm going to make it." When you make that choice with foresight and thought, you're probably going to do pretty decently and set yourself up well.
\n\nIf you let it slide a little bit around the edges because, you know, I feel like sleeping an extra five minutes a day or whatever it is, fine. But having those guidelines that you set for yourself is empowering. It isn't somebody taking something away from you. It's you giving yourself your best efforts at time management when you are conscious about it. And it works out. Yeah, I'd strongly encourage anybody who's doing remote work to create a schedule that they'd like to have and then follow it because it's surprisingly liberating.
\n\nDAVID: That is amazing. I just had an epiphany as you were saying that. I find it endlessly fascinating that you take an office job where you are required to go to a certain place, and you're required to sit in a cubicle or in an office. You're required to get work done from this time to this time and then take a break at this time and then work from this time to this time. And we give that back to you when you're remote.
\n\nYou can fudge when you show up to work. You can decide where you want to sit. You can decide how you want to work. You can decide how you allocate. You have ownership over all of these details of your job. And the first thing you lose is yourself. Isn't that interesting? All of a sudden, I'm in my office doing my work on my time, and I lose myself. That blows my mind a little tiny bit.
\n\nMIKE: Yeah, it's a big discussion about freedom and what that consists of. So there is a metaphor I like to think about regarding this idea, which is semiconductor manufacturing. So the current generation of chips that they make of processors, what are they? Under three nanometers nowadays? Something unbelievably small. And if you ever see any video of those facilities where they make those chips, it's crazy. Everyone is walking around in what looks like hazmat suits, the bunny suits they have to wear, so they don't get any particles off their bodies anywhere in the building.
\n\nThey'll have a building the size of a big-box store or bigger. It's all laminar flow, like, you've got fans in the floor and the ceiling that keep all the air moving vertically rather than horizontally, so no dust moves from side to side. And they get exceptionally pure crystals of exactly the right chemical makeup and slice them into these incredibly thin wafers. And then, they go through an amazingly precise photographic process to etch channels in them.
\n\nAnd here's just where I'm going with all this, the level of precision that is required to make those chips is mind-boggling. And the billions of dollars in investment to build the facilities to get to that degree of precision is mind-boggling. Sometimes we perceive freedom as being able to do whatever we want, and I'm thinking here in the context of remote work. Hey, I'm remote. I can make whatever schedule I want. I can do whatever I want.
\n\nAnd we think, oh, whatever we want means whatever our whims are at the moment. There is a kind of freedom that says I can do what I feel like in the moment. But the freedom that we have to do things because of those semiconductors is phenomenal. I can carry better than the Library of Alexandria in my pocket all the time. I can search all of the world's knowledge and get back results in less than a second. I can look at cat videos.
\n\nThere's just this vast quantity of things, a pool of information that's available to me, not because people did whatever they felt like in the moment but because people abstained, right? Found the very exact set of steps to follow and followed it. And that precision, that resistance to moving away from the exact set of instructions, actually was incredibly empowering for the companies that make the chips but also for everybody else.
\n\nTechnology is not based on doing what we want in the moment but on precision and following a very precise set of instructions. Thinking about freedom in that sense, in terms of empowerment, empowerment doesn't come from following the whims of the moment but by hard work and precision. And in that definition of freedom, you gain power. You gain the ability to do, not by removing constraints but by adding them, the very specific constraints that you have chosen.
\n\nDAVID: I just closed another loop in my brain here as well that, ostensibly, the topic that we were going to talk about today...and I love it when the podcast goes slightly in a different tangent. But we had started off talking about what can companies do to help fit remote devs into a team better? And I realized that we've actually circled back around to that very answer, which is the big resistance to remote work 5-10 years ago was, well, you might just go home and sit on your thumbs and do nothing, and we have no way to watch you and that kind of thing, the whole Overwatch Overlord kind of thing, which isn't great.
\n\nBut when you're remote, I definitely feel this pressure to...I got to get stuff done; I got to get stuff done; I got to get stuff done. And every time I think about my output at work, I think about it in a very static way of like, oh, I only moved two tickets today, or I only moved this much work, or I only did this much work. And so anytime I think about what do I need to do at work when I'm at home, it is, oh, I got to do work which, again, is a very low contrast kind of idea. It's just, oh, just push on this.
\n\nIf I take the time to step away from the computer, get some contrast, go for a walk, get some oxygen, do these things that I don't like doing...I'm not an exercise-loving person. I'm wildly sedentary. What can an employer do to help fit remote devs? I think it might be to remind and encourage those remote devs to get some contrast in your life. Maybe the best thing you can do to move this project forward is log out and go to bed. Get your head down; get eight hours of sleep under your pillow.
\n\nStep away from the computer. Go for a walk, go eat lunch, go out to lunch. Get away from your house and go out to lunch. Rather than just sitting down and saying, "Well, the Jira burndown chart shows that you've only moved 17 points of velocity in the last two sprints," or whatever. Instead of just making everything homogenous and uniform, encourage contrast, both in and out of work.
\n\nMIKE: I like your references to the contrast. Keep your life colorful. That seems like good advice, not just remote work but in general. [laughs] It sounds like the kind of job you'd want to have, colorful rather than dull.
\n\nDAVID: And maybe that's not for everybody. My wife and I have wildly different personalities that complement each other very well. She kind of keeps me anchored, and steady, and stable. And I'm the creative, flighty, occasionally disastrously non-foresight having. [laughs] I'm the dangerous one in the marriage. But she likes things with regularity. She was studying to be an accountant when we got married, and, I mean, that was about as much adventure as she wanted to have in her life was adding and subtracting numbers all day. Like, that's her idea of a good time, and, for me, it's mind-numbing. It's terrifying.
\n\nI say this because there are people who may be listening to this podcast who are listening to our stories of get contrasts, do these wildly disparate things. And you may be thinking, I don't want to do that, and that's fine. You don't have to do that. Do what you want to do. The whole point is to choose for yourself what is going to make you effective and happy.
\n\nMIKE: And if you've been spending all day adding, maybe you can spend some time subtracting.
\n\nDAVID: That's right. That's right. That big multiply and divide, whoa, whoa, whoa, let's not get crazy. Let's not get crazy. [laughs]
\n\nEDDY: I actually have a question; for those who have found comfort in working remote now, would you ever consider going back into the office?
\n\nMIKE: I think I'm the most remote person here, and I'd definitely consider it. Yeah, I enjoy interacting with my colleagues. The biggest downside, to me, to being in the office is probably the commute. There are distractions as well. But the commute takes some time every day. I have other reasons in that I live nowhere near the office. [laughs] And it's non-trivial for me to move for various reasons. But I would definitely consider it. I have no particular animosity toward the office.
\n\nDAVID: I hung out my shingle. We had a big tech recession in 2002 out here in Utah, and I got laid off from a government contracting job, and I hung out my shingle to do development. And I ended up landing a temporary gig, and then a remote gig, and then another temporary in-office gig. And I cycled. I would work from home for three months, then I would work in an office for six, and then I would work from home for nine months, then I'd worked in an office for four weeks.
\n\nAnd for me, it's all blurred together. Like, I have habits that I have learned to adopt, and it's just like changing your code. If it's raining, you put on your raincoat. If it's sunny, you put on a short-sleeved t-shirt. And there are certain habits that I have developed for in-office that I can't do when I'm at home. And there are certain habits that I have to adopt at home to be productive, habits that I cannot use when I'm in the office. And no, it's not just the whole wearing pants today. That's the standard joke about remote, right?
\n\nIt's things like I don't have to be as conscious about socializing. I'm a naturally gregarious person. I like other people. Ironically, I'm an introvert. I don't seek people to recharge. But I'm a naturally gregarious person. So when I'm in the office, ironically, I actually have to check myself a little bit so that I don't end up being the distraction for everyone around me because I love being that guy. And when I'm at home, I don't have to worry about that.
\n\nBut when I've been home long enough, you have to start seeking people out, or else you start going funny around the edges. You realize I have not stepped outside the front door of my house. And then you realize that your answer is the name of a month instead of hours. So, to answer your question, Eddy, yes, I absolutely would consider going back. I enjoy going back.
\n\nIt's kind of like saying, you've been eating brownies. Would you ever consider going back and eating salad? And the answer is if you've eaten nothing but brownies for 18 months, you start gasping for salads. You're like; please give me a green vegetable. Please give me something with some structure and some fiber. And that, for me, is switching environments. There's definitely a sense of, like, if you're trapped in an office or if you don't know what it's like to get away from the office, you can be like, ah, I really, really want to try the greener grass on the other side of the fence. And it certainly...a change is great. And the grass is greener on both sides of the fence.
\n\nBut having hopped the fence multiple, multiple times over my career, especially when I was freelancing, I had some customers who wanted me to freelance at their site and other customers who wanted me to freelance at home. So yeah, I've switched back and forth enough that, for me, it's just a change of wallpaper. There are coworkers in my wallpaper sometimes, not a sentence I thought I would say when I woke up this morning.
\n\nEDDY: I think I'm a little bit more on the other side of the fence. I wouldn't push back per se on going into the office, but I'm very comfortable with being remote right now. And I'm actually making plans to strive more in that direction rather than plans I'll ever have to go back, you know, just kind of got into my routines. It's definitely...I think I would look for the benefits companies that provide that remote work as a benefit type thing.
\n\nJASON: It's kind of funny. Anecdotally, my father in law in the pandemic...he's a very sociable person. When the pandemic hit, he was forced to work from home and was miserable. He was palpably irritable, just did not like it. He's one of those people who's got to be around other people. And I know a lot of people do this, but he, I mean, he already had a home office setup. But he went out and rented a space. We all kind of pitched him and helped move his office over so that he could still have a place where he could be...and he was still isolated and was as responsible as he could be with going through the pandemic.
\n\nBut now it's kind of funny. He's since switched companies, and that kind of broadened his horizons. He has his own office now, and he ended up taking a remote job and still has that external office. He needs to get out and drive and get out. And I think it's for that mental health reason, you know, you need to contrast.
\n\nDAVID: Kind of a best-of-both-worlds situation.
\n\nJASON: Yeah, absolutely.
\n\nDAVID: Which, I mean, if you do it badly, you could turn it into the worst of both worlds, right? You could end up with a long commute to an office where you're lonely anyway. So yeah, if you do pick a co-working space, pick one that's close by. [laughs]
\n\nMARK: Yeah, I think for me, so I'm kind of like Dave. I've had both types of jobs. But I think over the last couple of years, where you've just been at home, it's still nice to go to the office, but I like the ability to do both, so combined. And I don't really push one way or the other. I do feel when I do go to the office, because it's not very often, it's a lot of catching up and talking, so I don't get a whole lot done at all. Then I go home and work for a couple of hours just to get some work done.
\n\nSo if that's more consistent, I think that wouldn't happen as much. But I definitely like the ability to work from home. I got a dedicated office at home. I go in. I still kind of try to do, like you guys talked about, my same routine. I get up in the morning. I get ready for work, and it's ten steps down the hallway. And for me, it's not a commute. I'm five minutes from the office. So I don't have that excuse that it's a long way to get in there, but definitely like the ability to do both for sure.
\n\nDAVID: You just said something, Mark, that really hooked my ear there. What you said was you go into the office, and you don't feel like...you're socializing, and you don't feel like you get much work done. And, yes, in terms of advancing the project and meeting the deadline, that kind of work doesn't get done.
\n\nAll the side things that we do that support work that are work-adjacent, like socializing with your co-workers, that might not happen if you're full-time remote. You do end up getting those things done when you're in the office. It doesn't come up in your performance reviews like, well, 20% of your raise is based on how much time you spent at the water cooler and how contributing you were to the conversation. That doesn't happen. But I think it's really, really interesting.
\n\nI had an event recently where I said something that was accidentally offensive to someone else in the conversation. And the timing of me saying it and the way I said it made it sound like I was intentionally trying to mock this person. And fortunately, I had spent enough time...I had not spent enough time with that person for them to know that I was completely not trying to embarrass them. I was not trying to point a joke at them. It was literally there were two completely different ways to interpret what I said. And I didn't realize that the offensive context even existed.
\n\nAnd they kind of took it as like, oh, that was intentional, or maybe you deliberately set up the double entendre because I use those in my humor all the time. So it sounded like I was setting it up. Fortunately, there were people in the room who went, "Dave." And I'm like, "What?" And they're like, "Did you..." And I went, "Oh my gosh, no, no," and I was able to back it out. But if I had not had socialization time with the other people in the room, they would have run me out of the group. And I think I would have deserved it, I mean, not in terms of my intention but in what I had done.
\n\nAnd all of that was due to time spent not doing work with these people but instead bonding and gelling with them and getting to know them and them getting to know my sense of humor. And also to know, I'm not super proud of this, but I will tell a joke with dirty words in it, and I will tell filthy jokes, not at work. But I don't like to tell jokes that are mean to people. And even if they're perfectly clean, I don't like to tell mean jokes.
\n\nAnd the double entendre that I made was mean in its other interpretation, and there were people in the room who went, "That's not Dave. Dave did not mean to say that." So they grabbed me by the ear and said, "Stop that. You need to go say you're sorry. Don't ask why. Just go say you're sorry." I'm like, "Okay." Sorry, that's kind of a weird tangent.
\n\nBut what you said, sometimes we go to the office...what I would say is it's not that you're not getting work done, it's that you are doing different work-adjacent things. And when we work from home, there are other work-adjacent things that we can do. We can refill our emotional batteries by having access to our families or by being able to take the dog for a walk that we don't get when we're in the office, especially if we've got, you know, your commute is what? Like three and a half days if you jump in the car and head west?
\n\nMIKE: Right there. [laughs]
\n\nDAVID: Yeah. So, I don't know; I guess what it is is there's a contrast at work that is imposed. But there are other activities that we think of as, like, this is not part of the work. It's not officially part of your job description to get along with people and contribute. But it certainly shapes the direction of your career if you know how to socialize with people, if you know how to interact with people.
\n\nMIKE: Well, I would take that a little further. One of the things that I've seen be very effective at fostering remote teams is actively scheduling time, scheduling time to do, I would say, non-productive but to do things that don't create code [laughs] but are just there for social interaction. On our team, we've talked to some leadership about how to do this, actively been looking. What are some things we can do to let people have some fun together?
\n\nAnd that sounds maybe like a very forced way of making people feel like [laughs] it's a good place to work. That's really not the purpose. I mean, sure, we want it to be a more fun place to work. But, you know, if you want to go play games, you could do that at home too. Sometimes you got to have fun together because that actually has some real social utility. You get to know each other better and to trust each other sometimes by activities that are not just coding, and you have to make space for that.
\n\nNow, what that looks like for different people may be very different. There's a range of things that people may find appealing, and maybe some of the activities you do aren't what everybody would consider as fun. [laughs] It may feel like work. But that doesn't mean it doesn't have utility and value. Having every person on your team tell some interesting story about their background or playing some sort of group game together, not everybody enjoys those things.
\n\nBeing put on the spotlight to tell something, and maybe you have a very troubled history, and that's very difficult for you. You don't want to put somebody in a really bad position, and so you talk to them first. But it's a level of uncomfortable and not painful, that's still uncomfortable. It may not even be pleasant. You may not be doing it for fun, per se, but it still provides value to the team.
\n\nDAVID: Yeah, finding that line between what is normal and safe versus what is slightly risky versus what is [laughs] way over the line, finding that. Having something that is just slightly risky or slightly vulnerable that you can share and if your team reciprocates that with empathy and compassion, that is a great bonding experience. If you never share that, your relationship will be kind of...I think antiseptic is the right word there. It's a little bit of wordplay, but it's completely true. If your work environment is emotionally antiseptic, you can never grow a culture.
\n\nJASON: Yeah, I know some of the social things that we've done on the Atlas team was, I don't know, a couple of weeks ago; I don't quite recall. We played a round of Codewords and just getting to know some of the interns that we had. And hearing them in kind of a new light and getting to socialize outside of the context of here's an answer to your question or some strictly informative conversation was fun. Like Michael Webster, one of our interns, he's hilarious.
\n\nI wouldn't have gotten to hear or understand some of the humor and jokes if we hadn't been socializing. And that's fun just to reach out and talk if you need something. It really kind of opens things up, makes things easier to even reach out to people in general when you have that social context or kind of friendship context.
\n\nDAVID: Absolutely. When you have a problem that might not be important...I shared a story before the call. I won't go into all the details. But TL;DR, I was having a problem that everyone else was having and was minimizing. And it was really making me crazy. And I finally compared it to someone else, and they went, "Oh my gosh, you have a terrible problem. Go take care of this." And because I knew somebody in the IT department, it was so much easier to just reach out and say, "Hey, Mike, what's going on with this?"
\n\nAnd to ask them is this, you know because this might be a low-priority thing. I don't want to go to the help desk. I don't want to open a ticket. I don't want to have, you know, full tracking on this. And he looked at that and went, "Oh yeah, that's serious, go open a help ticket. And I will jump on it for you." And I'm like, cool, we can follow the process and also have that monitoring and meeting.
\n\nSorry to dovetail two stories back to back, but there's a pattern that's emerging from what we're talking about. We're all talking about time that we have spent in kind of play meetings as remote developers, which meant we had to make an appointment with each other. We had to schedule some mandatory fun, which just sounds like a death march, doesn't it? Doesn't it just sound terrible?
\n\nBut my boss, Zack, isn't here today, so I can talk a story behind his back here a little bit. He invited me to come work on the data team. And he said, "We've got a really, really great team." And I said, "Great," and I came, and I joined the team. Now, we're coming off the back of the pandemic, and we're all full-time remote. And I dove into the data stuff that we needed to learn. And then, three months later, I realized I'd still not met anybody on my team.
\n\nAnd I had kind of a one-on-one with...not kind of I had a one-on-one with Zack. And I said, "You keep telling me this team is really great, but I've never met them." And the next day, there was an appointment on the calendar. For every other Wednesday for an hour, we're going to get together and just play games. And so I've been able to meet with my co-workers and hang out and tell stories. And find out, you know, some teams everything is straight-laced and starched collars, and other teams are, you know, the humor is very colorful. And I'm getting to find out what colors of humor are okay on this team. And it's been super, super, incredibly awesome.
\n\nSo what I would say to any employer that's trying to figure out how do I grow a culture when everybody's remote, and we're unintentionally pouring, you know, antiseptic on places where we were growing culture, schedule some time. Don't make it mandatory. If somebody's pushing a deadline, don't force them to stress out about their job by putting down getting work done to go to some stupid meeting where people are going to joke around and shoot the BS when I really need to get, you know, don't make me do that.
\n\nBut if you do say this is a meeting and if you come, you get credit for being at work, and you don't have to do work, right? We all, you know, sometimes like to take a fun break like that. Because he scheduled that time, I've been able to hang out with my co-workers. I'd still like to hang out with them a lot more, but I've now actually met them. I could tell you their names without [laughs] having to look up an org chart. So that would be my advice (Way too long of a story.), but yeah, schedule some time. Don't make it mandatory but make it fun enough. Make it attractive to people to want to come to the somewhat mandatory fun.
\n\nJASON: I think that's huge that you said, "Don't make it mandatory." I was going to say that that's a key component, in my opinion, of making it fun is they are there...people are participating because they want to be there and can be there. And they've never been mandatory, and I've never felt like they were mandatory. And most of the time, I haven't attended because there were other things that were going on. But knowing that it was there and the opportunity I always want to now, especially the last couple that we've done, it's been fun to be a part of, you know, if you can make it.
\n\nDAVID: I worked at a shop way too long ago, gosh, 1999, I think. They had a thing called beat burnout. And the fact that we needed it was a solid demonstration that they were...it was in the video game industry. We were working 100-hour weeks, except for when they wanted us to work more. [chuckles] And they would have beat burnout. And they would do big things. They were always off-site. We would rent out a movie theater and then go to dinner at a nice restaurant or go to lunch at a nice restaurant.
\n\nAnd we'd rent out the room at the place. Every summer, they would rent out the amusement park. There's an amusement park near here that is very expensive to go to. It's taking you and your wife and go to this thing is going to be, you know, or you and your partner and go to this thing it's going to be 100 bucks to go do that. And they're like, "No, you get in for free. We're going to run a tab at this restaurant inside the park. We're going to run a tab at this cafeteria where you can get snacks." Go have fun, and you get an all-access ride pass. And that was fantastic. It was really, really cool.
\n\nAnd I was way behind on a major deadline that was going to cost me my job, [laughs] so I stayed at home, and I worked through it. And there were a couple of other co-workers who also stayed at home because they don't like amusement parks. And they didn't show up at the office, and they got reprimanded. And we got an official note from the CEO saying, "If you are not at beat burnout, you must be at your desk working." And attendance at beat burnout fell through the floor.
\n\nEven though they were doing great, fun things, after that, people were like, "Screw you, guys. I don't want to play this game." I do not want to be handcuffed to the roller coaster, which in this case is a literal roller coaster at an actual amusement park where you're supposed to be having fun.
\n\nEDDY: Basically, all I've gathered from talking to you guys [laughs] is that people can be less productive while in the office. So my question is, how the heck were any of you guys getting the job done before the pandemic?
\n\nDAVID: Oh, I wasn't. I wasn't.
\n\nEDDY: [laughs]
\n\nDAVID: The reason I had so many jobs is I'd go to a place, I get fired. No, I'm kidding. I'm kidding. It's different work, right? It's a different way of approaching. When I go into the office, I don't have to structure my day anymore because I have to be there at a certain time. That means I've got to get up at a certain time, take a shower, get dressed, eat some breakfast. I've got to commute at a certain time. And that structures out my day. Lunchtime is a certain hour; go home at a certain hour. And that gives me some of that necessary structure to my day, some of that necessary contrast to my day.
\n\nBut when I work from home, there's this wonderful thing where sometimes the structure has sharp corners, and that corner is going to gouge straight out of my eyeball. Instead of supporting me and giving me a framework to support my day, it's an overhead beam that I smack my head on. And it's just emotionally taxing, and it takes ten times as much emotional energy to be present during this particular hour of the day where if I was at home, I could...you know what? I really need to just go take a nap. And I can't do that in the office, that kind of thing.
\n\nSo knowing what things you have to build for yourself in each environment is crucial. Knowing what things can support you in each environment is crucial. And they are different things, and you can be productive. There's a book called "Peopleware" and a software called Peopleware and a company called PeopleSoft, I think. But there's an old, old book...I can't remember the names of the authors. But the book is called "Peopleware." DeMarco and Lister, I think, might be the authors. They wrote this book in the '90s, and it was all about how to be productive, how to manage people in a technological environment.
\n\nAnd their premise was technology does not solve any people problems. It doesn't solve any human problems. It just makes them happen faster. And there's just one sentence...they were walking through studying this great big cube farm. And the boss was giving them a tour of the place, and he was saying, "I like having everybody here in the cube farm," and they had low-walled cubicles. "I like the low-walled cubicles because I can look out over and I can see who's working and I can see who's not because I've got to stay on top of these people to keep them busy and keep them focused and on task."
\n\nAnd as they walked, they noticed...they looked into one of the conference rooms, and there was an engineer in the conference room with papers strewn. This was before laptops. This was in the '90s or '80s, sorry. He had papers strewn all across the conference table and was poring over them intently. They took note of it, and they continued to tour. They dropped the CEO back in his office and said, "If you don't mind, we'd like to tour your office unsupervised." And he said, "Sure, go on. I got nothing to hide."
\n\nAnd they went straight back to the conference room. And they poked their heads, and they said, "Sorry for disturbing you, but why are you in the conference room?" And he looked up, and he said, "Oh, I'm hiding in here." And they're like, "Why are you hiding in here?" And he said, "So I can get some work done." And that became kind of the spark for these guys to go write this book because they realized there's this boss who thinks all of his employees are lazy and distractible and work-shy peasants kind of thing.
\n\nIf that's true, why does he have people that are sneaking off to quiet rooms so they can get work done? Maybe we need to think about work in terms of maybe employees actually want to get work done. Maybe if we want to accomplish things in whichever environment you're in, we need to empower that and make that happen. So that was kind of a long, wild, rambly tangent. I highly recommend the "Peopleware" book if you haven't heard of that or haven't read it.
\n\nTo give you an idea of how...I want to use the phrase eternal truth. [laughs] It's a phrase of, like, how long-lasting their advice and how evergreen their advice is. They wrote the book before the internet existed. And when the internet came out, they went back to them and said, "Okay, okay, you studied those people without computers in their offices and all these things. Now that the internet is here, we need a version 2.0 of the book that changes all the things that you've learned about how people are productive and how they think and how they work."
\n\nAnd they went back and went through their book, and they compared everything to the internet age. And they added half a chapter on dealing with the distraction of email. And they said, "Other than that, the internet has done nothing to the things that we said back in the '80s. People want to get work done. And if you throw technology at them, it just distracts them," which I thought was fantastic and fascinating.
\n\nKYLE: I'd like to throw my two cents on Eddy's question too.
\n\nDAVID: Please do.
\n\nKYLE: What I've kind of noticed is when I was in the office, I would get work done, but there was the quote, unquote, "water cooler time." And this kind of goes back to Mark's concern when he goes in the office. I think, yeah, I do get more work done when I'm at home. But I think that water cooler time you'd have everyday kind of builds up to where if you're going in every once in a while, it appears as though you're not getting anything done in the office because all that water cooler time has built up, and you're getting it done in that day or in the few days that you are there that would normally naturally just be getting done day by day if you were there in the office every day.
\n\nI've also seen, too, a lot of the older offices don't have them, at least from my experience. But the newer offices, like when I was at InsideSales or the new building that we went to at Acima, they've got these isolated self-cube rooms. I'm not sure what to call them, like, solo conference rooms or whatever. And part of those, at least from my understanding, is if you need to get away, if you need to be isolated, you can go into those rooms and work, and those are there for a reason because there are distractions in an office. You need somewhere where you can just go and be heads down.
\n\nAnd I think that's just a trend that has kind of taken off in the technology space. I don't know how common that is in a normal office environment outside of technology, but I've definitely had to use those a few times just to, okay, I need somewhere where I can't be distracted, which is something I don't need at home. I can just close my door, and nobody comes and bugs me.
\n\nDAVID: I've worked at a couple of shops where they moved to an open floor plan or what, agile with a lowercase a, what agile refers to as a bullpen environment. And the idea in the bullpen is to make it so that everybody overhears everything because it's valuable. It's like, "Oh, man, I can't connect to the database. Can you connect to the database?" And somebody two seats over goes, "Oh yeah, they changed the connector from eight-bit to seven-bit. Turn on parity, and you'll be fine."
\n\nThere's like this side-channel thing. And they just saved you three hours of debugging, and it's fantastic. The problem is that you're trying to solve this problem that's like seven layers of recursion deep. And the person three chairs down says they can't connect to the database. And you know the answer, so you're going to tell them. Well, you just got distracted.
\n\nAnd in places that have bullpens, the chief complaint is you don't have any place where you can go to think, and especially you don't have any place where you can take a phone call without disrupting everybody around you. And so what I've seen are open floor plans with little three-foot by three-foot or four-foot by four-foot cubicles. They have a door. They have a big, tall window so you can see if it's occupied. And it's just enough space for a laptop and for you to put a sheet of paper next...and it's tiny. It's a tiny, tiny room. There are no monitors in there.
\n\nBut notably, there's also acoustic foam on the walls so that if you want to take a phone call or if you want to jump on a podcast with somebody and you're in the middle of a bullpen, you can go to the privacy rooms, booths, really like little phone booths all along the side. I thought that was a fantastic way to make it so that you could elect whether you wanted zero distractions for an hour or whether you wanted to take a phone call without distracting your neighbors. I thought that was a neat way to deal with that.
\n\nJASON: It's kind of funny how ironic that is that you build offices to get people into the office to work so they won't be distracted, and now we have to build sub-offices essentially where people can go to be alone and work.
\n\nDAVID: [laughs] Was it George Carlin that did the joke about humans didn't like it was cold, so they built a box to live in where it was warm? And then their food went bad, so they built a box inside the box to keep things cold. And then, the butter kept getting too hard, so they built a box inside the box inside the box to keep the butter warm. Those booths are basically the butter dishes of our office complex. [laughs]
\n\nJASON: True.
\n\nKYLE: And I've always thought the idea of a bullpen was kind of funny because you build the bullpens so that the communication can be heard, and then they complain about it being too noisy. And, at this point, I've never been in a bullpen that hasn't had a white noise generator.
\n\nDAVID: Oh.
\n\nJASON: Well, you and me were both in sales, Kyle. And it's funny because you have everybody in that environment, and you have merchants who are getting this or retailers rather that we work with who get some background noise. So it's kind of funny. I'm sure that's changed since the office is larger and you have those white noise generators. It's kind of ironic, I guess.
\n\nDAVID: I will say that in my experience, bullpens don't work well once you've got more than about ten people in it, also, if it's a focused team. If you've got 30 people in a room, and you've got the IT team, and you've got the sales team, and you've got the engineering team all working in the same room, then the things that you're overhearing have nothing to do with your job, and they're just pure distraction.
\n\nI believe that white noise generators are of the devil. They're just the most evil thing in the world. The auditory processors in your brain cannot shut off. And any species that shuts off their auditory processors while they sleep are now extinct because they get eaten in their sleep, and humans are no different. That part of your brain never ever shuts off. And so if you put on white noise to sleep or put on a fan to sleep, it doesn't give you as restful sleep as having total silence.
\n\nAnd trying to think about an engineering problem...I have ADD. I love having music on. I love having people to talk to. I love having stuff. And I had to train myself to sit in silence, and when I did, I noticed I had an extra 40 horsepower in the brain engine compartment. That's a weird metaphor. You can think better when you free up those neurons. If you have an open bullpen to encourage communication, and then you turn on a white noise generator to jam communication, fire your floor planner, please. Just, yeah, give people offices at that point; give them silence when they crave it.
\n\nMIKE: So, as we're finishing here, I'm noticing a recurring theme about being deliberate about things, scheduling time, creating spaces to do things. And this applies not just to remote work but in-person work. And it's been about the need to have some structure that it's...I'm going to say mandatory, but it is not the best word for it. If you want to be successful, you need a surprising amount of structure. And it can be completely and probably should be self-imposed. But you're making that choice for yourself so that you can be effective.
\n\nDAVID: Absolutely. When I try to schedule my exercise, I hate doing that. So I look at it from the thing of, like, I want to fill up this bucket with this much quantity of exercise over this amount of time, which makes it nice because now if I fall down the rabbit hole and I start chasing this really interesting problem at work and all of a sudden I accidentally seven hours, I don't feel like, oh, I missed my workout time. It's like, oh, no, I wanted to do some walking today, and I've got a minute now. I'll go for a walk.
\n\nAnd at the end of the week, if I haven't done much walking that week, I can say I need to do more walking this week. That's my way as a very fluid kind of eclectic person of saying I'm going to own my schedule because I can say I want to put this in my schedule, and I want to get it done. But I don't actually need to make an appointment for it. And if somebody else makes an appointment for something to happen, I absolutely am going to resist that because of just the way my ego works.
\n\nMIKE: Either way, though, you did set some time aside to yourself. You did it in the way --
\n\nDAVID: Yeah, yeah. I am 100% agreeing with you that what we're touching on here is owning the schedule, and owning your life, owning your career, owning what you do in a day, 100% agree, yes.
\n\nJASON: Can say I love how Acima has done things, kind of putting the ownership on the engineer and the employee.
\n\nDAVID: Yeah, trusting people to get it done, and then people get it done. And it feels great. Well, fantastic. Ramses had to drop off a minute early. But Kyle, Jason, Eddy, Mark, Mike, thank you so much for coming. This was a lot of fun. And I'm looking forward to our next episode. And we'll see you guys soon.
","summary":"Have you been through a global pandemic recently? This episode is for you. Today we're going to talk about fitting remote developers into a team.","date_published":"2023-03-01T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/a40de273-aa6c-4b99-b2d5-e5c4e379e6c2.mp3","mime_type":"audio/mpeg","size_in_bytes":58829263,"duration_in_seconds":3174}]},{"id":"4cd39b04-48c3-4b26-88dc-b5d9e4afa49a","title":"Episode 11: Favorite Dev Tools and Tricks Part 2","url":"https://acima-development.fireside.fm/11","content_text":"We enjoyed the last episode so much we're continuing the conversation with even more of our favorite dev tools and tricks!\n\nTranscript:\n\nDAVID: Hello and welcome to the Acima Development Podcast. We have got a full room today. We got people that are sitting in the back row lurking, and we got people sitting up in the front that want to hang out. So today, we've got Jason Loutensock, we've got Ramses Bateman, we've got Kyle Archer, we've got Zack Baker, Dominick Fabry, Eddy Lopez, Guillermo Barrera, and Mike Challis, and myself, David Brady. I will host today. \n\nAnd last episode, we talked about favorite tips, tricks, and tools. And we had so much fun doing that we're going to do it again, picking up from there. I know we had some fun pre-call chat about some really crazy stuff, things that you might not think about as development tools. Let's just open up the floor right off the bat. Does anybody have a development tip, trick, tool? \n\nI also...I had some people sneak in from the data team. I'm hoping more arrived. We've got Zack again. But I want to talk about how the data team thinks about things in a way that's very, very different than programmers. So I've kind of seeded the topic there a little bit. Does anybody have anything they want to do?\n\nJASON: I actually just got introduced to a new tool yesterday. I was on a call with Matthew Rampey yesterday morning, another developer here. And it's a cool tool called Dash. I don't know how popular it is. And I can't actually remember offhand the name of the company that produces it. It's a place where you can download documentation for any topic, cheat sheet, stuff like that. And I added a shortcut, obviously, to my bash profile. \n\nSo now whenever there's a command or gem I don't know about or some method in Ruby or Rails, if I'm not sure exactly what it does or I want to look at the documentation immediately, in the terminal, I can just Dash and then pass that in. And it's been super handy because immediately I get the documentation pulled out from a plethora of sources. But that's been my handy tool of the week that I thought would be fun to share.\n\nDAVID: That is very cool. There's a system like that built into Ruby called ri, which is...I can't remember what it stands for. The r probably stands for Ruby. The i probably stands for info because I know Matts was really big about Emacs. Instead of using the man format, it uses the info format. The problem is the first versions of ri took a long time to compile. And so you would do like a bundle install to get all of your Ruby gems installed. \n\nAnd you would just see this compiling documentation for, compiling documentation for. So it kind of became a standard practice to do gem install, name of the gem, dash dash no ri, which means you would not have the documentation. And so we've now come full circle [laughs] to people going, oh, I don't have the documentation for all these things I installed without documentation. That's kind of cool. That's kind of fun. So you're using Dash. What are some of the things that you were able to pull up on that? I know that sounds like a really stupid question, but talking about the workflow --\n\nJASON: No, no. Yeah, absolutely. So you download the app. And then you can manage a bunch of different dock sets. So they have a bunch that they support and kind of first party, if you will, of reports stuff. So you can have documentation for all sorts of things not limited to Ruby. You're not limited to Rails, everything, Python, whatever it may be, but you have this one source. And it's fully customizable. \n\nSo if there are things that you're constantly referencing, if you're working around a data migration and you want to have all the documentation for ActiveRecord pulled up, there are cheat sheets for that if you wanted to do that, or I've got Git cheat sheets now. But I can immediately reference or pull those up straight out of the terminal. And, of course, it pulls up in the UI, which is slick. It's really nice. It's a lot of fun.\n\nDAVID: That is very, very cool. I'm very happy to hear you say that it works for other things because if it was just for Ruby documentation, I was going to poke a little bit of fun at it because it's solving a problem we have created for ourselves. But, I mean, that's all of computer science. So we are the solution to and cause of all of our problems. But no, that sounds very, very cool. I will give that a checkout. What about ways of thinking? Is there an approach? Actually, let me turn this on its head. Is there a problem that you run into in your day-to-day work that you have recently found a solution that's very satisfying too?\n\nMIKE: I am hesitant to jump in because I was hosting last week. \n\nDAVID: I'm glad you're here. Welcome, Mike.\n\nMIKE: Last week, I just sang the praises of command-line tools because I think that they come over from the Unix world but are now in modern operating systems and are just unbelievably helpful. The ability to have simple, straightforward, single-purpose tools that you can chain together allows you to make an incredibly powerful pipeline, kind of on-demand, and just ad hoc. And that ability is hard to even describe how useful it is.\n\nIt's very easy to understate it. It is just fundamentally more powerful than anything else, specifically that chaining of tools because, otherwise, you have a single-purpose tool that can do what it can do, no matter how amazing it is; if it does that, you can chain tools together. You can come up with processes that their creators didn't even think about and novel things nobody's ever done before. That's amazingly powerful. \n\nDAVID: Yes. I liked the previous episode. You were talking about this bit. There's an idea that comes across in the Emacs camp called composability, where it's nice to have small, sharp tools. You guys talked last week about using awk, which is not a small tool. I mean, awk has its own programming language. And you can do crazy, crazy things just in awk. You can; I mean, it's got an entire language built into it. But it is super-duper-powerful. And there are lots of things. \n\nNobody uses awk directly. You always take, you know, you use cat, and then you pipe it into sed, and then you pipe it into grep. And then you pipe it into awk from there to kind of present the report of the things that you want. And composability is this ability to chain things together or to tie them together. There is a text editor out called Sublime Text. And it's kind of a spiritual successor to an editor called TextMate, which was really popular about 10-15 years ago. \n\nAnd TextMate, I got really excited about it because you could put these plugins into it that were written in any language. It had, you know, well, not any, but there were a bunch of languages. And it supported Ruby, which is very, very cool. And if you register your little scriptlet with it, you click on the tools menu, and you could see that script, and you could click it, and it would run. And the problem is that it couldn't talk. That little scriptlet could not talk to any of the other scriptlets. They were siloed away from each other. \n\nSo if you had a fragment of a command interpreter or a piece of something that did something useful, that, say, gave you fuzzy matching, you type amlmr, and the computer knows, oh, let's expand that to apps models lease management registrar. I don't know what the acronym is for. I literally just picked letters at random there. But that fuzzy finding, that expanding of the text to a string against a list of file names, you could do that in TextMate. And it was really cool. \n\nBut if you wrote a scriptlet to do that, you could have another scriptlet, and it did not have access to that functionality. And this was like a first-order principle over in the Emacs camp. So there's literally like a fuzzy match thing, and it has no UI. It has nothing tied into it. It just accepts a list of things, a list of text strings, and you give it a fuzzy string match, and it returns the subset of things that matched it. \n\nAnd the person who wrote this published it along with a thing to find files on your hard drive using fuzzy matching. But as soon as they published it, somebody else said, \"Oh, that is cool. I'm going to use that to let me fuzzy match and find variables inside the file.\" So all I have to do is collect all of the variable names in the current file and present them to this function that strips them out and puts them, so I can compose that function into my function. And you don't have to copy it and paste it into your library. You can just call that function remotely, and you can compose them together. And it's extremely powerful. \n\nIt's just terrifically exciting to the point that I remember for six months just my head vibrating over the idea of composability as a development tip or trick of, like, hey, that's a cool algorithm you got there. But what would be even better is if you packaged it in something that could be shared somewhere else. I remember getting really, really...I was pretty insufferable there for, I mean, not that I ever stopped being insufferable. But at some point, I was aware that I was doing it, which is like peak insufferability.\n\nMIKE: I'm with you completely on the composability. I think that that is the key attribute of, you know, the amazingness of that kind of tool. But it's a general principle. Command-line tools generally work that way, which makes them amazingly helpful. And the composability is just kind of central to their virtue.\n\nDAVID: And to be clear, I'm talking about this from the Emacs camp. It's this first-order principle they bandy around. Vim does this too. It just does it in a wildly different way, especially the old school like the Vi before Vi Improved was kicking around. Vi was an editor that was supposed to be small and sharp. But they still had the notion of composability because they basically said, \"No, no, it's the other way around. The editor is composed into the existing toolchain.\" \n\nSo we were talking last week about our last episode about grep, and awk, and all these things. Well, Vim is just one of the things in that chain. And when you're in Vim, it's easy to make it so that a single keystroke will execute something at the command line, and there's no reason you can't pipe your entire file into it. So the ability to fuzzy match something in a file in Vim it's already pre-composed. You've already got grep on your operating system. Why would we build that into the text editor? \n\nAll you guys that are in Vim composing hate mail that Emacs isn't that special, well, number one, yes, it is, but number two, you're special too. Vim can do everything Emacs can, except for the things that it can't because it doesn't think it should. This is what I was talking about, about design ideas and ways of thinking. Vim thinks a lot of things should be pushed out of it, or it used to. Vim has changed a lot in the last 5, 10, 15 years. \n\nBut Vim used to just say there are things you can do in the text editor that you shouldn't. It's the job of the operating system to handle that. And Emacs, of course, everything should be done in-house. I'm fond of saying that Emacs is an operating system. It's a nearly complete operating system in and of itself. The only thing it lacks is a small, simple text editor.\n\nMIKE: [laughs] That's an old one. I've ran into that one a few times before. But I think this is interesting. One thing we did not talk a lot about last week was kind of higher-level tools. Most of the tools we talked about were very low level like grep. We talked a lot about SQL or SQL, whatever you want to call it, [laughs] things that are kind of down at the bottom of the toolchain. \n\nWe talked a little bit about much higher level tools but not a lot, things like, say, Kubernetes. And we didn't really dig into those. I think that it's somewhat telling that we all love our low-level tools because they're just so powerful. And just didn't talk a whole lot about anything that was much higher than that. \n\nBut there are some high-level tools. Like I mentioned, we talked about Kubernetes a little bit, just a little bit at the end, or Docker, that are kind of at the other end from the command line that provide a useful utility up near the top of the stack. And those are also important tools. Kyle, I don't know if you want to talk at all about Kubernetes. You talked briefly about it last week. \n\nKYLE: Yeah, I can go off a little bit on Kubernetes just how it's kind of helped us here at the company just as a transitional thing. We used to run all of our services...I think it was Capistrano we used to deploy out. We ran on just straight EC2 VMs, which was working for us, and it worked really well. But we were able to migrate all the services over and get them running in Docker. And this allowed us to utilize orchestration tools like Rancher.\n\nBut building off of something like Rancher, we were able to go to Kubernetes. That tool has allowed us to cut costs in areas and share our infrastructure and get more services running per node than we were able to just on normal EC2 instances. This also allows us to get a lot of out-of-the-box features like monitoring or logging where we can grab everything from just a host, have all the logs just put on a host, and then have a log shipper taking those from that host and shipping them up to our ELK stack where we can visualize that.\n\nOr we have Prometheus that's able to grab metrics. And it's able to use the Kubernetes Service discovery and ship all of those metrics that it's able to scrape from all of the services up to our Prometheus clusters. And, well, it ends up in Thanos but Prometheus, and we're able to visualize those in Grafana in each of our environments.\n\nIt's also allowed us to have certain tolerances on just normal hosts that we wouldn't have had, which is if a service is running out of memory or there's a crash in the app that's recoverable, Kubernetes is able to recover those services. It does these health checks every so often. And if those services go down, it's going to bring them back up. And it's going to continue to try and bring them back up, which was a hassle in the old way that we used to work. \n\nThe management of it we're able to...I kind of talked about config management of some of this. Our Kubernetes clusters are in config management to where it's not per se a really easy task. But it has taken what could have been two-three weeks' worth of work to get an environment spun up, and that's down to a day or two. Just the speed and the flexibility that we have, we can replicate an environment, add more hosts, take hosts out with really with very much disruption.\n\nWe're even allowed to; in a couple of the environments, we're allowed to use Spot Instances, which is AWS' you can bid on instances that aren't being used in AWS that are EC2 instances and get them for lower costs for a certain amount of time until those resources are requested by another customer. In doing that, we're able to put those in our pre-flight in our development environment, or our dev environment as it's called for short, which ends up cutting our costs by a fourth or a third in those environments. \n\nThe only problem there is every once in a while, we have hosts get taken out, but Kubernetes is able to handle that, spin up new hosts, and get our services running in those environments fast enough that there's little to no disruption at least as far as I've known. There have been a few issues. But it's one of those things where it's minutes of downtime in these non-production environments in order to cut costs down by a fourth. Kubernetes is very powerful in running infrastructure.\n\nMIKE: It's really interesting when you started talking about Kubernetes, you mentioned seven other tools, which goes somewhat back to that composability. It sounds like part of what makes Kubernetes so useful is it allows you to connect to everything else in the ecosystem.\n\nKYLE: Oh yeah. I'm trying to think of what tool we can't really connect to Kubernetes. It's just, I mean, it is an ecosystem in itself. You can put anything into it. You can integrate anything into it. You can run your servers in it, or you can connect to servers meaning like Postgres. You can run Postgres inside Kubernetes if you want to. You run it outside and have your infrastructure talk to it out there.\n\nThere are several tools to manage it. Like we've been talking about, you can use command-line tools to interact. There's kubectl to interact with Kubernetes. You can use GUIs. There's Lens. I'm trying to think of some other tools to visualize the tool and your ecosystem in there. And then there are different flavors I did throughout, like Rancher. Rancher has its own solution for Kubernetes. Then there's EKS which is AWS' solution to Kubernetes, which is what we use. And then Google has theirs. Everything plays a role in Kubernetes. \n\nDAVID: That was exactly the comment I was going to make was that you started talking about Kubernetes, and you immediately started throwing out ELK, and Prometheus, and Thanos, and all these other Greek deities. And I guess ELK wasn't one, but, yeah, the idea that it ties you into these other things.\n\nThat actually reminds me of a thing that was in the discussion last week. Mike, you guys talked about IDEs versus command line. And I used to be super into IDEs. I was a big, big fan of Developer Studio, which was kind of the precursor to or the spiritual ancestor to VS Code these days. It was the big Microsoft flagship tool. And the thing that I loved about that was that you could do anything. \n\nAnd I got to the point where I was scripting my own stuff in VBA, which is Visual Basic for Applications. I could write things that would put buttons on the toolbar that I could click that would run things. And it was very cool and very powerful and very exciting. But it was very hard for me to test anything that I had put in the IDE because in order to operate an IDE, you need a human being. \n\nAnd when I came to that IDE, that was the feature that I wanted was that the IDE came up, and it just presented a smorgasbord of click on this button or this menu item. You can do anything that you want to do in your application. You just drag it and drop it and move it around from here to here to here. Whereas the command line it just presents you to the prompt and then asks you what do you want to do? And, I don't know, give me some ideas. Can you give me some guidance? And the command line is like, no, what do you want to do? It's just this blinking cursor. \n\nBut once you figure out what you want to do in the command line, you can script it and automate it very, very quickly and very easy, and you can chain them together. And these days, instead of an IDE, what I have is a folder called bin, which has all my binary scripts that I run, and it's up on GitHub. And every time I get a new machine, I pull that collection of scripts down. And this gives me basically like a set of wrappers around all my git commands.\n\nI make it very easy. I have a git script called gob, which is go branch. And when I type gob, the command line pops open a little...this goes back to the composability thing as well because it uses a tool called Selector, which does fuzzy matching in bash. And so I type gob and, boop, it presents me a list of all the branches that I have checked out on my machine. \n\nAnd I can start typing part of a branch name, and Selector will pick it. And then I hit Enter, and then it feeds that back into the git checkout command. And then it checks out that branch. And so it makes it really easy to do that from the command line. And I've added that IDE navigability back into the command line for myself. \n\nI will not lie; writing a bin folder for myself has been a project that has been ongoing for 15 years. And it's very complicated. And I've had people laugh at how complicated my scripts get because I'll end up writing a script that is nothing but the help for the other scripts. And that's because I write a script, and then I immediately forget how to use it, which is intentional. I don't want to be using brain cells to remember all these dozens and dozens, if not hundreds, of scripts that I keep on my system that are all operated differently. \n\nSo I literally will write a help script. Maybe that's a meta development trick is that I work very, very hard to have nothing that I have to memorize before I can operate some software. So anytime I write something, the first thing I have to do is the software will introduce itself and tell me how to operate that software. And that makes it so that I don't have to remember how any of my scripts work because if I try to run them and I run them wrong, the script will stop and say, \"Yeah, here's my help info.\"\n\nMATT: I think, as engineers, that's kind of our M.O. Our whole purpose is to create things that take out the human interaction. And I've always said I'm an engineer because I'm lazy. I want to create things that do other things for me.\n\nDAVID: Lazy with a capital L though, right? Because you will work all day. You'll stay up...this is something my father-in-law used to say, \"You'll stay up all night trying to figure out how to get out of an hour of work.\n\nMATT: 100%. \n\nDAVID: And he meant that as an insult, but I absolutely took it as a compliment of, like, oh, you better believe it. You better believe it. Because that hour of work I have to do every single day, once I spend that all-nighter solving that, I never have to pay that hour again for the rest of my life. And I also never have to pay the all-nighter again.\n\nMATT: It's all about the end game.\n\nMIKE: This reminds me of something that I was really struck by. I read it a couple of years ago. And, presumably, it's still true. It said that at Microsoft, part of what's led to their kind of rebirth as a company and getting back and being a leading company again is that they have a rule within the company that if they have a choice between working on a feature and working on something that improves developer productivity, the rule is choose the thing that improves developer productivity. \n\nDAVID: Wow.\n\nMATT: I think that's a great policy. In the end, those features are going to benefit from that. You may front load a little bit of extra work, but in the end, it's going to save you time over time with multiple features versus just getting a single feature out quickly. And I think companies who have that mindset highly benefit.\n\nMIKE: It's got to snowball. As you make developers more productive, they do things to make themselves more productive and more so and more so over time. And you just become kind of a juggernaut [laughs] of productivity rather than just gradually become less and less capable, which is going to be the default because entropy just makes everything fall into disorder and decay.\n\nMATT: Yep. That whole work smarter, not harder mentality, right? \n\nMIKE: Yeah.\n\nDAVID: There is a fantastic xkcd. It's number 1205 for those of you playing along at home xkcd.com/1205. It's called \"Is It Worth the Time?\" And it is a chart of how long you can work on something to make it faster, better, and easier. And it's a chart of, like, how much time did you shave off this task multiplied by how often do you use this task? And the chart points to how long you can work on this problem before it stops being useful. \n\nLike, people realize that, oh, I did this thing that shaves 30 seconds off of a task. Well, that's cool. How often do you run this task? Oh, once a year. Okay. Well, according to the chart, if you spent more than two minutes working on speeding this up, you've actually taken more time. You've not done lazy with a capital L. You've just done regular lazy with a capital ADHD. You got distracted and went down the rat hole.\n\nBut if you have a task that you do three times a day and you figure out how to shave one second off of it, if you spend all day on it, it pays off. It's worth it in the end run. Because over four or five years, that stacks up, and eventually, you're saving more time than you pay. You figure out how to shave 5 minutes off a task you run 50 times a day; you can work on this for nine months before you have sunk too much into it. So yeah, lazy with a capital L. It's a good idea.\n\nMATT: All about ROI. \n\nDAVID: Yes.\n\nMIKE: We're sometimes hesitant to put in that I [laughs] to get the R.\n\nMATT: Right, right. Absolutely. And I think business is scared of things like tech debt. They think, well, is focusing on this tech debt going to increase profitability? And, I mean, ultimately, the answer is usually yes, but it's very hard to visualize.\n\nDAVID: I spoke at a conference a couple of years ago, and I talked about how ROI on refactoring is usually worth it. But it's not going to pay off this sprint. And I think a lot of...I'm going to say team leads and managers but I'm not saying this is a culture or flaw of them. I mean, somebody in that position has some necessarily short-term focus. Sometimes we think if you pay attention to the pennies, the dollars will take care of themselves. \n\nSo if you focus on making each sprint go faster or each week of development just eke me out just one more story point out of the team velocity, well, then, in the long run, everything goes faster. And when we think about deep ROI, this does not apply. You absolutely end up getting trapped into kind of a local maximum problem where in order to go further up the hill, you have to go down the slope that you're in. \n\nI grew up in mountainous rocky canyon-y territory where the terrain was divvied up into fins of sandstone. And often to get to the top of the next fin, you had to jump down off the fin you were on. That's kind of a local maximum. And your manager wants to get as high up the rock as possible. And your manager's time frame is only long enough for you to take 20 steps because it's just this sprint, just a sprint, just a sprint. \n\nAnd so your manager doesn't want to climb down off this fin because you're going to lose height, you're going to lose height, you're going to lose height. Well, yeah, I have to because I want to get up that fin, which is twice as high as this fin. Does that make sense? You have to put that investment and you lose the return instantly. The investment is the reverse of return. You're paying out on the thing that you're going to get back. \n\nMATT: We're talking about these tools, right?\n\nDAVID: Mm-hmm. \n\nMATT: And for anyone who is new to this industry, I highly recommend focusing on the tool that is you, not that you're a tool.\n\nDAVID: Oooh. [laughs]\n\nMATT: Not that you're a tool. But we talk about all these physical tools like Vim. And I am a JetBrains user, whatever. But if you can focus on these tools, and learn how to approach these problems, and learn how to have a little bit of foresight on what you are doing, in the end, that is a tool that is going to save you time. It's going to help the company save money and make money, and it's worth the investment.\n\nMIKE: Brilliantly put. Here at Acima, the management has often said that we need to take some time to sharpen the saw. And that saw they're talking about sharpening is your own...is that tool yourself that you're talking about. And a lot of people have set aside time every day to take some time to sharpen that saw, and I think that the payoff has been tremendous. What you said there is brilliant that you're the most important tool. I'm guessing that other people have some things to say about that because it was so on point. \n\nDAVID: There's a thought that came immediately to my mind, just an epiphany that I had when I was on your team, Mike. The Atlas team does a Skills Clinic every day where we just focus on getting better at something by working on an unrelated problem and throwing weird approaches to it. And there have been times in Skills Clinic where people have been like, \"Oh, we got to focus on this thing because we got to get this done.\" And I kind of jumped in and said, \"No, you don't have to get this done.\" \n\nI mean, getting things done is a skill, and there's a time and a place to focus on that. But Skills Clinic, we look at programming so much as like you take a problem. You give it to a programmer, and that programmer outputs a solution. It's almost like a function. This function takes a problem as an input entity, emits a solution as an output. But Skills Clinic takes the approach of no, no, we take a problem and a programmer as input. And what we emit is a solution and a better programmer. \n\nAnd that is a huge epiphany that I've realized that that kind of thinking will absolutely make your career if you view every problem you approach as yourself being the input and output of this problem. Sometimes, you want to just jump in and solve the problem the quickest, fastest, easiest way. You want to optimize for minimum investment to get that maximized return. \n\nAnd other times, you want to focus on developing yourself, make yourself the inputs to the improvement process so that when you come out of it, you're like, okay, well, that took twice as long as I really wanted it to. But now I know Kubernetes, or now I know Terraform, or now I know the ELK stack, or now I know how Grafana works from inside Ruby or Python, that sort of thing. Huge shift in the mentality.\n\nMATT: Right. Regurgitation is easy. But it doesn't provide a whole lot of value for yourself or for your employers in the grand scheme of things and in the --\n\nDAVID: In the short term, it does, though, right?\n\nMATT: 100%.\n\nDAVID: The things that you can just regurgitate on demand right now are the result of the investment. That is the return on the investment that you paid into three sprints ago or two years ago. And completely weird 10-second story; I went down the rathole years back, and I learned to program in Lua, which is just a weird scripting language nobody ever uses. \n\nSo when I got into Lua, it was out of Brazil, so all the documentation was in Portuguese. And I'm like, oh boy, this is head-hurty. And 5, 10 years later, I needed to write a Read/Write Splitter in MySQL, which is, you know, I don't want to start a database war, but it's a database; we'll put it that way. It's a database. And there are a lot of databases that like to look down their noses at MySQL. \n\nAnd at the time, MySQL had absolutely no concept of middleware, and no concept of Read/Write splitting. And then somebody said, \"Well, there's this middleware layer that you can install for MySQL. The problem is it's only scriptable in some language called Lua. Does anybody know this?\" And I'm sitting there going, oh, oh, oh, because I never expected this to pay off. But here we are.\n\nMIKE: To be fair, I think Lua is used in a lot of embedded systems, and that's where it shines, and that's its purpose.\n\nDAVID: It's what it was designed for was you could drop Lua into a C++ program, and now people can script your C++ code at runtime from a text prompt. That's exactly what it was for.\n\nSPEAKER 1: Adobe uses it for things like Lightroom and Photoshop plugins.\n\nDAVID: There's a really big game that got scripted almost entirely...and I want to say World of Warcraft. Don't quote me on that. I didn't play a lot of WoW. But there were a lot of people around 2010, 2009 timeframe who were not programmers that knew how to script in Lua because there was a really popular game out at the time that was scriptable from Lua. \n\nAnd they didn't advertise that it was Lua. They were just like, oh yeah, you can script our game. Here's the manual to our game. And then somebody finally went, wait a minute, this is Lua. And they started manipulating the vector tables that you could pass around. And it worked because it really was Lua.\n\nJASON: My nephew, my 11-year-old nephew, who wanted to get into programming in general, got into a game called Roblox. And that's, I guess, massively popular now. It's the same idea that he's learned to script in Lua. It's really fun.\n\nMATT: You have Minecraft. I mean, things like that are really pushing these youngsters to learn this stuff, and that's great.\n\nMIKE: Which is a great segue into our next episode. [laughs] We're just going to be talking about how to teach your kids to program. \n\nSPEAKER 1: One topic that we've kind of talked about but on a higher level, I'm kind of thinking about it with everything that's been said, is just kind of automation in general. As an engineer, we're all wanting to use different tools, and we're all wanting to make our jobs faster and get on to the new shiny per se. And I'm just thinking about it, and I feel like one of the biggest things that we can do is anything that we're finding that's just repetitive, that is old, and that we're just not really wanting to personally manage all the time we need to take the time to just automate that. \n\nAnd it kind of goes back to the ROI conversation. It might take you a little bit longer to automate that task than to just go click through it or whatever you happen to be doing. But there's going to be a huge benefit to getting it automated because, yeah, it took you 15 minutes today when it normally takes you 30 seconds. But if you're doing that daily, weekly, or whatever, that's going to save you a lot of time and money. And then you get to work on the next task that's caught your interest or the next framework, whatever it is that you happen to be working with. \n\nIt made me think back when we were talking about setting up your machine. I ended up working with a guy that was specific in the Microsoft world, had been for years about 13 years of C# experience. And using Windows, one thing that was never really pushed for me was the command line or PowerShell. In Windows, everything has a UI, has a GUI. So it was kind of a foreign idea getting in and learning about package managers and terminals with Linux. And I thought it was really cool. \n\nAnd he ended up showing me one day he has his entire Windows setup in a PowerShell script. He used an open-source package manager, Chocolatey. I think there are better ones now. But he would set up his entire development environment, even for Windows. And this was even a few years ago. But my main point is just automation and automating everything because, as engineers, we don't want to do the same task over and over.\n\nSPEAKER 2: David, you were asking for difference in thought processes. And I would say this is probably the biggest similarity. I think all around software engineering, data engineering, DevOps, everywhere, we don't feel like, or at least my feeling on it, I should say, I want to automate myself out of a job, basically. My job is not done until I've done that. So automation any tool I can build to automate something.\n\nDAVID: There's a fantastic joke that a boss of mine told me years and years ago. This guy comes into work, and every day he comes into work, there's this guy sitting in an office, and he's just kicked back with his feet up on the desk, and he's just staring out the window. And he's never doing any work. He's just constantly staring out the window. And this guy, he sees him every time. \n\nAnd finally, he gets frustrated. And he's like, \"Who's that guy that's never doing any work?\" And his manager says, \"Oh, that's Bob. Last year, Bob came up with an idea that saved the company $20 million. So Bob's job now is to sit in that office and come up with another idea.\"\n\nMATT: Yeah, I think we're a long way from working ourselves out of a job. You know, even with artificial intelligence and everything, there's always going to be a need for someone to help create and scale that type of thing.\n\nSPEAKER 2: Yeah, I wasn't saying that we're close. I was just saying that's the goal. It's a very, very far distant goal that may never be realized. But as you build these automations and do all this stuff, like data engineering, for instance, we could just have somebody go into all these systems and copy-paste all this data into a CSV and then go into DataGrip and say, \"Here's a CSV,\" upload this to a table. But we're automating jobs out, essentially. It's in the best of our abilities. So that's all I was stating with that is like the goal, which may never be achievable, but the goal would be automation.\n\nMATT: It's a good goal to work for. I would love to be good enough to work myself out of my job.\n\nDAVID: But it won't happen, though, because --\n\nMATT: But it will never happen.\n\nDAVID: But it also will happen. Because what will happen is I talked a little bit earlier in the call about how I've got this gigantic folder called bin, and it's got all these scripts. I have worked myself out of the job of managing git from the command line because I have this suite of scripts that will check out branches that will...I can run this pattern-matching thing to delete branches off of my machine by Jira ticket number and that sort of thing. And I got all these scripts to do this. If you are constantly working yourself out of a job, you will find yourself managing batches of those jobs that you have worked yourself out of. \n\nAnd I'm saying this like I'm a really smart person. If you could see me in person, you'd realize I'm just vibrating in my chair because this is something I just realized talking to you guys in this call just now is that, yeah, if you focus on improving your skills and trying to work yourself out of a job, you will wind up with so much more capacity because now you can spend your time thinking about, well, now that I've got all these jobs solved, what can I do with all those solutions in my back pocket? You know, with all those arrows in my quiver, what kind of bigger game can I hunt now?\n\nMATT: You're making yourself much more valuable.\n\nJASON: It's just like the pre-industrial revolution. Everybody was working 100-hour weeks doing some monotonous task. As soon as you automate it, you go from 100 to 40. And now everybody as a whole has more time to invest in new creative solutions and coming up with new ideas, so exactly what you're saying, opening up yourself for a greater capacity, just leads to a new revolution.\n\nMATT: Yeah, it drives innovation.\n\nMIKE: I was going to say the exact same thing, Jason, that Industrial Revolution didn't get everybody out of a job. It gave us modern civilization.\n\nDAVID: And created managerial jobs and labor management jobs for the people that had been working on grinding wheat.\n\nMIKE: It's exactly right. It allows you to do higher-order work that is probably more rewarding and way more productive.\n\nSPEAKER 3: If you're willing to be flexible, you're not really automating yourself out of a job. You're just automating yourself into a different job. \n\nDAVID: That is a beautiful way to put it.\n\nMATT: And a more fulfilling job.\n\nDAVID: I can't think of a better way of summing up the topic for this episode and the previous one that the whole point of all these developer tips and tricks is that you're automating yourself into a better job. And it doesn't necessarily mean leaving your current employment. It literally just means you're increasing your capacity and your ability to handle more responsibility, which is awesome.\n\nMATT: Moral of the story is sharpen the tool that is you.\n\nJASON: I just have to add that Acima, as a whole, has been incredible; not to go all corporate or whatever, but it's been incredible that this has been prioritized in a way. And, for instance, our Skills Clinic that we do that you've touched on before, I've learned more in that Skills Clinic than anywhere else given the same amount of time. It's phenomenal. And I always walk away applying those new things that we got to investigate and learn that were completely unrelated to my everyday work. So I just wanted to touch on that culture and how grateful I am for it. \n\nMIKE: And that can be repeated. I'm assuming that we have listeners that are not [laughs] working here. That's kind of the point, propose this or implement it. Better than propose it, make it happen at the place that you're working, and things will go better. [laughs] It's on you now. You've been given a choice. Are you going to take it, or are you not? You have the opportunity to go out and sharpen that saw. There's a strong invitation here that it's worth it and you should try it. Pick up that file, start sharpening.\n\nMATT: I would highly recommend always try and gravitate towards people who have better skills than you and people who are better than you at what you do. That is the way to grow.\n\nDAVID: The most biggest growth I ever had was I was the only guy on an engineering team at Evans & Sutherland, which is a big graphics company in Salt Lake City. I was the only kid on a team of 26 who did not have a master's degree or a Ph.D. And I dropped out of college. So I was like two full schools behind [laughs] everyone else on my team. And it was drinking from the firehose every single day. I was ten times the programmer every year than I was before. It was amazing.\n\nMATT: Yeah, you just have to swallow that pride and take it all in.\n\nDAVID: I will throw this one in as well. I worked with a programmer years and years and years ago who was super arrogant and obnoxious, and he had to blow his own horn all the time. Anyway, he was kind of insufferable to be around. And I realized he's this way because he's insecure, and I don't like it because I'm insecure. It was very much like some one-upmanship, or I'm smarter than you, that kind of thing. \n\nAnd then one day, I realized, six months from now, I'm going to know everything he knows because he can't stop himself from telling me how smart he is and how he does this thing and then showing me how to do it, which I realized was actually super valuable. And I realized six months from now, I'm going to know everything you know, and you're not going to know anything I know. I'm content with this arrangement. And I was able to remove my ego from the problem. And it turned out that I was right. He was actually an invaluable training resource to me, even though we were both college-aged kids with just awful nerd personalities that were absolutely insufferable. \n\nSPEAKER 3: You know, Dave, I kind of want to echo what Matt said, where put yourself in an uncomfortable position in a sense and reach out to developers in a way that you will pair with people more. When I started, and it's like you said, I was drinking from a firehose, but I quickly realized that the more time I reached out to someone for assistance, the quicker I learned, so my growth has grown exponentially because of the help that I received from people.\n\nMATT: And I feel like, at Acima, we've built a really good group of people for that. We don't know what we don't know. But we have such great people and such a great team. Everyone has something to offer, and if we can all realize that, we can all learn and grow together.\n\nDAVID: Take some time in your office and be Bob, right? Try to come up with an idea. And spend some time actively trying to come up with ideas. Your ability to come up with ideas will improve directly as a result. \n\nAll righty, we are at time for the hour. I kind of call this the podcasting phenomenon where you start the call, and it's a little bit dry, and nobody has stuff. And then some ideas will happen, and we get sparked on them, and we riff on them. And you get to the end of the hour, and everybody's like, oh, one last thought, one last thought. I love that. It makes me very, very happy to have that. \n\nAnd I want to thank everybody that came today: Jason, and Ramses, and Zack, Kyle, Michael, and Eddy, Guillermo, Mike, Matt, and, oh, [inaudible 43:18] came in a little bit late. Sorry I didn't introduce you, but happy to have you here. Thanks, everybody, for dropping in on the call today. We will see you guys in the next episode.","content_html":"We enjoyed the last episode so much we're continuing the conversation with even more of our favorite dev tools and tricks!
\n\nTranscript:
\n\nDAVID: Hello and welcome to the Acima Development Podcast. We have got a full room today. We got people that are sitting in the back row lurking, and we got people sitting up in the front that want to hang out. So today, we've got Jason Loutensock, we've got Ramses Bateman, we've got Kyle Archer, we've got Zack Baker, Dominick Fabry, Eddy Lopez, Guillermo Barrera, and Mike Challis, and myself, David Brady. I will host today.
\n\nAnd last episode, we talked about favorite tips, tricks, and tools. And we had so much fun doing that we're going to do it again, picking up from there. I know we had some fun pre-call chat about some really crazy stuff, things that you might not think about as development tools. Let's just open up the floor right off the bat. Does anybody have a development tip, trick, tool?
\n\nI also...I had some people sneak in from the data team. I'm hoping more arrived. We've got Zack again. But I want to talk about how the data team thinks about things in a way that's very, very different than programmers. So I've kind of seeded the topic there a little bit. Does anybody have anything they want to do?
\n\nJASON: I actually just got introduced to a new tool yesterday. I was on a call with Matthew Rampey yesterday morning, another developer here. And it's a cool tool called Dash. I don't know how popular it is. And I can't actually remember offhand the name of the company that produces it. It's a place where you can download documentation for any topic, cheat sheet, stuff like that. And I added a shortcut, obviously, to my bash profile.
\n\nSo now whenever there's a command or gem I don't know about or some method in Ruby or Rails, if I'm not sure exactly what it does or I want to look at the documentation immediately, in the terminal, I can just Dash and then pass that in. And it's been super handy because immediately I get the documentation pulled out from a plethora of sources. But that's been my handy tool of the week that I thought would be fun to share.
\n\nDAVID: That is very cool. There's a system like that built into Ruby called ri, which is...I can't remember what it stands for. The r probably stands for Ruby. The i probably stands for info because I know Matts was really big about Emacs. Instead of using the man format, it uses the info format. The problem is the first versions of ri took a long time to compile. And so you would do like a bundle install to get all of your Ruby gems installed.
\n\nAnd you would just see this compiling documentation for, compiling documentation for. So it kind of became a standard practice to do gem install, name of the gem, dash dash no ri, which means you would not have the documentation. And so we've now come full circle [laughs] to people going, oh, I don't have the documentation for all these things I installed without documentation. That's kind of cool. That's kind of fun. So you're using Dash. What are some of the things that you were able to pull up on that? I know that sounds like a really stupid question, but talking about the workflow --
\n\nJASON: No, no. Yeah, absolutely. So you download the app. And then you can manage a bunch of different dock sets. So they have a bunch that they support and kind of first party, if you will, of reports stuff. So you can have documentation for all sorts of things not limited to Ruby. You're not limited to Rails, everything, Python, whatever it may be, but you have this one source. And it's fully customizable.
\n\nSo if there are things that you're constantly referencing, if you're working around a data migration and you want to have all the documentation for ActiveRecord pulled up, there are cheat sheets for that if you wanted to do that, or I've got Git cheat sheets now. But I can immediately reference or pull those up straight out of the terminal. And, of course, it pulls up in the UI, which is slick. It's really nice. It's a lot of fun.
\n\nDAVID: That is very, very cool. I'm very happy to hear you say that it works for other things because if it was just for Ruby documentation, I was going to poke a little bit of fun at it because it's solving a problem we have created for ourselves. But, I mean, that's all of computer science. So we are the solution to and cause of all of our problems. But no, that sounds very, very cool. I will give that a checkout. What about ways of thinking? Is there an approach? Actually, let me turn this on its head. Is there a problem that you run into in your day-to-day work that you have recently found a solution that's very satisfying too?
\n\nMIKE: I am hesitant to jump in because I was hosting last week.
\n\nDAVID: I'm glad you're here. Welcome, Mike.
\n\nMIKE: Last week, I just sang the praises of command-line tools because I think that they come over from the Unix world but are now in modern operating systems and are just unbelievably helpful. The ability to have simple, straightforward, single-purpose tools that you can chain together allows you to make an incredibly powerful pipeline, kind of on-demand, and just ad hoc. And that ability is hard to even describe how useful it is.
\n\nIt's very easy to understate it. It is just fundamentally more powerful than anything else, specifically that chaining of tools because, otherwise, you have a single-purpose tool that can do what it can do, no matter how amazing it is; if it does that, you can chain tools together. You can come up with processes that their creators didn't even think about and novel things nobody's ever done before. That's amazingly powerful.
\n\nDAVID: Yes. I liked the previous episode. You were talking about this bit. There's an idea that comes across in the Emacs camp called composability, where it's nice to have small, sharp tools. You guys talked last week about using awk, which is not a small tool. I mean, awk has its own programming language. And you can do crazy, crazy things just in awk. You can; I mean, it's got an entire language built into it. But it is super-duper-powerful. And there are lots of things.
\n\nNobody uses awk directly. You always take, you know, you use cat, and then you pipe it into sed, and then you pipe it into grep. And then you pipe it into awk from there to kind of present the report of the things that you want. And composability is this ability to chain things together or to tie them together. There is a text editor out called Sublime Text. And it's kind of a spiritual successor to an editor called TextMate, which was really popular about 10-15 years ago.
\n\nAnd TextMate, I got really excited about it because you could put these plugins into it that were written in any language. It had, you know, well, not any, but there were a bunch of languages. And it supported Ruby, which is very, very cool. And if you register your little scriptlet with it, you click on the tools menu, and you could see that script, and you could click it, and it would run. And the problem is that it couldn't talk. That little scriptlet could not talk to any of the other scriptlets. They were siloed away from each other.
\n\nSo if you had a fragment of a command interpreter or a piece of something that did something useful, that, say, gave you fuzzy matching, you type amlmr, and the computer knows, oh, let's expand that to apps models lease management registrar. I don't know what the acronym is for. I literally just picked letters at random there. But that fuzzy finding, that expanding of the text to a string against a list of file names, you could do that in TextMate. And it was really cool.
\n\nBut if you wrote a scriptlet to do that, you could have another scriptlet, and it did not have access to that functionality. And this was like a first-order principle over in the Emacs camp. So there's literally like a fuzzy match thing, and it has no UI. It has nothing tied into it. It just accepts a list of things, a list of text strings, and you give it a fuzzy string match, and it returns the subset of things that matched it.
\n\nAnd the person who wrote this published it along with a thing to find files on your hard drive using fuzzy matching. But as soon as they published it, somebody else said, "Oh, that is cool. I'm going to use that to let me fuzzy match and find variables inside the file." So all I have to do is collect all of the variable names in the current file and present them to this function that strips them out and puts them, so I can compose that function into my function. And you don't have to copy it and paste it into your library. You can just call that function remotely, and you can compose them together. And it's extremely powerful.
\n\nIt's just terrifically exciting to the point that I remember for six months just my head vibrating over the idea of composability as a development tip or trick of, like, hey, that's a cool algorithm you got there. But what would be even better is if you packaged it in something that could be shared somewhere else. I remember getting really, really...I was pretty insufferable there for, I mean, not that I ever stopped being insufferable. But at some point, I was aware that I was doing it, which is like peak insufferability.
\n\nMIKE: I'm with you completely on the composability. I think that that is the key attribute of, you know, the amazingness of that kind of tool. But it's a general principle. Command-line tools generally work that way, which makes them amazingly helpful. And the composability is just kind of central to their virtue.
\n\nDAVID: And to be clear, I'm talking about this from the Emacs camp. It's this first-order principle they bandy around. Vim does this too. It just does it in a wildly different way, especially the old school like the Vi before Vi Improved was kicking around. Vi was an editor that was supposed to be small and sharp. But they still had the notion of composability because they basically said, "No, no, it's the other way around. The editor is composed into the existing toolchain."
\n\nSo we were talking last week about our last episode about grep, and awk, and all these things. Well, Vim is just one of the things in that chain. And when you're in Vim, it's easy to make it so that a single keystroke will execute something at the command line, and there's no reason you can't pipe your entire file into it. So the ability to fuzzy match something in a file in Vim it's already pre-composed. You've already got grep on your operating system. Why would we build that into the text editor?
\n\nAll you guys that are in Vim composing hate mail that Emacs isn't that special, well, number one, yes, it is, but number two, you're special too. Vim can do everything Emacs can, except for the things that it can't because it doesn't think it should. This is what I was talking about, about design ideas and ways of thinking. Vim thinks a lot of things should be pushed out of it, or it used to. Vim has changed a lot in the last 5, 10, 15 years.
\n\nBut Vim used to just say there are things you can do in the text editor that you shouldn't. It's the job of the operating system to handle that. And Emacs, of course, everything should be done in-house. I'm fond of saying that Emacs is an operating system. It's a nearly complete operating system in and of itself. The only thing it lacks is a small, simple text editor.
\n\nMIKE: [laughs] That's an old one. I've ran into that one a few times before. But I think this is interesting. One thing we did not talk a lot about last week was kind of higher-level tools. Most of the tools we talked about were very low level like grep. We talked a lot about SQL or SQL, whatever you want to call it, [laughs] things that are kind of down at the bottom of the toolchain.
\n\nWe talked a little bit about much higher level tools but not a lot, things like, say, Kubernetes. And we didn't really dig into those. I think that it's somewhat telling that we all love our low-level tools because they're just so powerful. And just didn't talk a whole lot about anything that was much higher than that.
\n\nBut there are some high-level tools. Like I mentioned, we talked about Kubernetes a little bit, just a little bit at the end, or Docker, that are kind of at the other end from the command line that provide a useful utility up near the top of the stack. And those are also important tools. Kyle, I don't know if you want to talk at all about Kubernetes. You talked briefly about it last week.
\n\nKYLE: Yeah, I can go off a little bit on Kubernetes just how it's kind of helped us here at the company just as a transitional thing. We used to run all of our services...I think it was Capistrano we used to deploy out. We ran on just straight EC2 VMs, which was working for us, and it worked really well. But we were able to migrate all the services over and get them running in Docker. And this allowed us to utilize orchestration tools like Rancher.
\n\nBut building off of something like Rancher, we were able to go to Kubernetes. That tool has allowed us to cut costs in areas and share our infrastructure and get more services running per node than we were able to just on normal EC2 instances. This also allows us to get a lot of out-of-the-box features like monitoring or logging where we can grab everything from just a host, have all the logs just put on a host, and then have a log shipper taking those from that host and shipping them up to our ELK stack where we can visualize that.
\n\nOr we have Prometheus that's able to grab metrics. And it's able to use the Kubernetes Service discovery and ship all of those metrics that it's able to scrape from all of the services up to our Prometheus clusters. And, well, it ends up in Thanos but Prometheus, and we're able to visualize those in Grafana in each of our environments.
\n\nIt's also allowed us to have certain tolerances on just normal hosts that we wouldn't have had, which is if a service is running out of memory or there's a crash in the app that's recoverable, Kubernetes is able to recover those services. It does these health checks every so often. And if those services go down, it's going to bring them back up. And it's going to continue to try and bring them back up, which was a hassle in the old way that we used to work.
\n\nThe management of it we're able to...I kind of talked about config management of some of this. Our Kubernetes clusters are in config management to where it's not per se a really easy task. But it has taken what could have been two-three weeks' worth of work to get an environment spun up, and that's down to a day or two. Just the speed and the flexibility that we have, we can replicate an environment, add more hosts, take hosts out with really with very much disruption.
\n\nWe're even allowed to; in a couple of the environments, we're allowed to use Spot Instances, which is AWS' you can bid on instances that aren't being used in AWS that are EC2 instances and get them for lower costs for a certain amount of time until those resources are requested by another customer. In doing that, we're able to put those in our pre-flight in our development environment, or our dev environment as it's called for short, which ends up cutting our costs by a fourth or a third in those environments.
\n\nThe only problem there is every once in a while, we have hosts get taken out, but Kubernetes is able to handle that, spin up new hosts, and get our services running in those environments fast enough that there's little to no disruption at least as far as I've known. There have been a few issues. But it's one of those things where it's minutes of downtime in these non-production environments in order to cut costs down by a fourth. Kubernetes is very powerful in running infrastructure.
\n\nMIKE: It's really interesting when you started talking about Kubernetes, you mentioned seven other tools, which goes somewhat back to that composability. It sounds like part of what makes Kubernetes so useful is it allows you to connect to everything else in the ecosystem.
\n\nKYLE: Oh yeah. I'm trying to think of what tool we can't really connect to Kubernetes. It's just, I mean, it is an ecosystem in itself. You can put anything into it. You can integrate anything into it. You can run your servers in it, or you can connect to servers meaning like Postgres. You can run Postgres inside Kubernetes if you want to. You run it outside and have your infrastructure talk to it out there.
\n\nThere are several tools to manage it. Like we've been talking about, you can use command-line tools to interact. There's kubectl to interact with Kubernetes. You can use GUIs. There's Lens. I'm trying to think of some other tools to visualize the tool and your ecosystem in there. And then there are different flavors I did throughout, like Rancher. Rancher has its own solution for Kubernetes. Then there's EKS which is AWS' solution to Kubernetes, which is what we use. And then Google has theirs. Everything plays a role in Kubernetes.
\n\nDAVID: That was exactly the comment I was going to make was that you started talking about Kubernetes, and you immediately started throwing out ELK, and Prometheus, and Thanos, and all these other Greek deities. And I guess ELK wasn't one, but, yeah, the idea that it ties you into these other things.
\n\nThat actually reminds me of a thing that was in the discussion last week. Mike, you guys talked about IDEs versus command line. And I used to be super into IDEs. I was a big, big fan of Developer Studio, which was kind of the precursor to or the spiritual ancestor to VS Code these days. It was the big Microsoft flagship tool. And the thing that I loved about that was that you could do anything.
\n\nAnd I got to the point where I was scripting my own stuff in VBA, which is Visual Basic for Applications. I could write things that would put buttons on the toolbar that I could click that would run things. And it was very cool and very powerful and very exciting. But it was very hard for me to test anything that I had put in the IDE because in order to operate an IDE, you need a human being.
\n\nAnd when I came to that IDE, that was the feature that I wanted was that the IDE came up, and it just presented a smorgasbord of click on this button or this menu item. You can do anything that you want to do in your application. You just drag it and drop it and move it around from here to here to here. Whereas the command line it just presents you to the prompt and then asks you what do you want to do? And, I don't know, give me some ideas. Can you give me some guidance? And the command line is like, no, what do you want to do? It's just this blinking cursor.
\n\nBut once you figure out what you want to do in the command line, you can script it and automate it very, very quickly and very easy, and you can chain them together. And these days, instead of an IDE, what I have is a folder called bin, which has all my binary scripts that I run, and it's up on GitHub. And every time I get a new machine, I pull that collection of scripts down. And this gives me basically like a set of wrappers around all my git commands.
\n\nI make it very easy. I have a git script called gob, which is go branch. And when I type gob, the command line pops open a little...this goes back to the composability thing as well because it uses a tool called Selector, which does fuzzy matching in bash. And so I type gob and, boop, it presents me a list of all the branches that I have checked out on my machine.
\n\nAnd I can start typing part of a branch name, and Selector will pick it. And then I hit Enter, and then it feeds that back into the git checkout command. And then it checks out that branch. And so it makes it really easy to do that from the command line. And I've added that IDE navigability back into the command line for myself.
\n\nI will not lie; writing a bin folder for myself has been a project that has been ongoing for 15 years. And it's very complicated. And I've had people laugh at how complicated my scripts get because I'll end up writing a script that is nothing but the help for the other scripts. And that's because I write a script, and then I immediately forget how to use it, which is intentional. I don't want to be using brain cells to remember all these dozens and dozens, if not hundreds, of scripts that I keep on my system that are all operated differently.
\n\nSo I literally will write a help script. Maybe that's a meta development trick is that I work very, very hard to have nothing that I have to memorize before I can operate some software. So anytime I write something, the first thing I have to do is the software will introduce itself and tell me how to operate that software. And that makes it so that I don't have to remember how any of my scripts work because if I try to run them and I run them wrong, the script will stop and say, "Yeah, here's my help info."
\n\nMATT: I think, as engineers, that's kind of our M.O. Our whole purpose is to create things that take out the human interaction. And I've always said I'm an engineer because I'm lazy. I want to create things that do other things for me.
\n\nDAVID: Lazy with a capital L though, right? Because you will work all day. You'll stay up...this is something my father-in-law used to say, "You'll stay up all night trying to figure out how to get out of an hour of work.
\n\nMATT: 100%.
\n\nDAVID: And he meant that as an insult, but I absolutely took it as a compliment of, like, oh, you better believe it. You better believe it. Because that hour of work I have to do every single day, once I spend that all-nighter solving that, I never have to pay that hour again for the rest of my life. And I also never have to pay the all-nighter again.
\n\nMATT: It's all about the end game.
\n\nMIKE: This reminds me of something that I was really struck by. I read it a couple of years ago. And, presumably, it's still true. It said that at Microsoft, part of what's led to their kind of rebirth as a company and getting back and being a leading company again is that they have a rule within the company that if they have a choice between working on a feature and working on something that improves developer productivity, the rule is choose the thing that improves developer productivity.
\n\nDAVID: Wow.
\n\nMATT: I think that's a great policy. In the end, those features are going to benefit from that. You may front load a little bit of extra work, but in the end, it's going to save you time over time with multiple features versus just getting a single feature out quickly. And I think companies who have that mindset highly benefit.
\n\nMIKE: It's got to snowball. As you make developers more productive, they do things to make themselves more productive and more so and more so over time. And you just become kind of a juggernaut [laughs] of productivity rather than just gradually become less and less capable, which is going to be the default because entropy just makes everything fall into disorder and decay.
\n\nMATT: Yep. That whole work smarter, not harder mentality, right?
\n\nMIKE: Yeah.
\n\nDAVID: There is a fantastic xkcd. It's number 1205 for those of you playing along at home xkcd.com/1205. It's called "Is It Worth the Time?" And it is a chart of how long you can work on something to make it faster, better, and easier. And it's a chart of, like, how much time did you shave off this task multiplied by how often do you use this task? And the chart points to how long you can work on this problem before it stops being useful.
\n\nLike, people realize that, oh, I did this thing that shaves 30 seconds off of a task. Well, that's cool. How often do you run this task? Oh, once a year. Okay. Well, according to the chart, if you spent more than two minutes working on speeding this up, you've actually taken more time. You've not done lazy with a capital L. You've just done regular lazy with a capital ADHD. You got distracted and went down the rat hole.
\n\nBut if you have a task that you do three times a day and you figure out how to shave one second off of it, if you spend all day on it, it pays off. It's worth it in the end run. Because over four or five years, that stacks up, and eventually, you're saving more time than you pay. You figure out how to shave 5 minutes off a task you run 50 times a day; you can work on this for nine months before you have sunk too much into it. So yeah, lazy with a capital L. It's a good idea.
\n\nMATT: All about ROI.
\n\nDAVID: Yes.
\n\nMIKE: We're sometimes hesitant to put in that I [laughs] to get the R.
\n\nMATT: Right, right. Absolutely. And I think business is scared of things like tech debt. They think, well, is focusing on this tech debt going to increase profitability? And, I mean, ultimately, the answer is usually yes, but it's very hard to visualize.
\n\nDAVID: I spoke at a conference a couple of years ago, and I talked about how ROI on refactoring is usually worth it. But it's not going to pay off this sprint. And I think a lot of...I'm going to say team leads and managers but I'm not saying this is a culture or flaw of them. I mean, somebody in that position has some necessarily short-term focus. Sometimes we think if you pay attention to the pennies, the dollars will take care of themselves.
\n\nSo if you focus on making each sprint go faster or each week of development just eke me out just one more story point out of the team velocity, well, then, in the long run, everything goes faster. And when we think about deep ROI, this does not apply. You absolutely end up getting trapped into kind of a local maximum problem where in order to go further up the hill, you have to go down the slope that you're in.
\n\nI grew up in mountainous rocky canyon-y territory where the terrain was divvied up into fins of sandstone. And often to get to the top of the next fin, you had to jump down off the fin you were on. That's kind of a local maximum. And your manager wants to get as high up the rock as possible. And your manager's time frame is only long enough for you to take 20 steps because it's just this sprint, just a sprint, just a sprint.
\n\nAnd so your manager doesn't want to climb down off this fin because you're going to lose height, you're going to lose height, you're going to lose height. Well, yeah, I have to because I want to get up that fin, which is twice as high as this fin. Does that make sense? You have to put that investment and you lose the return instantly. The investment is the reverse of return. You're paying out on the thing that you're going to get back.
\n\nMATT: We're talking about these tools, right?
\n\nDAVID: Mm-hmm.
\n\nMATT: And for anyone who is new to this industry, I highly recommend focusing on the tool that is you, not that you're a tool.
\n\nDAVID: Oooh. [laughs]
\n\nMATT: Not that you're a tool. But we talk about all these physical tools like Vim. And I am a JetBrains user, whatever. But if you can focus on these tools, and learn how to approach these problems, and learn how to have a little bit of foresight on what you are doing, in the end, that is a tool that is going to save you time. It's going to help the company save money and make money, and it's worth the investment.
\n\nMIKE: Brilliantly put. Here at Acima, the management has often said that we need to take some time to sharpen the saw. And that saw they're talking about sharpening is your own...is that tool yourself that you're talking about. And a lot of people have set aside time every day to take some time to sharpen that saw, and I think that the payoff has been tremendous. What you said there is brilliant that you're the most important tool. I'm guessing that other people have some things to say about that because it was so on point.
\n\nDAVID: There's a thought that came immediately to my mind, just an epiphany that I had when I was on your team, Mike. The Atlas team does a Skills Clinic every day where we just focus on getting better at something by working on an unrelated problem and throwing weird approaches to it. And there have been times in Skills Clinic where people have been like, "Oh, we got to focus on this thing because we got to get this done." And I kind of jumped in and said, "No, you don't have to get this done."
\n\nI mean, getting things done is a skill, and there's a time and a place to focus on that. But Skills Clinic, we look at programming so much as like you take a problem. You give it to a programmer, and that programmer outputs a solution. It's almost like a function. This function takes a problem as an input entity, emits a solution as an output. But Skills Clinic takes the approach of no, no, we take a problem and a programmer as input. And what we emit is a solution and a better programmer.
\n\nAnd that is a huge epiphany that I've realized that that kind of thinking will absolutely make your career if you view every problem you approach as yourself being the input and output of this problem. Sometimes, you want to just jump in and solve the problem the quickest, fastest, easiest way. You want to optimize for minimum investment to get that maximized return.
\n\nAnd other times, you want to focus on developing yourself, make yourself the inputs to the improvement process so that when you come out of it, you're like, okay, well, that took twice as long as I really wanted it to. But now I know Kubernetes, or now I know Terraform, or now I know the ELK stack, or now I know how Grafana works from inside Ruby or Python, that sort of thing. Huge shift in the mentality.
\n\nMATT: Right. Regurgitation is easy. But it doesn't provide a whole lot of value for yourself or for your employers in the grand scheme of things and in the --
\n\nDAVID: In the short term, it does, though, right?
\n\nMATT: 100%.
\n\nDAVID: The things that you can just regurgitate on demand right now are the result of the investment. That is the return on the investment that you paid into three sprints ago or two years ago. And completely weird 10-second story; I went down the rathole years back, and I learned to program in Lua, which is just a weird scripting language nobody ever uses.
\n\nSo when I got into Lua, it was out of Brazil, so all the documentation was in Portuguese. And I'm like, oh boy, this is head-hurty. And 5, 10 years later, I needed to write a Read/Write Splitter in MySQL, which is, you know, I don't want to start a database war, but it's a database; we'll put it that way. It's a database. And there are a lot of databases that like to look down their noses at MySQL.
\n\nAnd at the time, MySQL had absolutely no concept of middleware, and no concept of Read/Write splitting. And then somebody said, "Well, there's this middleware layer that you can install for MySQL. The problem is it's only scriptable in some language called Lua. Does anybody know this?" And I'm sitting there going, oh, oh, oh, because I never expected this to pay off. But here we are.
\n\nMIKE: To be fair, I think Lua is used in a lot of embedded systems, and that's where it shines, and that's its purpose.
\n\nDAVID: It's what it was designed for was you could drop Lua into a C++ program, and now people can script your C++ code at runtime from a text prompt. That's exactly what it was for.
\n\nSPEAKER 1: Adobe uses it for things like Lightroom and Photoshop plugins.
\n\nDAVID: There's a really big game that got scripted almost entirely...and I want to say World of Warcraft. Don't quote me on that. I didn't play a lot of WoW. But there were a lot of people around 2010, 2009 timeframe who were not programmers that knew how to script in Lua because there was a really popular game out at the time that was scriptable from Lua.
\n\nAnd they didn't advertise that it was Lua. They were just like, oh yeah, you can script our game. Here's the manual to our game. And then somebody finally went, wait a minute, this is Lua. And they started manipulating the vector tables that you could pass around. And it worked because it really was Lua.
\n\nJASON: My nephew, my 11-year-old nephew, who wanted to get into programming in general, got into a game called Roblox. And that's, I guess, massively popular now. It's the same idea that he's learned to script in Lua. It's really fun.
\n\nMATT: You have Minecraft. I mean, things like that are really pushing these youngsters to learn this stuff, and that's great.
\n\nMIKE: Which is a great segue into our next episode. [laughs] We're just going to be talking about how to teach your kids to program.
\n\nSPEAKER 1: One topic that we've kind of talked about but on a higher level, I'm kind of thinking about it with everything that's been said, is just kind of automation in general. As an engineer, we're all wanting to use different tools, and we're all wanting to make our jobs faster and get on to the new shiny per se. And I'm just thinking about it, and I feel like one of the biggest things that we can do is anything that we're finding that's just repetitive, that is old, and that we're just not really wanting to personally manage all the time we need to take the time to just automate that.
\n\nAnd it kind of goes back to the ROI conversation. It might take you a little bit longer to automate that task than to just go click through it or whatever you happen to be doing. But there's going to be a huge benefit to getting it automated because, yeah, it took you 15 minutes today when it normally takes you 30 seconds. But if you're doing that daily, weekly, or whatever, that's going to save you a lot of time and money. And then you get to work on the next task that's caught your interest or the next framework, whatever it is that you happen to be working with.
\n\nIt made me think back when we were talking about setting up your machine. I ended up working with a guy that was specific in the Microsoft world, had been for years about 13 years of C# experience. And using Windows, one thing that was never really pushed for me was the command line or PowerShell. In Windows, everything has a UI, has a GUI. So it was kind of a foreign idea getting in and learning about package managers and terminals with Linux. And I thought it was really cool.
\n\nAnd he ended up showing me one day he has his entire Windows setup in a PowerShell script. He used an open-source package manager, Chocolatey. I think there are better ones now. But he would set up his entire development environment, even for Windows. And this was even a few years ago. But my main point is just automation and automating everything because, as engineers, we don't want to do the same task over and over.
\n\nSPEAKER 2: David, you were asking for difference in thought processes. And I would say this is probably the biggest similarity. I think all around software engineering, data engineering, DevOps, everywhere, we don't feel like, or at least my feeling on it, I should say, I want to automate myself out of a job, basically. My job is not done until I've done that. So automation any tool I can build to automate something.
\n\nDAVID: There's a fantastic joke that a boss of mine told me years and years ago. This guy comes into work, and every day he comes into work, there's this guy sitting in an office, and he's just kicked back with his feet up on the desk, and he's just staring out the window. And he's never doing any work. He's just constantly staring out the window. And this guy, he sees him every time.
\n\nAnd finally, he gets frustrated. And he's like, "Who's that guy that's never doing any work?" And his manager says, "Oh, that's Bob. Last year, Bob came up with an idea that saved the company $20 million. So Bob's job now is to sit in that office and come up with another idea."
\n\nMATT: Yeah, I think we're a long way from working ourselves out of a job. You know, even with artificial intelligence and everything, there's always going to be a need for someone to help create and scale that type of thing.
\n\nSPEAKER 2: Yeah, I wasn't saying that we're close. I was just saying that's the goal. It's a very, very far distant goal that may never be realized. But as you build these automations and do all this stuff, like data engineering, for instance, we could just have somebody go into all these systems and copy-paste all this data into a CSV and then go into DataGrip and say, "Here's a CSV," upload this to a table. But we're automating jobs out, essentially. It's in the best of our abilities. So that's all I was stating with that is like the goal, which may never be achievable, but the goal would be automation.
\n\nMATT: It's a good goal to work for. I would love to be good enough to work myself out of my job.
\n\nDAVID: But it won't happen, though, because --
\n\nMATT: But it will never happen.
\n\nDAVID: But it also will happen. Because what will happen is I talked a little bit earlier in the call about how I've got this gigantic folder called bin, and it's got all these scripts. I have worked myself out of the job of managing git from the command line because I have this suite of scripts that will check out branches that will...I can run this pattern-matching thing to delete branches off of my machine by Jira ticket number and that sort of thing. And I got all these scripts to do this. If you are constantly working yourself out of a job, you will find yourself managing batches of those jobs that you have worked yourself out of.
\n\nAnd I'm saying this like I'm a really smart person. If you could see me in person, you'd realize I'm just vibrating in my chair because this is something I just realized talking to you guys in this call just now is that, yeah, if you focus on improving your skills and trying to work yourself out of a job, you will wind up with so much more capacity because now you can spend your time thinking about, well, now that I've got all these jobs solved, what can I do with all those solutions in my back pocket? You know, with all those arrows in my quiver, what kind of bigger game can I hunt now?
\n\nMATT: You're making yourself much more valuable.
\n\nJASON: It's just like the pre-industrial revolution. Everybody was working 100-hour weeks doing some monotonous task. As soon as you automate it, you go from 100 to 40. And now everybody as a whole has more time to invest in new creative solutions and coming up with new ideas, so exactly what you're saying, opening up yourself for a greater capacity, just leads to a new revolution.
\n\nMATT: Yeah, it drives innovation.
\n\nMIKE: I was going to say the exact same thing, Jason, that Industrial Revolution didn't get everybody out of a job. It gave us modern civilization.
\n\nDAVID: And created managerial jobs and labor management jobs for the people that had been working on grinding wheat.
\n\nMIKE: It's exactly right. It allows you to do higher-order work that is probably more rewarding and way more productive.
\n\nSPEAKER 3: If you're willing to be flexible, you're not really automating yourself out of a job. You're just automating yourself into a different job.
\n\nDAVID: That is a beautiful way to put it.
\n\nMATT: And a more fulfilling job.
\n\nDAVID: I can't think of a better way of summing up the topic for this episode and the previous one that the whole point of all these developer tips and tricks is that you're automating yourself into a better job. And it doesn't necessarily mean leaving your current employment. It literally just means you're increasing your capacity and your ability to handle more responsibility, which is awesome.
\n\nMATT: Moral of the story is sharpen the tool that is you.
\n\nJASON: I just have to add that Acima, as a whole, has been incredible; not to go all corporate or whatever, but it's been incredible that this has been prioritized in a way. And, for instance, our Skills Clinic that we do that you've touched on before, I've learned more in that Skills Clinic than anywhere else given the same amount of time. It's phenomenal. And I always walk away applying those new things that we got to investigate and learn that were completely unrelated to my everyday work. So I just wanted to touch on that culture and how grateful I am for it.
\n\nMIKE: And that can be repeated. I'm assuming that we have listeners that are not [laughs] working here. That's kind of the point, propose this or implement it. Better than propose it, make it happen at the place that you're working, and things will go better. [laughs] It's on you now. You've been given a choice. Are you going to take it, or are you not? You have the opportunity to go out and sharpen that saw. There's a strong invitation here that it's worth it and you should try it. Pick up that file, start sharpening.
\n\nMATT: I would highly recommend always try and gravitate towards people who have better skills than you and people who are better than you at what you do. That is the way to grow.
\n\nDAVID: The most biggest growth I ever had was I was the only guy on an engineering team at Evans & Sutherland, which is a big graphics company in Salt Lake City. I was the only kid on a team of 26 who did not have a master's degree or a Ph.D. And I dropped out of college. So I was like two full schools behind [laughs] everyone else on my team. And it was drinking from the firehose every single day. I was ten times the programmer every year than I was before. It was amazing.
\n\nMATT: Yeah, you just have to swallow that pride and take it all in.
\n\nDAVID: I will throw this one in as well. I worked with a programmer years and years and years ago who was super arrogant and obnoxious, and he had to blow his own horn all the time. Anyway, he was kind of insufferable to be around. And I realized he's this way because he's insecure, and I don't like it because I'm insecure. It was very much like some one-upmanship, or I'm smarter than you, that kind of thing.
\n\nAnd then one day, I realized, six months from now, I'm going to know everything he knows because he can't stop himself from telling me how smart he is and how he does this thing and then showing me how to do it, which I realized was actually super valuable. And I realized six months from now, I'm going to know everything you know, and you're not going to know anything I know. I'm content with this arrangement. And I was able to remove my ego from the problem. And it turned out that I was right. He was actually an invaluable training resource to me, even though we were both college-aged kids with just awful nerd personalities that were absolutely insufferable.
\n\nSPEAKER 3: You know, Dave, I kind of want to echo what Matt said, where put yourself in an uncomfortable position in a sense and reach out to developers in a way that you will pair with people more. When I started, and it's like you said, I was drinking from a firehose, but I quickly realized that the more time I reached out to someone for assistance, the quicker I learned, so my growth has grown exponentially because of the help that I received from people.
\n\nMATT: And I feel like, at Acima, we've built a really good group of people for that. We don't know what we don't know. But we have such great people and such a great team. Everyone has something to offer, and if we can all realize that, we can all learn and grow together.
\n\nDAVID: Take some time in your office and be Bob, right? Try to come up with an idea. And spend some time actively trying to come up with ideas. Your ability to come up with ideas will improve directly as a result.
\n\nAll righty, we are at time for the hour. I kind of call this the podcasting phenomenon where you start the call, and it's a little bit dry, and nobody has stuff. And then some ideas will happen, and we get sparked on them, and we riff on them. And you get to the end of the hour, and everybody's like, oh, one last thought, one last thought. I love that. It makes me very, very happy to have that.
\n\nAnd I want to thank everybody that came today: Jason, and Ramses, and Zack, Kyle, Michael, and Eddy, Guillermo, Mike, Matt, and, oh, [inaudible 43:18] came in a little bit late. Sorry I didn't introduce you, but happy to have you here. Thanks, everybody, for dropping in on the call today. We will see you guys in the next episode.
","summary":"We enjoyed the last episode so much we're continuing the conversation with even more of our favorite dev tools and tricks!","date_published":"2023-02-15T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/4cd39b04-48c3-4b26-88dc-b5d9e4afa49a.mp3","mime_type":"audio/mpeg","size_in_bytes":45963724,"duration_in_seconds":2618}]},{"id":"1513ca25-ecd9-421e-9322-346d60176ec6","title":"Episode 10: Favorite Dev Tools and Tricks","url":"https://acima-development.fireside.fm/10","content_text":"We're calling out the most valuable development tools and tricks.\n\nTranscript:\n\nMIKE: Welcome to another episode of our Acima Development Podcast. I'm Mike. I'll be hosting today. And today, we're going to be talking about development tools and tricks. Before I do that, I'd like to go around and have everybody briefly introduce themselves. Mark, do you want to introduce yourself?\n\nMARK: Hello, my name is Mark. I'm an intern for the summer.\n\nMIKE: Thank you. Jason.\n\nJASON: My name is Jason. I've been developing for about six months now. I started as a developer here in Acima.\n\nMIKE: Great, thank you. Ramses. \n\nRAMSES: Hello, hello. I have also been a software developer now with Acima for about six months. \n\nMIKE: Great. And Kyle.\n\nKYLE: Hey. Kyle, DevOps Engineer, been doing that here at Acima for about five years. \n\nMIKE: So now that we've introduced ourselves, I wanted to start with not quite a story; it's an example. I'm interested in pedagogy, in teaching, in the science of teaching, and I've read quite a bit about math teaching in particular. There's a popular technique that has become more popular in the most recent few years to help children develop the appropriate mindset, and it works for adults as well, develop an appropriate mindset for math because, a lot of times, we're taught mindsets that are not very helpful.\n\nLearning math by rote, in particular, tends to lead to difficulty solving novel problems. You run into a new problem like \"Oh, now what do I do?\" And professional mathematicians approach math very differently than how it's often taught in schools. For them, math is art and creativity, and looking for interesting new ways to approach problems, where a lot of people who are taught math in school are taught very differently, where here's your problem; here's the technique for solving the problem. And that's the one way to do it. \n\nSo in order to develop a better mindset, a more flexible mindset for teaching, they do what they call number talks or math talks, where you present a math problem that you can solve in your head with some challenge. How would you add 23+84 in your head? And you ask a class of 30 kids this, and you get like 32 answers. [laughs] Everybody does it a little bit different. And I may be exaggerating a little bit because you'll tend to have common themes. \n\nBut it's remarkable how people will come up with very different ways of doing it; some people will add the tens first and then the ones. Some people will try to get to easy numbers like multiples of 25, or multiples of 5, or multiples of 10 and then balance out the numbers accordingly. Some people might go to 100, you know, they work around boundaries like that. There are lots of different ways that people can approach problems, a surprising number of ways people can approach those kinds of problems. \n\nAnd once you hear all the other different ways, you're like, wow, I thought there was only one way of doing it, and I thought that it was just my way. And it turns out there are many different ways of solving the problem. It's worth looking up if you're ever interested in thinking about it. It's fun to try it with a group of friends. Just come up with a problem like that. Just do some addition or some multiplication that you can do in your head with a bit of challenge, and ask other people how they do it. And you'll likely be surprised how many different ways people do it. \n\nI used this introduction to come into software development tools because, coming into the industry, you might think there's one way to do this. But our industry is a creative industry. Our job is not to follow a set of rules but to solve problems. I'll repeat that repeatedly, and I've probably mentioned it other times I host the podcast because there's a misconception sometimes that our job is writing code, which is not really true. Our job is to solve problems. \n\nAnd there are a lot of ways to solve the problem. And you may have people who approach the problem in very different ways and come up with a great solution through very different techniques. And that doesn't mean that one is right and one is wrong. So there's some real value in seeing a variety of ways to find out what works for you. There's not necessarily a right answer. Sometimes there may be solutions that are not very good, and it's good to recognize those. \n\nBut, in general, there's a lot of gray area there. There's a lot of flexibility and areas where there's not really a right or wrong answer, just a variety of answers. And having a whole toolbox with the tools rather than just one hammer is going to give you a lot of power to do things differently and likely do things better because you can reach for a variety of tools and find the right one for the right place. And you may find that your personal preferences lead to different approaches from what other people do. \n\nI'm going to lead by saying that I am very much a minimalist. I used to use big IDE when I was a Java developer years ago. That's pretty common in the Java world. And I did a lot of remote server administration for a while. I started using command-line editors and just stuck. So I'm a Vim user, primarily, and have been for a number of years, which is just a command-line editor. I never leave the terminal. I rarely leave Vim because I can execute commands from right inside Vim. \n\nI don't have a lot of plugins and just use the standard Linux or Unix toolset that is available from the command line to do my searching, and I find it extremely effective. I'm able to navigate around and find what I need very quickly. Others use a big toolset and are able to also navigate around files and find things very quickly. I'm not going to say one is better than the other because I think they both have merits. \n\nSo I'm going to start with just saying I tend to be a minimalist. I'm curious where other people are at because other people have their own tools that are very useful. I will say that knowing at least one command-line editor...and the two big capable command-line editors are generally Vim and Emacs. It's a surprising superpower. It takes some doing to learn. But those tools allow you to accomplish a lot with a little. And even if you don't get really good at them, it's nice to have those in your tool belt so that you can accomplish something. \n\nSo if I were going to start by saying a very useful tool, I would recommend learning a command-line editor. And if you want an easy introduction, there are very easy command-line editors you can start with, like Nano, which is a simple editor that once you get into, you'll be able to see how to get out, unlike Vim. [laughs] And you can get started that way. I think there's a lot of value in using those command-line tools. \n\nI would like to talk more about the incredible value of the command-line tools that come from Unix, particularly grep. Grep is the open version of this that's widely used on Linux that I think are invaluable for myself in my tools. But I don't want to talk the whole time. So I wanted to lead with that, talk about the importance of a variety of tools and start my take on useful tools by saying to anybody that command-line tools are, in general, incredibly valuable. \n\nAnd I'll talk a bit more about that in a minute. But I'd like to hear what other people have to say about what, you know if you were to just...if somebody was to ask you, \"What is most valuable to you?\" what would you say is the most valuable tool?\n\nKYLE: I'll have to agree with you on the Vim subject. And I have been around the Emacs people as well. And I feel like that requires a different set of joints in your finger to use that tool. \n\nMIKE: [laughs]\n\nKYLE: But I come from the other side of the fence as well, though, because starting out in QA, a lot of the tooling that I was introduced to that made my job easier and flow well was all GUI-related and Git from a UI and stuff like that. The transition to using something like Vim, I wouldn't say I'm any kind of expert. But I feel like it's made my job so much easier in the sense that there is native tooling, like you were saying, grep, and everything in Linux and Unix that you're able to do that's even cross-platform. \n\nA lot of what you're going to find on Linux is available on a macOS or even in the later versions of Windows. Now you have that ability as well, either through PowerShell or through the Linux Subsystem that they have now. It's just I do feel like my productivity has increased. And the scripting and the tooling that you're able to use, even with just a Bash application, you can just do a lot that you can still do with a UI as long as you're really familiar with the tool.\n\nMIKE: A lot of things you can. There are some things that are actually remarkably difficult, if not impossible, to do from a UI. I don't want to get to the punch line because [laughs] I want to hear what a couple of people have to say. But I'd like to grab back onto that thread because I am with you completely that it is useful, and you can do it from a UI if you're familiar with it. But there are some things that I think you can't in most UIs to accomplish. Again, I'm going to come back to that. I'm curious. Jason, I think you were going to say something.\n\nJASON: Yeah, I think it was drifting a little further off-topic from a specific IDE. But a really useful tool that I had when I came on, Johnny actually pointed out. And basically, he showed me where I can customize methods anywhere. I run Pry or anywhere I run an IRB console. So just knowing where you can add those custom methods is really a time saver and kind of lends itself to what you're saying, you know, running things from a command-line editor or a GUI. \n\nRight now, I'm using RubyMine. It seems to be popular with a lot of the devs and has a lot of useful tools, and being newer, that is helpful. There are a lot of helpful hints there. But yeah, being able to modify your pryrc file or irbrc file to add some custom methods to help you save time has been big for me.\n\nMIKE: Thank you. And anybody listening who's not a Rubyist, Pry is a popular Ruby debugger. You can use it on the command line.\n\nZACK: So one of the big things that have always gotten me throughout my development career is merge conflicts. And the tool that I found that I've just hooked into the terminal so I can just run git merge tool and pops up is Meld. I don't know if any of you guys have ever used that before. It kind of does pop up like a UI for you with some easy arrows to just kind of push and create one file with the right edits to it. And it's been kind of a lifesaver as far as merge conflicts have gone.\n\nMIKE: Merge conflicts are the bane of development. [laughs] Anything you can find that is useful for those is good. We could have a whole episode on Git and ways to deal with merge conflicts and avoid them before they ever happen. Thank you. Anybody else who wants to share a tool that just really is the best one that they use?\n\nMARK: For me, it'd be VS Code open-source code editor that you can pretty much do anything you want in. And the only problem I would give with it is that there are sometimes troubles with its terminal. But besides that, I find it's a great source for editing code as well as the ability to customize the interface and so forth and style it as you like.\n\nMIKE: I feel like VS Code has kind of taken over the world. [laughter] It seems to have become the editor of choice for a lot of people\n\nMARK: Well, more and more people are pushing for open-source products. I think Germany swapped all their government computers to Linux. Or was it that they put their whole school system on Nextcloud?\n\nMIKE: I know there have been several experiments in Europe like that. I haven't followed it really closely. Definitely, you know, open source is helpful. And they've got a big corporate backer for VS Code as well, so it keeps it going. And we've also got some interesting integrations now with Copilot, some very interesting things with that IDE. They're very cool. So there's a lot of innovative stuff going on with VS Code. And it seems to be where a lot of the energy of the industry is.\n\nKYLE: Just wanted to pop in and say something about VS Code just because that is another tool that we heavily use with DevOps because, once again, it integrates with everything under the kitchen sink. Just...and, Mark, I don't know if you've tried it or not, but you can basically use any terminal with VS Code. You just have to go into the settings and pick which one you're wanting to use if that helps you out at all.\n\nMARK: I'm aware. It's just there are some times where I've run into a permissions issue where it'll say, \"The terminal within VS Code has less permissions,\" then just pulling up the terminal app.\n\nKYLE: Ah, okay, yeah. It can be limiting at times.\n\nMIKE: Well, with that segue going back to terminal, I want to revisit this idea of command-line tooling versus user interface. There is a philosophy embraced by the Unix operating system. Nobody...well, I say nobody...the original Unix operating system birthed many children. And while pure Unix is not that widespread anymore, it has many of these children. I believe that macOS is formally certified as a Unix and meets the requirements for Unix, even though it has a very different underlying system. \n\nAnd Linux is Unix-ish in its approach, even if it was built from scratch. And it's taken over the world. Android runs on a Linux base. I'm actually not that familiar with iOS, and it wouldn't surprise me if they used something similar. Because most of the devices out there in the world run some Unix-inspired operating system, and I think there's a reason for that. There's a Unix philosophy that says the tools should be small, single-purpose, and composable, all of which are important.\n\nI say small, meaning that they don't do all of the things, although some of the...like an editor, maybe does a lot of things. Emacs, there's very little it can't do. [laughs] Some people see it as unwieldy, but it's a very powerful tool. But most of the tools they use are single-purpose. You might have a tool, for example, that counts characters or a tool that just runs regular expressions to search for text within a string. \n\nAnd the single-purpose tools are composable in that Unix allows you to create what they call a pipe, which sends the output from one command as the input to the next command, allowing you to chain commands together and compose an arbitrary number. And you can put 50 of them together. There's no real preset limit. You can take the output from one command and put it as the input into another. And, okay, that sounds simple enough, but it is radically more powerful than other approaches, and I'd argue that emphatically. \n\nBecause if you've got a graphical tool that lets you do a thing, maybe it lets you do a sophisticated thing, you can get whatever you can get from that one tool. But instead, if you have a simple tool, instead of doing some very sophisticated thing, it does one thing well. And it allows you to compose it with other things that would accomplish the same thing. \n\nYou can almost always do what you're able to do with that graphical tool but then take the output of it and send it to another tool. So you can take your sum that you got from the first tool and send it into the next thing to do some math on, and then send it to the next tool to print it out to a file, write it to a file, and then you can even send that file as an email. You can chain these tools together to come up with a very sophisticated workflow.\n\nA lot of times, just in development, you want to do simple things. What if I want to look for all the files that have a particular extension and, for each of those, search for a particular line of text, and then compile all of those files into a list and open them up in my editor? I do things like that all the time using my command-line tools. It is very useful. And that's something that's actually very challenging to do using a graphical tool and may not be even possible in most of the tools that you use unless you've learned how to use some obscure tricks in the edges of it. \n\nAnd that's why I say that these command-line tools are, I think, underappreciated, and the most important tool, I think, that is worth developing and getting in your tool belt as a developer because they are much more powerful than most other tools available and faster as well. And, Kyle, you talked a little about the power of command-line tools. Has that been consistent with your experience? \n\nKYLE: Yeah, that's along the lines of what I've experienced, too. I was actually sitting here thinking, as you were talking, there are CLIs for everything almost. And, I mean, if you're looking at a...not to bash on any particular company, but you go in, and you'll see a UI, and you'll familiarize yourself with the UI. And then four months later, if we're looking at long-term or whatever, you go in there, and it's like, oh, we've got a new look. And you're like, well, that's great, but where's this setting, or where's this feature that I was looking for, right?\n\nMIKE: Right.\n\nKYLE: And with a CLI, I've found that doesn't change; that's constant. They may add features, but they don't really move them around. And I feel like that's another power of the command line, if you want to say, is each of these companies are making CLIs that they will do the same thing, call the same APIs is what, you know, either their application or web interface will do. And you're able to do a lot of the same stuff easier and faster than you might be able to even find it in the UI.\n\nMIKE: I agree 100%. Just anybody listening who's not familiar with the lingo, when we say CLI, we're talking about a command-line interface and using something from the command line. I'd ask that further, Kyle, from the DevOps perspective, which would you rather have: configuration files that you can manage through Git or, I guess, there are other source control tools, but nobody...I'm not going to say nobody uses them [laughs], but Git has kind of dominated source control. Would you rather have configuration files and scripts managed in source control or a pipeline managed in a graphical user interface?\n\nKYLE: I avoid a graphical interface as often as I can. It's all about having configuration management.\n\nMIKE: Yeah, there's a reason that DevOps has become central to, I think, most effective software companies. They treat configuration as code and use the same powerful tools that we use in development to great effect.\n\nKYLE: It's just one of those situations where, I mean, here at Acima, we've got...what is it? Five or six environments. And so, I can either go in and configure each environment through the UI, or I can configure one environment in configuration and apply it to every environment with a quick script. And it's which one would you rather do? Which one's going to save the company money and make you look better in the long run?\n\nMIKE: [laughs] Absolutely. We touched on something there that we didn't dig into. We've been talking about command-line tools and their great utility. We talked a little about Linux. But there's another incredibly powerful tool written by the same guy, Linus Torvalds, who gave us Linux. Linus Torvalds started Linux [laughs] but has personally not, by any stretch of the imagination, written most of it. His gift to the community was planting that seed and starting that community, which together builds a remarkable tool. \n\nHe also started another tool that has become fundamental to, I think, most development companies out there which is Git. It's kind of a silly name, incredibly useful tool. [laughs] And maybe it'll be superseded by some other tool in the future, but for now, I think Git sort of reigns supreme. You can use graphical interfaces for Git. I actually don't, like, ever [laughs] because its command-line interface is very powerful. But graphical interface, there's nothing wrong with them; they work great. \n\nAnd having that powerful version control system is, I would say, a vital tool for effective development. Those of us who have used, I would say, inferior or simpler tools in the past know the treasure of everything that Git is. And Git is actually, at its core, a pretty simple idea, which is instead of having a central repository that has a single point of failure, everybody keeps everything. \n\nYou keep a history of all of the changes that have ever happened to your project. So you have basically a stream of events that are signed so that you can verify them, going back all the way through the history of a project back to the beginning. And everybody keeps that. And by having it distributed, it's very hard to lose very much that's important. \n\nMaybe you've been working on a project for a couple of days and kept it on your own machine and didn't share it out with the community, and maybe you'd lose that. You don't need to. You can push up your changes hourly, and then you're unlikely to ever lose very much, and certainly not the whole project. And Git manages that distributed system of multiple copies repository and manages to handle it very well. And in doing so, it has become a central tool to most development. And there are business models built on top of this open-source tool, such as GitHub. What would your lives be like without Git?\n\nMARK: A big pain in the ass for managing.\n\nMIKE: [laughs] Yeah.\n\nJASON: A lot of re-dos.\n\nMARK: We'd probably have something like daily merge meetings just to begin work together to merge all our changes on everyone's devices.\n\nMIKE: Oh. I think that's exactly right. You'd do daily merge meetings, and you'd have to carefully coordinate. [laughs] Let's make sure that you never touch the same code as somebody else. And it would all have to be done by direct communication. You'd have to talk to somebody first to coordinate that. No easy way to handle conflicts when you both accidentally change the same file. Nightmare. [laughs]\n\nIf you're starting out at development, start using a version control system. It will serve you well. It will save you pain, as Mark said, and re-dos, as Jason said, more times than you will ever count. It's just a remarkable tool. And there are some other systems out there. Git is the most popular and extremely useful. There are a couple; like I said, there are a couple others. Mercurial is used somewhat. It has its own following.\n\nJASON: One added benefit to that is you can have kind of this fearless sense of I can experiment, do whatever I want. I'll just create a new branch and experiment and see if it works.\n\nMIKE: And it changes your mindset, doesn't it? \n\nJASON: Absolutely, yeah. Also, this discussion is kind of interesting because I never really thought of source control giving you that liberty. I'm not afraid to touch any file. I can do anything that I need to so long as I'm not modifying something else, like a database that could set me back, but even that, you can reset to a better state.\n\nMIKE: I love where you went there. It gives you freedom to experiment. Freedom to experiment is one of the most important things for being able to be effective as well. It's closely related to the idea of psychological safety, which research has shown to be the central characteristic of effective teams and effective developers. If you can feel free to experiment without harsh consequences, then you're going to, and trying new things is how you get things done. I think we could talk about this for some time. \n\nI saw a wonderful presentation at a conference once talking about luck. And I'm going to summarize the presentation, and you can go and look it up yourself. But there was some research done about what makes people lucky. They asked people who of their friends was lucky. So they characterized a group of people who were considered lucky by others. And they figured out what was different between these lucky people and other people to actually research what makes a person lucky. And you can figure out what the difference is. \n\nIt turns out that the key differentiator between lucky people and people who are not so fortunate is that the lucky people try new things. And when I heard that, I maybe paused; oh, really? I've thought about that a lot since. If I want to be lucky, I got to try new things. You're never going to have a different experience unless you're trying new things. Yes, you can have some bad experiences too, [laughs] but you're never going to get something that will take you to the next level, have that moment of serendipity unless you are putting yourself in a position where you can. Git allows you to be lucky.\n\nKYLE: Just a side thought on this as we're talking. I almost feel like Git, or a tool like Git, is partially why some of us can be employed I feel like. Because I just feel like if you didn't have a tool like that, large development teams would be a burden more than anything. You'd have small, concise teams that don't, you know, one dude is working on something, and then the other person is working on something else. And they can quickly merge things. \n\nAnd we wouldn't be able to have 7, 10 developers, whatever, working on the same service because they would be having those conflicts, and it would be just a managing nightmare. So I think part of this is that it gives us that parallelism to allow more developers to be employed to deliver faster and everything.\n\nMIKE: Well-spoken. Going back again to that capacity, it'd be utterly unmanageable without the tool. \n\nWe've talked a lot about the power of the command line and the power of version control. I think I mentioned one command-line tool that, for me, is perhaps my favorite, the one that I use all of the time and I think is perhaps under-appreciated, which is grep. I mentioned it previously. Grep is like a utility knife for search. [laughs] It has all the various different tools out there that you might need to use. \n\nIt's a fairly simple tool. It searches using simple expressions, generally uses regular expressions. You can specify how much it leans toward regular expression versus just simple text search. Regular expressions are a little mini-language for search that are used widely throughout the software industry, including in tools like grep. \n\nAnd using that tool allowing you to search on the command line is amazing because if I want to search for, say, a string within a set of files, I can use that tool, and maybe I'll get back 10,000 results, way more than I wanted. But then I can pipe that into another usage of grep that reverse filters for some string that's common that I don't actually want in my search. And maybe I'll chain three or four of those together because I'll run it and see my output, like, oh, wait, I've got this other string that is always there when I'm actually looking for just a substring of that. And I'll just keep adding to my chain. \n\nAnd maybe eventually, I'll get to a chain that's 10-long where I'll filter things out that I don't want, starting with something that I do want. And maybe at the end, I add something else that I want, and I'll get back a small set that gives me a list of files. And that chaining is remarkably helpful. And some IDEs, I think, support this idea of chaining. \n\nAnd I think internalizing that idea that I don't have to do it all at once. I can do this in incremental pieces and chain them together to get what I want is remarkably powerful. That is very powerful for grep. But it's also powerful in a lot of other contexts. Thinking about this pipeline of chain commands that progressively filter and transform what you started with leads to an incredibly powerful tool. Any other heavy grep users here?\n\nJASON: I use grep specifically every day. \n\nMIKE: It's a superpower, isn't it? \n\nJASON: It's a time saver. It's nice. That's one of the things that it's kind of funny. I'm starting to see why people transition away from a GUI to command line, or at least now, whereas before, I didn't always have my terminal open. My schooling was in Java, and it wasn't super handy having the terminal open, at least not for me. I wasn't experienced enough. Definitely, now it's constantly open, and I'm, again, starting to see that transition because it's just so much faster. Maybe that's why Ramses could get so much done, superuser.\n\nRAMSES: Yeah, I don't use any graphical interfaces; it's all Vim.\n\nMIKE: It's just so much faster, isn't it? [laughs]\n\nRAMSES: Yeah, incredibly. I've tried to use different graphical interfaces like RubyMine and VS Code, but they just slow me down. \n\nMIKE: That's where it got to for me; I mean, I used to use an IDE all the time. And after using a console-based editor heavily, when I tried to go back, it was painful. [laughs] This is just so slow. There are very good uses of graphical IDEs, though, that can become quite effective. Again, there's more than one way to solve this problem. But people who go to the command line, I think, in general, get very fast. [laughs] It's worth doing. It's worth learning, even if you don't use it all the time. \n\nWe actually had a late joiner who spoke up once, Zack, who works on the data side. I'm very curious because we've got mostly traditional developers. But data has kind of taken over the world in the last few years. So I'd be really interested to hear, Zack, what you would consider some of the most useful tools. You talked about using tools for solving merge conflicts. I would guess that you have several other tools that you might see as vital. If you don't mind, Zack, what you mention might be useful tools from the data side that the rest of us might not be familiar with.\n\nZACK: I use mainly the JetBrains suite as far as IDEs and stuff go, specifically data-side, DataGrip to be able to just access all the databases, look at data like that. I don't necessarily really have tools that go through the data. It's all just queries that I have to write to find outliers and stuff like that. So DataGrip is just extremely helpful.\n\nMIKE: That's interesting. So I'm assuming that SQL is your best friend.\n\nZACK: Yeah. Yeah, yeah. If you take a look at how our scripts function, we use Python, but it's really just like a gateway to SQL. Most of our stuff is just random straight SQL.\n\nMIKE: SQL is SQL, S-Q-L. I'll use whichever one the person I'm talking with uses, [laughs] but it means the same thing. It's not necessarily the latest, greatest, most trendy language, and it's probably got some rough edges even. But what an incredibly powerful tool.\n\nZACK: Yeah. There are very few things, in my opinion, that Python or really any language can do that you can't just do in SQL as well, as it's extremely powerful for that data and never even leaves the warehouse, so you have no network latencies. You have none of that working against you. It's all just happening in the same place.\n\nMIKE: I think that can hardly be overstated. But most operations, if you can keep them in the database rather than bring them to the client side, you will save yourself multiple orders of magnitude of time.\n\nZACK: Yeah. And there's still...with warehousing; it's typically a cluster of machines, whereas I believe maybe our Postgres instances are just one machine. So there's still a little bit of network latency that happens, even processing just within the warehouse. But it's so small because all of those machines are sitting right next to each other. But yeah, you can tell a massive difference if you were to run a query that pulls data out versus just run a query that creates a new table. It's night and day difference for sure.\n\nMIKE: One thing I've noticed working with a data warehouse is that, as a general rule, all queries take a few seconds. You run a simple query to return a few records, and it takes a few seconds. You run some incredibly sophisticated query that does all kinds of complicated things, and it might run a few seconds. [laughs]\n\nZACK: It's kind of funny because those complicated queries that you're talking about will probably return faster for you than SELECT * from, just the way that a columnar database is geared towards a row-based database such as Postgres where the whole row is sitting right next to each other. But, again, in a data warehouse, it has to go search all over disk to go find all the different columns to combine them back together. So the most powerful tool [laughs] in my arsenal is the warehouse, very specific type of database.\n\nMIKE: Yeah, I first started using a columnar database ten years ago or something, and it opens up a whole world of possibilities. When you just have your online transaction processing database, just your standard database, and you want to run some big, ugly query that you know is going to run slow, you pause. Can I really run this, or am I going to take down production? And the answer is, yeah, you probably shouldn't run it. And then your hands are tied. And what do you do?\n\nAnd if you have a replica, then you run the query, and it works. But again, if you're running just a traditional row-based database, it might not ever come back. It might run for several minutes. You just run out of memory. It's not designed for that kind of use case. But when you have this other database that is configured differently and designed for running those big, ugly queries, it's not going to be very fast for, like you say, SELECT *, you know, return this one record. It's going to be slow. You never want to use that for your production database. But if you want to run a report, it's transformational.\n\nZACK: Yeah, it gets really, really powerful once you start separating compute and storage and all that stuff. And you can really have machines that are just specifically made for one purpose rather than just having one machine stood up that's really made to try to handle everything. Plus, just getting distributed computing going is a massive win when it comes to data.\n\nMIKE: And those who haven't used it, it's hard to express the difference between waiting for 20 minutes for a query that times out and waiting 5 seconds then you get your results back. It allows a different cadence to your work. If you can do something 1,000 times a day versus 3, it's a different kind of work. It's fundamentally different in character. Sounds like you're going to say something, Zack.\n\nZACK: Yeah. My last job that I was at, when I started there, they were using a MySQL database as their warehouse. And it was exactly that. I would run a query, and I want to be outside of the range of expectation that it takes 45 minutes for that query to come back to me. And then I'm pretty sure they just had all their settings to negative one, or zero, or whatever, so there was no timeouts going on on those databases. \n\nBut they were also insanely easy to bring down. I had released code there, and for some reason, they were running a five-server leader configuration, which just didn't work at all. I did a code release there, probably my first one that just took down all five of those.\n\nMIKE: Oh.\n\nZACK: Because you had to just write your SQL so perfectly to pull the data outside of those types of databases. And even then, like I said, you're waiting 45 minutes. And that's just the most inefficient way. I'm sitting there for 45 minutes, not able to continue developing my script because I'm just waiting on data to return to me.\n\nMIKE: Going back to what Jason was saying before about the freedom to experiment, you have very limited freedom to experiment in that kind of environment. And that data warehouse gives you the power, the ability to experiment, again, takes the shackles off. Now you're free to go try stuff. \n\nZACK: Exactly, yeah. \n\nMIKE: It's interesting that SQL and data warehouse came up as a vital tool. Do you have anything else that you'd bring up from the data side, or do you think you've covered the key items, Zack?\n\nZACK: I think that I've made the key items. I mean, you're familiar with Dave. He ran the show last week. He also develops inside of the terminal, like you guys were talking about. I would mention that I did end up inside of an IDE. I used to use VS Code. I ended up inside of an IDE, specifically JetBrains, because I started delving in Scala. That all has to compile at runtime. It was so much easier just to press the play button in an IDE than doing anything inside of a terminal. \n\nSo you guys were discussing how the terminal is extremely powerful and faster to use in that way, and I don't disagree like 90% of the time. But I do believe there's that 10% of the time where having [laughs] a UI tooling is just remarkable. Like, I dev Android apps, and I wouldn't want to do that without Android Studio spinning up an emulator for me to work on.\n\nMIKE: That makes sense. And when I was a full-time Java developer, I used the JetBrains suite as well, IntelliJ, all the way. It's an amazing tool.\n\nZACK: It's funny; I really tried to use the terminal. And I was just getting these weird errors in Scala just because it wasn't compile...I was trying to not compile. I was trying to run a scripting language, just read it out and run it instead of compile it down to bytes and run it that way. And as soon as I jumped into IntelliJ and pressed that play button, it all just ran and worked but could not get it to work inside [laughs] of the terminal.\n\nMIKE: It's not that that's an insurmountable problem but, like you say, the ease of use. I'd actually recommend that most new developers use an IDE, use an integrated development environment, a big graphical editor that lets you see things because it's a lower bar to entry. Why not use a powerful tool that makes it easier for you? But learn the command line too. Treat that as a goal. While you've done the easier thing, try using some of the command-line tools. Try experimenting with them here and there over time.\n\nZACK: I agree with that as well. I spend a lot of time in the command line. And I spent a lot of time early on through college working in networking and setting up headless machines that you just had to SSH into so there was no GUI that you could work with. And through that time, the three big ones that I would say if you know these, you can do just about anything would be Grep, as we discussed, sed, and awk.\n\nMIKE: I use sed a lot. I need to use awk more. It's also a remarkably capable tool.\n\nZACK: Yeah. And that's one that I never really use a lot, either. [laughter] I never really hit cases where grep, and sed just didn't work for me. \n\nMIKE: Exactly.\n\nZACK: And on the rare occasions I did, it was just like, I'd Google to figure out what command it is, and it was [laughter] typically awk.\n\nMIKE: That's pretty much where I'm at. [laughs] Grep and sed encompass almost everything. And then awk, you know, that's what Google is for. [laughs] \n\nWe're reaching the end of our scheduled time, but to go back and summarize, we've talked about some powerful tools over on the data side, specifically, data warehouse using SQL or SQL, whichever you prefer, you want to call it. We've talked about command-line tools, particularly grep. And we talked about the value of version control system. We talked about Git and the value of IDEs. And the commercial product from the JetBrains suite of commercial products are really very good tools, as well as VS Code, which has become very widespread within the industry. \n\nHopefully, if you're listening, you've got some great ideas of things you might want to try. Is there anybody else who wants to put in a plug for a tool that we haven't covered or talk about some concepts we touched on, and you really want to dig in a little further?\n\nKYLE: I realized when Zack was going over tooling that they use in data, I didn't really talk about some of the major ones we use in DevOps, which is I would throw out TerraForm, Kubernetes. Those tools specifically because...TerraForm is how we manage all of our clusters and all of our infrastructure out in AWS and Google and wherever that's managed.\n\nZACK: Just another one, real fast; Kyle reminded me when he brought up Kubernetes is we have started using a tool called Argo. It's a workflow management tool: also extremely important. In your normal software and engineering environment, you have typically something that happens that causes an event stream that runs through and kicks off whatever endpoints or whatever needs to be kicked off. A lot of times, with data, you just have to schedule that. So we use Crontab as well as Argo to schedule our jobs to run.\n\nMIKE: Cool.\n\nKYLE: Last plug, Docker. Docker has to be mentioned.\n\nMIKE: Yes. [laughs]\n\nJASON: The debate rages on.\n\nMIKE: [laughs]\n\nMARK: In Docker's favor.\n\n[laughter]\n\nMIKE: So I'll hopefully tone down some of that debate by saying that Docker is widely used in production and even on production deployments. In cloud deployments, having containerized code is just incredibly useful. For local development, I think there's a lot more debate as to whether you just want to run bare metal or whether you want to run containerized. Is that what you're touching on, Jason?\n\nJASON: Yeah, just locally, obviously, it's resource-heavy, but I absolutely see the kind of the compartmentalization; like you said, the whole point is to run in containers. I can see where in a production environment, that's extremely useful. But yeah, there's been a lot of debate here at Acima over whether Docker is...if we should rely on that for local development, just the memory requirements, basically.\n\nMIKE: You know, interestingly, we do rely on Docker, many of us, for local development, even if we're not thinking about it because we'll connect to cloud instances for some of our services, which are built using Docker.\n\nZACK: I was going to say my argument for running Docker locally, at least from what I've found, is it only uses the resources that are needed for that, which for my team is really easy because it's only using resources if we're running a script. As well as it's been extremely helpful to have a development environment that is pretty much a one-to-one to production. You don't get any of the sneaky, like, oh, it's failing in production, and I have no idea why it's going on. It will fail on your local machine if it's going to fail in production.\n\nMIKE: It's wonderful to be able to compare.\n\nKYLE: I think that is one benefit with Docker that is a little bit overlooked is we get this response from devs sometimes, you know when something is deployed, and it's...well, it worked on my machine. Well, that's great, but we can't put your machine in AWS. However, if you give us a Docker image, we can put that in AWS, and that's the same image that will be running on your machine as will be running on a machine out in AWS. \n\nMIKE: That's a big deal, that consistency.\n\nZACK: If you look at toolings before Docker, it's not a new idea of trying to match local to production environments. Before that, there was Vagrant, which admittedly was maybe a little bit of a shit show; hard to manage but definitely been going for that for a long time. And I think Docker kind of hit the nail on the head with it.\n\nMIKE: It's becoming remarkably successful and integral to a lot of what we do for a reason. It kind of takes the virtualization idea to its logical extreme. Let's strip out everything extraneous and have just what we need but everything that we need. All of your system libraries and your application that depend on them; we'll put that in a bundle and nothing else. It's a powerful, powerful way to approach deployment and even local development to get that consistency.\n\nMARK: Docker has also been great for privacy and so forth. I know recently I discovered that you can run full-blown browsers within Docker and then access those browsers from your other browser. So I can have, say, 30 Firefox containers in Docker and have each container for a specific reason. So instead of creating profiles on my main computer for everything I want, I could have containerized Firefox applications for what websites I go to, which I believe is a great plus for security and not just development means.\n\nMIKE: Yeah, if nothing else, you can segregate home from work. [laughs]\n\nKYLE: I will say one thing that I've found developing in Docker is I tend to really kind of mess my machine up, and a local machine that requires a lot of debugging and figuring out what have you done and backtracking. The Docker image, use it, abuse it, throw it away, start up a new image.\n\nJASON: I think that's a huge selling point for me going back to what we were talking about before with the freedom to experiment. I think that's pretty powerful.\n\nMIKE: Well, it sounds like a good place to tie this up. There are a variety of tools that give you that power to experiment, and they've been coming up repeatedly. Docker and Git were mentioned particularly in that regard of the data warehouse. Anything that allows you to try something without breaking things is going to make your workflow much more powerful. \n\nThank you for joining us today. And, hopefully, we gave you some ideas for things that you can go use yourself. And I don't know if we'll be seeing you, but you'll be hearing us next time on the Acima Development Podcast. Thank you.","content_html":"We're calling out the most valuable development tools and tricks.
\n\nTranscript:
\n\nMIKE: Welcome to another episode of our Acima Development Podcast. I'm Mike. I'll be hosting today. And today, we're going to be talking about development tools and tricks. Before I do that, I'd like to go around and have everybody briefly introduce themselves. Mark, do you want to introduce yourself?
\n\nMARK: Hello, my name is Mark. I'm an intern for the summer.
\n\nMIKE: Thank you. Jason.
\n\nJASON: My name is Jason. I've been developing for about six months now. I started as a developer here in Acima.
\n\nMIKE: Great, thank you. Ramses.
\n\nRAMSES: Hello, hello. I have also been a software developer now with Acima for about six months.
\n\nMIKE: Great. And Kyle.
\n\nKYLE: Hey. Kyle, DevOps Engineer, been doing that here at Acima for about five years.
\n\nMIKE: So now that we've introduced ourselves, I wanted to start with not quite a story; it's an example. I'm interested in pedagogy, in teaching, in the science of teaching, and I've read quite a bit about math teaching in particular. There's a popular technique that has become more popular in the most recent few years to help children develop the appropriate mindset, and it works for adults as well, develop an appropriate mindset for math because, a lot of times, we're taught mindsets that are not very helpful.
\n\nLearning math by rote, in particular, tends to lead to difficulty solving novel problems. You run into a new problem like "Oh, now what do I do?" And professional mathematicians approach math very differently than how it's often taught in schools. For them, math is art and creativity, and looking for interesting new ways to approach problems, where a lot of people who are taught math in school are taught very differently, where here's your problem; here's the technique for solving the problem. And that's the one way to do it.
\n\nSo in order to develop a better mindset, a more flexible mindset for teaching, they do what they call number talks or math talks, where you present a math problem that you can solve in your head with some challenge. How would you add 23+84 in your head? And you ask a class of 30 kids this, and you get like 32 answers. [laughs] Everybody does it a little bit different. And I may be exaggerating a little bit because you'll tend to have common themes.
\n\nBut it's remarkable how people will come up with very different ways of doing it; some people will add the tens first and then the ones. Some people will try to get to easy numbers like multiples of 25, or multiples of 5, or multiples of 10 and then balance out the numbers accordingly. Some people might go to 100, you know, they work around boundaries like that. There are lots of different ways that people can approach problems, a surprising number of ways people can approach those kinds of problems.
\n\nAnd once you hear all the other different ways, you're like, wow, I thought there was only one way of doing it, and I thought that it was just my way. And it turns out there are many different ways of solving the problem. It's worth looking up if you're ever interested in thinking about it. It's fun to try it with a group of friends. Just come up with a problem like that. Just do some addition or some multiplication that you can do in your head with a bit of challenge, and ask other people how they do it. And you'll likely be surprised how many different ways people do it.
\n\nI used this introduction to come into software development tools because, coming into the industry, you might think there's one way to do this. But our industry is a creative industry. Our job is not to follow a set of rules but to solve problems. I'll repeat that repeatedly, and I've probably mentioned it other times I host the podcast because there's a misconception sometimes that our job is writing code, which is not really true. Our job is to solve problems.
\n\nAnd there are a lot of ways to solve the problem. And you may have people who approach the problem in very different ways and come up with a great solution through very different techniques. And that doesn't mean that one is right and one is wrong. So there's some real value in seeing a variety of ways to find out what works for you. There's not necessarily a right answer. Sometimes there may be solutions that are not very good, and it's good to recognize those.
\n\nBut, in general, there's a lot of gray area there. There's a lot of flexibility and areas where there's not really a right or wrong answer, just a variety of answers. And having a whole toolbox with the tools rather than just one hammer is going to give you a lot of power to do things differently and likely do things better because you can reach for a variety of tools and find the right one for the right place. And you may find that your personal preferences lead to different approaches from what other people do.
\n\nI'm going to lead by saying that I am very much a minimalist. I used to use big IDE when I was a Java developer years ago. That's pretty common in the Java world. And I did a lot of remote server administration for a while. I started using command-line editors and just stuck. So I'm a Vim user, primarily, and have been for a number of years, which is just a command-line editor. I never leave the terminal. I rarely leave Vim because I can execute commands from right inside Vim.
\n\nI don't have a lot of plugins and just use the standard Linux or Unix toolset that is available from the command line to do my searching, and I find it extremely effective. I'm able to navigate around and find what I need very quickly. Others use a big toolset and are able to also navigate around files and find things very quickly. I'm not going to say one is better than the other because I think they both have merits.
\n\nSo I'm going to start with just saying I tend to be a minimalist. I'm curious where other people are at because other people have their own tools that are very useful. I will say that knowing at least one command-line editor...and the two big capable command-line editors are generally Vim and Emacs. It's a surprising superpower. It takes some doing to learn. But those tools allow you to accomplish a lot with a little. And even if you don't get really good at them, it's nice to have those in your tool belt so that you can accomplish something.
\n\nSo if I were going to start by saying a very useful tool, I would recommend learning a command-line editor. And if you want an easy introduction, there are very easy command-line editors you can start with, like Nano, which is a simple editor that once you get into, you'll be able to see how to get out, unlike Vim. [laughs] And you can get started that way. I think there's a lot of value in using those command-line tools.
\n\nI would like to talk more about the incredible value of the command-line tools that come from Unix, particularly grep. Grep is the open version of this that's widely used on Linux that I think are invaluable for myself in my tools. But I don't want to talk the whole time. So I wanted to lead with that, talk about the importance of a variety of tools and start my take on useful tools by saying to anybody that command-line tools are, in general, incredibly valuable.
\n\nAnd I'll talk a bit more about that in a minute. But I'd like to hear what other people have to say about what, you know if you were to just...if somebody was to ask you, "What is most valuable to you?" what would you say is the most valuable tool?
\n\nKYLE: I'll have to agree with you on the Vim subject. And I have been around the Emacs people as well. And I feel like that requires a different set of joints in your finger to use that tool.
\n\nMIKE: [laughs]
\n\nKYLE: But I come from the other side of the fence as well, though, because starting out in QA, a lot of the tooling that I was introduced to that made my job easier and flow well was all GUI-related and Git from a UI and stuff like that. The transition to using something like Vim, I wouldn't say I'm any kind of expert. But I feel like it's made my job so much easier in the sense that there is native tooling, like you were saying, grep, and everything in Linux and Unix that you're able to do that's even cross-platform.
\n\nA lot of what you're going to find on Linux is available on a macOS or even in the later versions of Windows. Now you have that ability as well, either through PowerShell or through the Linux Subsystem that they have now. It's just I do feel like my productivity has increased. And the scripting and the tooling that you're able to use, even with just a Bash application, you can just do a lot that you can still do with a UI as long as you're really familiar with the tool.
\n\nMIKE: A lot of things you can. There are some things that are actually remarkably difficult, if not impossible, to do from a UI. I don't want to get to the punch line because [laughs] I want to hear what a couple of people have to say. But I'd like to grab back onto that thread because I am with you completely that it is useful, and you can do it from a UI if you're familiar with it. But there are some things that I think you can't in most UIs to accomplish. Again, I'm going to come back to that. I'm curious. Jason, I think you were going to say something.
\n\nJASON: Yeah, I think it was drifting a little further off-topic from a specific IDE. But a really useful tool that I had when I came on, Johnny actually pointed out. And basically, he showed me where I can customize methods anywhere. I run Pry or anywhere I run an IRB console. So just knowing where you can add those custom methods is really a time saver and kind of lends itself to what you're saying, you know, running things from a command-line editor or a GUI.
\n\nRight now, I'm using RubyMine. It seems to be popular with a lot of the devs and has a lot of useful tools, and being newer, that is helpful. There are a lot of helpful hints there. But yeah, being able to modify your pryrc file or irbrc file to add some custom methods to help you save time has been big for me.
\n\nMIKE: Thank you. And anybody listening who's not a Rubyist, Pry is a popular Ruby debugger. You can use it on the command line.
\n\nZACK: So one of the big things that have always gotten me throughout my development career is merge conflicts. And the tool that I found that I've just hooked into the terminal so I can just run git merge tool and pops up is Meld. I don't know if any of you guys have ever used that before. It kind of does pop up like a UI for you with some easy arrows to just kind of push and create one file with the right edits to it. And it's been kind of a lifesaver as far as merge conflicts have gone.
\n\nMIKE: Merge conflicts are the bane of development. [laughs] Anything you can find that is useful for those is good. We could have a whole episode on Git and ways to deal with merge conflicts and avoid them before they ever happen. Thank you. Anybody else who wants to share a tool that just really is the best one that they use?
\n\nMARK: For me, it'd be VS Code open-source code editor that you can pretty much do anything you want in. And the only problem I would give with it is that there are sometimes troubles with its terminal. But besides that, I find it's a great source for editing code as well as the ability to customize the interface and so forth and style it as you like.
\n\nMIKE: I feel like VS Code has kind of taken over the world. [laughter] It seems to have become the editor of choice for a lot of people
\n\nMARK: Well, more and more people are pushing for open-source products. I think Germany swapped all their government computers to Linux. Or was it that they put their whole school system on Nextcloud?
\n\nMIKE: I know there have been several experiments in Europe like that. I haven't followed it really closely. Definitely, you know, open source is helpful. And they've got a big corporate backer for VS Code as well, so it keeps it going. And we've also got some interesting integrations now with Copilot, some very interesting things with that IDE. They're very cool. So there's a lot of innovative stuff going on with VS Code. And it seems to be where a lot of the energy of the industry is.
\n\nKYLE: Just wanted to pop in and say something about VS Code just because that is another tool that we heavily use with DevOps because, once again, it integrates with everything under the kitchen sink. Just...and, Mark, I don't know if you've tried it or not, but you can basically use any terminal with VS Code. You just have to go into the settings and pick which one you're wanting to use if that helps you out at all.
\n\nMARK: I'm aware. It's just there are some times where I've run into a permissions issue where it'll say, "The terminal within VS Code has less permissions," then just pulling up the terminal app.
\n\nKYLE: Ah, okay, yeah. It can be limiting at times.
\n\nMIKE: Well, with that segue going back to terminal, I want to revisit this idea of command-line tooling versus user interface. There is a philosophy embraced by the Unix operating system. Nobody...well, I say nobody...the original Unix operating system birthed many children. And while pure Unix is not that widespread anymore, it has many of these children. I believe that macOS is formally certified as a Unix and meets the requirements for Unix, even though it has a very different underlying system.
\n\nAnd Linux is Unix-ish in its approach, even if it was built from scratch. And it's taken over the world. Android runs on a Linux base. I'm actually not that familiar with iOS, and it wouldn't surprise me if they used something similar. Because most of the devices out there in the world run some Unix-inspired operating system, and I think there's a reason for that. There's a Unix philosophy that says the tools should be small, single-purpose, and composable, all of which are important.
\n\nI say small, meaning that they don't do all of the things, although some of the...like an editor, maybe does a lot of things. Emacs, there's very little it can't do. [laughs] Some people see it as unwieldy, but it's a very powerful tool. But most of the tools they use are single-purpose. You might have a tool, for example, that counts characters or a tool that just runs regular expressions to search for text within a string.
\n\nAnd the single-purpose tools are composable in that Unix allows you to create what they call a pipe, which sends the output from one command as the input to the next command, allowing you to chain commands together and compose an arbitrary number. And you can put 50 of them together. There's no real preset limit. You can take the output from one command and put it as the input into another. And, okay, that sounds simple enough, but it is radically more powerful than other approaches, and I'd argue that emphatically.
\n\nBecause if you've got a graphical tool that lets you do a thing, maybe it lets you do a sophisticated thing, you can get whatever you can get from that one tool. But instead, if you have a simple tool, instead of doing some very sophisticated thing, it does one thing well. And it allows you to compose it with other things that would accomplish the same thing.
\n\nYou can almost always do what you're able to do with that graphical tool but then take the output of it and send it to another tool. So you can take your sum that you got from the first tool and send it into the next thing to do some math on, and then send it to the next tool to print it out to a file, write it to a file, and then you can even send that file as an email. You can chain these tools together to come up with a very sophisticated workflow.
\n\nA lot of times, just in development, you want to do simple things. What if I want to look for all the files that have a particular extension and, for each of those, search for a particular line of text, and then compile all of those files into a list and open them up in my editor? I do things like that all the time using my command-line tools. It is very useful. And that's something that's actually very challenging to do using a graphical tool and may not be even possible in most of the tools that you use unless you've learned how to use some obscure tricks in the edges of it.
\n\nAnd that's why I say that these command-line tools are, I think, underappreciated, and the most important tool, I think, that is worth developing and getting in your tool belt as a developer because they are much more powerful than most other tools available and faster as well. And, Kyle, you talked a little about the power of command-line tools. Has that been consistent with your experience?
\n\nKYLE: Yeah, that's along the lines of what I've experienced, too. I was actually sitting here thinking, as you were talking, there are CLIs for everything almost. And, I mean, if you're looking at a...not to bash on any particular company, but you go in, and you'll see a UI, and you'll familiarize yourself with the UI. And then four months later, if we're looking at long-term or whatever, you go in there, and it's like, oh, we've got a new look. And you're like, well, that's great, but where's this setting, or where's this feature that I was looking for, right?
\n\nMIKE: Right.
\n\nKYLE: And with a CLI, I've found that doesn't change; that's constant. They may add features, but they don't really move them around. And I feel like that's another power of the command line, if you want to say, is each of these companies are making CLIs that they will do the same thing, call the same APIs is what, you know, either their application or web interface will do. And you're able to do a lot of the same stuff easier and faster than you might be able to even find it in the UI.
\n\nMIKE: I agree 100%. Just anybody listening who's not familiar with the lingo, when we say CLI, we're talking about a command-line interface and using something from the command line. I'd ask that further, Kyle, from the DevOps perspective, which would you rather have: configuration files that you can manage through Git or, I guess, there are other source control tools, but nobody...I'm not going to say nobody uses them [laughs], but Git has kind of dominated source control. Would you rather have configuration files and scripts managed in source control or a pipeline managed in a graphical user interface?
\n\nKYLE: I avoid a graphical interface as often as I can. It's all about having configuration management.
\n\nMIKE: Yeah, there's a reason that DevOps has become central to, I think, most effective software companies. They treat configuration as code and use the same powerful tools that we use in development to great effect.
\n\nKYLE: It's just one of those situations where, I mean, here at Acima, we've got...what is it? Five or six environments. And so, I can either go in and configure each environment through the UI, or I can configure one environment in configuration and apply it to every environment with a quick script. And it's which one would you rather do? Which one's going to save the company money and make you look better in the long run?
\n\nMIKE: [laughs] Absolutely. We touched on something there that we didn't dig into. We've been talking about command-line tools and their great utility. We talked a little about Linux. But there's another incredibly powerful tool written by the same guy, Linus Torvalds, who gave us Linux. Linus Torvalds started Linux [laughs] but has personally not, by any stretch of the imagination, written most of it. His gift to the community was planting that seed and starting that community, which together builds a remarkable tool.
\n\nHe also started another tool that has become fundamental to, I think, most development companies out there which is Git. It's kind of a silly name, incredibly useful tool. [laughs] And maybe it'll be superseded by some other tool in the future, but for now, I think Git sort of reigns supreme. You can use graphical interfaces for Git. I actually don't, like, ever [laughs] because its command-line interface is very powerful. But graphical interface, there's nothing wrong with them; they work great.
\n\nAnd having that powerful version control system is, I would say, a vital tool for effective development. Those of us who have used, I would say, inferior or simpler tools in the past know the treasure of everything that Git is. And Git is actually, at its core, a pretty simple idea, which is instead of having a central repository that has a single point of failure, everybody keeps everything.
\n\nYou keep a history of all of the changes that have ever happened to your project. So you have basically a stream of events that are signed so that you can verify them, going back all the way through the history of a project back to the beginning. And everybody keeps that. And by having it distributed, it's very hard to lose very much that's important.
\n\nMaybe you've been working on a project for a couple of days and kept it on your own machine and didn't share it out with the community, and maybe you'd lose that. You don't need to. You can push up your changes hourly, and then you're unlikely to ever lose very much, and certainly not the whole project. And Git manages that distributed system of multiple copies repository and manages to handle it very well. And in doing so, it has become a central tool to most development. And there are business models built on top of this open-source tool, such as GitHub. What would your lives be like without Git?
\n\nMARK: A big pain in the ass for managing.
\n\nMIKE: [laughs] Yeah.
\n\nJASON: A lot of re-dos.
\n\nMARK: We'd probably have something like daily merge meetings just to begin work together to merge all our changes on everyone's devices.
\n\nMIKE: Oh. I think that's exactly right. You'd do daily merge meetings, and you'd have to carefully coordinate. [laughs] Let's make sure that you never touch the same code as somebody else. And it would all have to be done by direct communication. You'd have to talk to somebody first to coordinate that. No easy way to handle conflicts when you both accidentally change the same file. Nightmare. [laughs]
\n\nIf you're starting out at development, start using a version control system. It will serve you well. It will save you pain, as Mark said, and re-dos, as Jason said, more times than you will ever count. It's just a remarkable tool. And there are some other systems out there. Git is the most popular and extremely useful. There are a couple; like I said, there are a couple others. Mercurial is used somewhat. It has its own following.
\n\nJASON: One added benefit to that is you can have kind of this fearless sense of I can experiment, do whatever I want. I'll just create a new branch and experiment and see if it works.
\n\nMIKE: And it changes your mindset, doesn't it?
\n\nJASON: Absolutely, yeah. Also, this discussion is kind of interesting because I never really thought of source control giving you that liberty. I'm not afraid to touch any file. I can do anything that I need to so long as I'm not modifying something else, like a database that could set me back, but even that, you can reset to a better state.
\n\nMIKE: I love where you went there. It gives you freedom to experiment. Freedom to experiment is one of the most important things for being able to be effective as well. It's closely related to the idea of psychological safety, which research has shown to be the central characteristic of effective teams and effective developers. If you can feel free to experiment without harsh consequences, then you're going to, and trying new things is how you get things done. I think we could talk about this for some time.
\n\nI saw a wonderful presentation at a conference once talking about luck. And I'm going to summarize the presentation, and you can go and look it up yourself. But there was some research done about what makes people lucky. They asked people who of their friends was lucky. So they characterized a group of people who were considered lucky by others. And they figured out what was different between these lucky people and other people to actually research what makes a person lucky. And you can figure out what the difference is.
\n\nIt turns out that the key differentiator between lucky people and people who are not so fortunate is that the lucky people try new things. And when I heard that, I maybe paused; oh, really? I've thought about that a lot since. If I want to be lucky, I got to try new things. You're never going to have a different experience unless you're trying new things. Yes, you can have some bad experiences too, [laughs] but you're never going to get something that will take you to the next level, have that moment of serendipity unless you are putting yourself in a position where you can. Git allows you to be lucky.
\n\nKYLE: Just a side thought on this as we're talking. I almost feel like Git, or a tool like Git, is partially why some of us can be employed I feel like. Because I just feel like if you didn't have a tool like that, large development teams would be a burden more than anything. You'd have small, concise teams that don't, you know, one dude is working on something, and then the other person is working on something else. And they can quickly merge things.
\n\nAnd we wouldn't be able to have 7, 10 developers, whatever, working on the same service because they would be having those conflicts, and it would be just a managing nightmare. So I think part of this is that it gives us that parallelism to allow more developers to be employed to deliver faster and everything.
\n\nMIKE: Well-spoken. Going back again to that capacity, it'd be utterly unmanageable without the tool.
\n\nWe've talked a lot about the power of the command line and the power of version control. I think I mentioned one command-line tool that, for me, is perhaps my favorite, the one that I use all of the time and I think is perhaps under-appreciated, which is grep. I mentioned it previously. Grep is like a utility knife for search. [laughs] It has all the various different tools out there that you might need to use.
\n\nIt's a fairly simple tool. It searches using simple expressions, generally uses regular expressions. You can specify how much it leans toward regular expression versus just simple text search. Regular expressions are a little mini-language for search that are used widely throughout the software industry, including in tools like grep.
\n\nAnd using that tool allowing you to search on the command line is amazing because if I want to search for, say, a string within a set of files, I can use that tool, and maybe I'll get back 10,000 results, way more than I wanted. But then I can pipe that into another usage of grep that reverse filters for some string that's common that I don't actually want in my search. And maybe I'll chain three or four of those together because I'll run it and see my output, like, oh, wait, I've got this other string that is always there when I'm actually looking for just a substring of that. And I'll just keep adding to my chain.
\n\nAnd maybe eventually, I'll get to a chain that's 10-long where I'll filter things out that I don't want, starting with something that I do want. And maybe at the end, I add something else that I want, and I'll get back a small set that gives me a list of files. And that chaining is remarkably helpful. And some IDEs, I think, support this idea of chaining.
\n\nAnd I think internalizing that idea that I don't have to do it all at once. I can do this in incremental pieces and chain them together to get what I want is remarkably powerful. That is very powerful for grep. But it's also powerful in a lot of other contexts. Thinking about this pipeline of chain commands that progressively filter and transform what you started with leads to an incredibly powerful tool. Any other heavy grep users here?
\n\nJASON: I use grep specifically every day.
\n\nMIKE: It's a superpower, isn't it?
\n\nJASON: It's a time saver. It's nice. That's one of the things that it's kind of funny. I'm starting to see why people transition away from a GUI to command line, or at least now, whereas before, I didn't always have my terminal open. My schooling was in Java, and it wasn't super handy having the terminal open, at least not for me. I wasn't experienced enough. Definitely, now it's constantly open, and I'm, again, starting to see that transition because it's just so much faster. Maybe that's why Ramses could get so much done, superuser.
\n\nRAMSES: Yeah, I don't use any graphical interfaces; it's all Vim.
\n\nMIKE: It's just so much faster, isn't it? [laughs]
\n\nRAMSES: Yeah, incredibly. I've tried to use different graphical interfaces like RubyMine and VS Code, but they just slow me down.
\n\nMIKE: That's where it got to for me; I mean, I used to use an IDE all the time. And after using a console-based editor heavily, when I tried to go back, it was painful. [laughs] This is just so slow. There are very good uses of graphical IDEs, though, that can become quite effective. Again, there's more than one way to solve this problem. But people who go to the command line, I think, in general, get very fast. [laughs] It's worth doing. It's worth learning, even if you don't use it all the time.
\n\nWe actually had a late joiner who spoke up once, Zack, who works on the data side. I'm very curious because we've got mostly traditional developers. But data has kind of taken over the world in the last few years. So I'd be really interested to hear, Zack, what you would consider some of the most useful tools. You talked about using tools for solving merge conflicts. I would guess that you have several other tools that you might see as vital. If you don't mind, Zack, what you mention might be useful tools from the data side that the rest of us might not be familiar with.
\n\nZACK: I use mainly the JetBrains suite as far as IDEs and stuff go, specifically data-side, DataGrip to be able to just access all the databases, look at data like that. I don't necessarily really have tools that go through the data. It's all just queries that I have to write to find outliers and stuff like that. So DataGrip is just extremely helpful.
\n\nMIKE: That's interesting. So I'm assuming that SQL is your best friend.
\n\nZACK: Yeah. Yeah, yeah. If you take a look at how our scripts function, we use Python, but it's really just like a gateway to SQL. Most of our stuff is just random straight SQL.
\n\nMIKE: SQL is SQL, S-Q-L. I'll use whichever one the person I'm talking with uses, [laughs] but it means the same thing. It's not necessarily the latest, greatest, most trendy language, and it's probably got some rough edges even. But what an incredibly powerful tool.
\n\nZACK: Yeah. There are very few things, in my opinion, that Python or really any language can do that you can't just do in SQL as well, as it's extremely powerful for that data and never even leaves the warehouse, so you have no network latencies. You have none of that working against you. It's all just happening in the same place.
\n\nMIKE: I think that can hardly be overstated. But most operations, if you can keep them in the database rather than bring them to the client side, you will save yourself multiple orders of magnitude of time.
\n\nZACK: Yeah. And there's still...with warehousing; it's typically a cluster of machines, whereas I believe maybe our Postgres instances are just one machine. So there's still a little bit of network latency that happens, even processing just within the warehouse. But it's so small because all of those machines are sitting right next to each other. But yeah, you can tell a massive difference if you were to run a query that pulls data out versus just run a query that creates a new table. It's night and day difference for sure.
\n\nMIKE: One thing I've noticed working with a data warehouse is that, as a general rule, all queries take a few seconds. You run a simple query to return a few records, and it takes a few seconds. You run some incredibly sophisticated query that does all kinds of complicated things, and it might run a few seconds. [laughs]
\n\nZACK: It's kind of funny because those complicated queries that you're talking about will probably return faster for you than SELECT * from, just the way that a columnar database is geared towards a row-based database such as Postgres where the whole row is sitting right next to each other. But, again, in a data warehouse, it has to go search all over disk to go find all the different columns to combine them back together. So the most powerful tool [laughs] in my arsenal is the warehouse, very specific type of database.
\n\nMIKE: Yeah, I first started using a columnar database ten years ago or something, and it opens up a whole world of possibilities. When you just have your online transaction processing database, just your standard database, and you want to run some big, ugly query that you know is going to run slow, you pause. Can I really run this, or am I going to take down production? And the answer is, yeah, you probably shouldn't run it. And then your hands are tied. And what do you do?
\n\nAnd if you have a replica, then you run the query, and it works. But again, if you're running just a traditional row-based database, it might not ever come back. It might run for several minutes. You just run out of memory. It's not designed for that kind of use case. But when you have this other database that is configured differently and designed for running those big, ugly queries, it's not going to be very fast for, like you say, SELECT *, you know, return this one record. It's going to be slow. You never want to use that for your production database. But if you want to run a report, it's transformational.
\n\nZACK: Yeah, it gets really, really powerful once you start separating compute and storage and all that stuff. And you can really have machines that are just specifically made for one purpose rather than just having one machine stood up that's really made to try to handle everything. Plus, just getting distributed computing going is a massive win when it comes to data.
\n\nMIKE: And those who haven't used it, it's hard to express the difference between waiting for 20 minutes for a query that times out and waiting 5 seconds then you get your results back. It allows a different cadence to your work. If you can do something 1,000 times a day versus 3, it's a different kind of work. It's fundamentally different in character. Sounds like you're going to say something, Zack.
\n\nZACK: Yeah. My last job that I was at, when I started there, they were using a MySQL database as their warehouse. And it was exactly that. I would run a query, and I want to be outside of the range of expectation that it takes 45 minutes for that query to come back to me. And then I'm pretty sure they just had all their settings to negative one, or zero, or whatever, so there was no timeouts going on on those databases.
\n\nBut they were also insanely easy to bring down. I had released code there, and for some reason, they were running a five-server leader configuration, which just didn't work at all. I did a code release there, probably my first one that just took down all five of those.
\n\nMIKE: Oh.
\n\nZACK: Because you had to just write your SQL so perfectly to pull the data outside of those types of databases. And even then, like I said, you're waiting 45 minutes. And that's just the most inefficient way. I'm sitting there for 45 minutes, not able to continue developing my script because I'm just waiting on data to return to me.
\n\nMIKE: Going back to what Jason was saying before about the freedom to experiment, you have very limited freedom to experiment in that kind of environment. And that data warehouse gives you the power, the ability to experiment, again, takes the shackles off. Now you're free to go try stuff.
\n\nZACK: Exactly, yeah.
\n\nMIKE: It's interesting that SQL and data warehouse came up as a vital tool. Do you have anything else that you'd bring up from the data side, or do you think you've covered the key items, Zack?
\n\nZACK: I think that I've made the key items. I mean, you're familiar with Dave. He ran the show last week. He also develops inside of the terminal, like you guys were talking about. I would mention that I did end up inside of an IDE. I used to use VS Code. I ended up inside of an IDE, specifically JetBrains, because I started delving in Scala. That all has to compile at runtime. It was so much easier just to press the play button in an IDE than doing anything inside of a terminal.
\n\nSo you guys were discussing how the terminal is extremely powerful and faster to use in that way, and I don't disagree like 90% of the time. But I do believe there's that 10% of the time where having [laughs] a UI tooling is just remarkable. Like, I dev Android apps, and I wouldn't want to do that without Android Studio spinning up an emulator for me to work on.
\n\nMIKE: That makes sense. And when I was a full-time Java developer, I used the JetBrains suite as well, IntelliJ, all the way. It's an amazing tool.
\n\nZACK: It's funny; I really tried to use the terminal. And I was just getting these weird errors in Scala just because it wasn't compile...I was trying to not compile. I was trying to run a scripting language, just read it out and run it instead of compile it down to bytes and run it that way. And as soon as I jumped into IntelliJ and pressed that play button, it all just ran and worked but could not get it to work inside [laughs] of the terminal.
\n\nMIKE: It's not that that's an insurmountable problem but, like you say, the ease of use. I'd actually recommend that most new developers use an IDE, use an integrated development environment, a big graphical editor that lets you see things because it's a lower bar to entry. Why not use a powerful tool that makes it easier for you? But learn the command line too. Treat that as a goal. While you've done the easier thing, try using some of the command-line tools. Try experimenting with them here and there over time.
\n\nZACK: I agree with that as well. I spend a lot of time in the command line. And I spent a lot of time early on through college working in networking and setting up headless machines that you just had to SSH into so there was no GUI that you could work with. And through that time, the three big ones that I would say if you know these, you can do just about anything would be Grep, as we discussed, sed, and awk.
\n\nMIKE: I use sed a lot. I need to use awk more. It's also a remarkably capable tool.
\n\nZACK: Yeah. And that's one that I never really use a lot, either. [laughter] I never really hit cases where grep, and sed just didn't work for me.
\n\nMIKE: Exactly.
\n\nZACK: And on the rare occasions I did, it was just like, I'd Google to figure out what command it is, and it was [laughter] typically awk.
\n\nMIKE: That's pretty much where I'm at. [laughs] Grep and sed encompass almost everything. And then awk, you know, that's what Google is for. [laughs]
\n\nWe're reaching the end of our scheduled time, but to go back and summarize, we've talked about some powerful tools over on the data side, specifically, data warehouse using SQL or SQL, whichever you prefer, you want to call it. We've talked about command-line tools, particularly grep. And we talked about the value of version control system. We talked about Git and the value of IDEs. And the commercial product from the JetBrains suite of commercial products are really very good tools, as well as VS Code, which has become very widespread within the industry.
\n\nHopefully, if you're listening, you've got some great ideas of things you might want to try. Is there anybody else who wants to put in a plug for a tool that we haven't covered or talk about some concepts we touched on, and you really want to dig in a little further?
\n\nKYLE: I realized when Zack was going over tooling that they use in data, I didn't really talk about some of the major ones we use in DevOps, which is I would throw out TerraForm, Kubernetes. Those tools specifically because...TerraForm is how we manage all of our clusters and all of our infrastructure out in AWS and Google and wherever that's managed.
\n\nZACK: Just another one, real fast; Kyle reminded me when he brought up Kubernetes is we have started using a tool called Argo. It's a workflow management tool: also extremely important. In your normal software and engineering environment, you have typically something that happens that causes an event stream that runs through and kicks off whatever endpoints or whatever needs to be kicked off. A lot of times, with data, you just have to schedule that. So we use Crontab as well as Argo to schedule our jobs to run.
\n\nMIKE: Cool.
\n\nKYLE: Last plug, Docker. Docker has to be mentioned.
\n\nMIKE: Yes. [laughs]
\n\nJASON: The debate rages on.
\n\nMIKE: [laughs]
\n\nMARK: In Docker's favor.
\n\n[laughter]
\n\nMIKE: So I'll hopefully tone down some of that debate by saying that Docker is widely used in production and even on production deployments. In cloud deployments, having containerized code is just incredibly useful. For local development, I think there's a lot more debate as to whether you just want to run bare metal or whether you want to run containerized. Is that what you're touching on, Jason?
\n\nJASON: Yeah, just locally, obviously, it's resource-heavy, but I absolutely see the kind of the compartmentalization; like you said, the whole point is to run in containers. I can see where in a production environment, that's extremely useful. But yeah, there's been a lot of debate here at Acima over whether Docker is...if we should rely on that for local development, just the memory requirements, basically.
\n\nMIKE: You know, interestingly, we do rely on Docker, many of us, for local development, even if we're not thinking about it because we'll connect to cloud instances for some of our services, which are built using Docker.
\n\nZACK: I was going to say my argument for running Docker locally, at least from what I've found, is it only uses the resources that are needed for that, which for my team is really easy because it's only using resources if we're running a script. As well as it's been extremely helpful to have a development environment that is pretty much a one-to-one to production. You don't get any of the sneaky, like, oh, it's failing in production, and I have no idea why it's going on. It will fail on your local machine if it's going to fail in production.
\n\nMIKE: It's wonderful to be able to compare.
\n\nKYLE: I think that is one benefit with Docker that is a little bit overlooked is we get this response from devs sometimes, you know when something is deployed, and it's...well, it worked on my machine. Well, that's great, but we can't put your machine in AWS. However, if you give us a Docker image, we can put that in AWS, and that's the same image that will be running on your machine as will be running on a machine out in AWS.
\n\nMIKE: That's a big deal, that consistency.
\n\nZACK: If you look at toolings before Docker, it's not a new idea of trying to match local to production environments. Before that, there was Vagrant, which admittedly was maybe a little bit of a shit show; hard to manage but definitely been going for that for a long time. And I think Docker kind of hit the nail on the head with it.
\n\nMIKE: It's becoming remarkably successful and integral to a lot of what we do for a reason. It kind of takes the virtualization idea to its logical extreme. Let's strip out everything extraneous and have just what we need but everything that we need. All of your system libraries and your application that depend on them; we'll put that in a bundle and nothing else. It's a powerful, powerful way to approach deployment and even local development to get that consistency.
\n\nMARK: Docker has also been great for privacy and so forth. I know recently I discovered that you can run full-blown browsers within Docker and then access those browsers from your other browser. So I can have, say, 30 Firefox containers in Docker and have each container for a specific reason. So instead of creating profiles on my main computer for everything I want, I could have containerized Firefox applications for what websites I go to, which I believe is a great plus for security and not just development means.
\n\nMIKE: Yeah, if nothing else, you can segregate home from work. [laughs]
\n\nKYLE: I will say one thing that I've found developing in Docker is I tend to really kind of mess my machine up, and a local machine that requires a lot of debugging and figuring out what have you done and backtracking. The Docker image, use it, abuse it, throw it away, start up a new image.
\n\nJASON: I think that's a huge selling point for me going back to what we were talking about before with the freedom to experiment. I think that's pretty powerful.
\n\nMIKE: Well, it sounds like a good place to tie this up. There are a variety of tools that give you that power to experiment, and they've been coming up repeatedly. Docker and Git were mentioned particularly in that regard of the data warehouse. Anything that allows you to try something without breaking things is going to make your workflow much more powerful.
\n\nThank you for joining us today. And, hopefully, we gave you some ideas for things that you can go use yourself. And I don't know if we'll be seeing you, but you'll be hearing us next time on the Acima Development Podcast. Thank you.
","summary":"We're calling out the most valuable development tools and tricks.","date_published":"2023-02-01T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/1513ca25-ecd9-421e-9322-346d60176ec6.mp3","mime_type":"audio/mpeg","size_in_bytes":47329080,"duration_in_seconds":2691}]},{"id":"eb53402e-b15c-4091-8704-515d53bd6a89","title":"Episode 9: Remote Work Vs. In-Office","url":"https://acima-development.fireside.fm/9","content_text":"In this episode, we talk about remote work vs. being in the office. Pros and cons! Ups and downs!\n\nTranscript:\n\nDAVE: Hello. Welcome and good morning to the Acima Development Podcast. We are going to talk today about remote versus in-office work, and that's going to be kind of exciting. I'm your host, Dave Brady. I've been programming at Acima for a little over a year. And I started out on the Atlas web dev team building the website that the merchants use, and now I'm over on the data engineering team. And it's a lot of fun. Today on the panel, we have Eric Martinez.\n\nERIC: Hello, Hello. Eric Martinez, Product Manager. I've been at Acima for one year, and I'm excited to engage in this conversation with you all.\n\nDAVE: Awesome. We also have David Solano.\n\nDAVID: Hey, guys. I've been here in Acima for one year too, and I'm a developer. \n\nDAVE: Right on. David, where are you from? \n\nDAVID: Costa Rica. [laughs] \n\nDAVE: Costa Rica. \n\nDAVID: Ya.\n\nDAVE: We want everybody to know that we're not all in the middle of Utah. So it's kind of nice. Speaking of people that are not in the middle of Utah, we also have today Marcos Yu. \n\nMARCOS: Yeah. Hi. I'm a new developer in Acima. \n\nDAVE: Welcome. Where are you from, Marcos? \n\nMARCOS: I am from the Philippines.\n\nDAVE: Awesome. Welcome. We also have Ramses Bateman.\n\nRAMSES: Hello, hello. I am from Utah. Full-time developer for about six months now.\n\nDAVE: Right on. And, you know, if the Philippines and Costa Rica wasn't far enough away, we also have Aniket Tiwari. \n\nANIKET: Hi, everyone. I'm a contract developer, and I'm currently working from India. \n\nDAVE: Right on. Welcome. So we have people from pretty much every time zone. Well, I mean, not literally every timezone; we'd need 24 people here. But yeah, we've got pretty good global coverage, which is actually a pretty good introduction to the topic today, which is the benefits and trade-offs to remote work versus in-office work. I kind of want to just kick things off with a question, which is just to ask everybody on the team or everybody here on the panel what's your opinion? What do you think, bad idea, good idea?\n\nDAVID: Well, I've been in both scenarios. Right now, for Acima, I work remotely. But I think right from my side; I like to be at home working or busy working from a different location. It has its benefits, but I think that it also...sometimes you miss to see people just kind of networking or contact with others stuck around the office. So I think both sides have pros and cons.\n\nDAVE: 100% agreed.\n\nERIC: There is an argument to both, right? Work remotely versus coming into the office, and I think a lot of the national conversation regarding this topic has intensified because during the pandemic, obviously, working remotely was a thing because we couldn't gather. And I think a lot of benefits came out of that, good and bad. You have a segment of the population who probably it took a mental toll working remotely and not being able to connect with their peers at the office, not being able to have those connections with people outside of your home environment.\n\nThen you have people who reported they were more productive. And then they started to see like, hey, I don't have to go to the office. [laughs] I don't have to get up at 5:30 in the morning, try to get a peloton ride, shower, and take the kids to school, then drive 20 to 30 minutes to the office, and then drive back. So it became more efficient for those individuals. \n\nAnd then you have someone like me where...so when the pandemic happened, I was kind of doing some contract work, you know, there were some jobs. And when I came to Acima, it was kind of towards the tail end of the pandemic, but I think that we were still kind of starting from...a lot of companies had shifted to completely working remotely. And this is where I felt like in order to start a job; I think it will be really, really hard to start remotely. Now, that's my opinion based on my experience. \n\nI don't know. Maybe there are others here in the panel that might share a similar feeling. For the type of role that I have...so I partner with a team of engineers who manage a lot of the financial transactions and all the systems that manage all that money when you send it out with accounting. And a lot of my job for me to be successful is, I need to have personal relationships with accounting, with lots of people that I would have found a little bit hard to do remotely in a fully remote environment.\n\nIs there a straight answer? I think I'm kind of standing in the middle of the line with one foot on one side and one foot on the other. But now that I have built those relationships, I'm starting to like, hey, I want to work from home, maybe a hybrid model where I don't have to come into the office as much where I have built those personal relationships that now I can work with individuals remotely, right?\n\nDAVE: You actually make some really, really good points. I love this; can you start a job if you're 100% remote? We have some people on the team that did not come into the office [laughs] to get started, right? Aniket, David, Marcos. Like, how did you get started at this gig? How did you get started at previous gigs where you were 100% remote? Have you ever had jobs where you go in for the beginning and then roll out, or do you...oh, wow, my boss just joined the podcast. Welcome, Zach. \n\nZACH: Hey, how's it going? \n\nDAVE: Are you here to join the podcast, or are you here to tell me to get back to work?\n\nZACH: Join the podcast. I've been meaning to do it for a while.\n\nDAVE: Oh, thank goodness. Thank goodness. So awesome. Zach, you are the...what do you do here?\n\nZACH: My official title is Senior Data Service Manager managing the data services team.\n\nDAVE: Nice. So that would make me a senior data service.\n\nZACH: Senior data engineer, I believe. \n\nDAVE: Just, I mean, you are the senior data service manager. So if I'm a senior engineer, then you don't manage me, cool. I'm sure you'll set me straight later. Today we're talking about remote work versus in-office work. And Eric just raised a really good question of can you be 100% remote? And we've got three people; we've got a Costa Rican, a Filipino, and an Indian on the podcast today. And those are all 10-hour flights or more. I wanted to throw out to you guys, David, Marcos, Aniket, what is it like getting started in a job where you're 100% remote?\n\nMARCOS: Maybe I can share my experience around 2015. \n\nDAVE: Sure.\n\nMARCOS: So this is not actually my first time working remotely. So I was working under a UK client. So the time zone that I work with is very different, so that was a very different experience for me, for instance. So this happened way, way before the pandemic, so I was pretty happy back then, the productivity surge because I don't need to commute and stuff. And also, I feel that I'm accomplishing many things on a day-to-day basis because I feel that I could work six hours straight rather than at the office that I need to consider the traffic to go home to my family, so everything was good. \n\nBut then it was also my worst working experience. That's when I learned the importance of communication, especially with working remotely. While working in the company, there was no feedback loop in terms of the work quality that I'd been delivering and stuff. In my head, at that time, during those two years, I'd been doing great. I've been contributing well because I have this bunch of code that I've been pushing on our codebase, and it gets deployed.\n\nThen one day, they told me that they're going to stop working with me because the project is almost ending and stuff. So I was the first one to have been let go. I can understand the situation back then that it is kind of like a project basis and stuff. While looking for a job at that stage, that's when I noticed that my skills haven't grown for the two years, maybe because...I could factor in the lack of communication with my teammates also. You're not able to check the code quality that you're delivering and stuff. \n\nI would agree with the sentiment earlier that it works both ways. Yeah, you're being productive and stuff. Still, you need to communicate with your client and your peers. That's one of the most important points because that will show you where you are currently and if not, you might get lost working alone by yourself.\n\nDAVID: When I started working as a developer, I didn't have work from home, so I needed to travel two hours from my house to work. And from time to time, I could ask like, \"Hey, can I work from home this day?\" I need maybe to go to the doctor at the end of the day, and it's easy for me to go after job and be here in the house. Then I switched to another place, and I'd go two days, and that was a big change for me. I could rest a little bit longer. I could still network with the guys, with my partners, and that was great. \n\nAnd then, I switched to another place. And I was in a project where they weren't used to having work-from-home people. But I was completely remote because I was here in Costa Rica. And this client and this project was from the U.S., so it was extremely hard because they were not used to having tools to communicate better. Slack was something that they were barely using. \n\nAnd even though you tried to communicate with them, the team was not like in that way of facilitating everything for the remote guys. And I was not the only one. So it came to one point when they decided that they couldn't work with people working remotely. So they started to finish contracts because it was not working for them. \n\nThen I switched to another one where remote work was the thing. No one was at the office. Actually, there was no office. And it was pretty fun because they encouraged communication. It's easy for everyone. And then I joined here at Acima, and I think it's kind of both scenarios when you can go to the office; some people love to go to the office. \n\nBut for us that are working remotely from a totally different country, it's just awesome because here in Acima, the communication is just great. If have questions, you ask, and you get answers. If you have problems with the things that you are doing, you can pair program with your co-workers. And that is great because everyone here is willing to help you. So I think this is just amazing. For me, this has been the best experience of all time working remotely because I think Acima is just prepared for remote work.\n\nDAVE: I love how you talked about the existence of communication channels. I had forgotten this, but you're absolutely right; I've had that experience where eight of the people on the team were in the office, and two of us were remote. And we absolutely got starved for information because the team that was in the office all their communication channels were implicit, locally-convenient channels. \n\nIt's like they would go stand by each other's desk, or they would go hang out at the ping pong table or play foosball or whatever, or they would go eat in the lunch room together. And if you're outside, it's really hard to force your way into that communication circle, and it's actually seen as an annoyance or an intrusion. [laughs] \n\nThere was a team that I was on, and we had really good remote communication. And so at one point, we actually started doing telepresence where I would literally come in the morning, and I would jump into...it wasn't Skype but before Zoom existed, but it was one of those get on and do a video call. And in the office, they had a spare machine. So they could just turn that machine on, put my face on that screen, and then they could carry me around like a little disembodied head around the office. \n\nIt sounds really cool, but in practice, it's kind of, eh, it wasn't great. All the people that are like, \"This is not a good idea,\" they turned out to be right. But the hallmark, worst moment with that came when a couple of people on my team went to do a special side project with another local team that was entirely local. And I wanted to join with as well, so I'm like, cool, yeah. \n\nSo I had them take the telepresence laptop into the conference room where this other team was working. And they sat me down at the end of the table facing down the table, and it was pretty good. And immediately, nobody talked to me because the laptop the sound isn't that great. And I'm getting 12 people's audio slamming into me and that sort of thing. And I kind of got quiet, and I just started listening to everybody, and they started ignoring me. \n\nAnd at one point, somebody bumped the laptop and turned it like 90 degrees, 120 degrees, so I'm staring into a wall. And I'm like, \"Guys, hey. Guys, hello? [laughs] Can somebody turn me around?\" And either nobody could hear me or nobody cared. And after 10 minutes of waiting to see if somebody would notice that my laptop was turned around and nobody doing it, I'm finally like, eh, fine, I'll just drop out. And I ended up not doing the rest of that special team project because I literally could not force my way into the communication channel.\n\nDAVID: I was in that position a long time ago, same scenario. It was a webcam. The whole team was in the office. I was remote. And if you talk to them, they were not paying attention. So I decided to drop off, and no one even noticed. [laughs]\n\nDAVE: Yeah. That was the same experience I had. I dropped out of the thing. And I had to go find somebody and tell them, \"Hey, you might want to get the telepresence laptop out of the conference room.\" And they're like, \"Oh, is it still there?\" I'm like, \"Yeah, it's still there. [laughs] It's still pointed at the wall.\"\n\nDAVID: Yeah. And I've been in the other scenario where they don't have webcams with laptops and all that, but they just have this speaker.\n\nDAVE: Oh, like a conference call, yeah. \n\nDAVID: Right. And it's fine because sometimes, if there's someone who is able to facilitate how the conversation is going, it's easy for the one that is remote. And I actually like that he asked questions, \"Hey, David, what do you think about this?\" And so everyone listens, and everyone keeps silent and listens to what you have to say. And this enables you to participate in the, even now, in the meeting that is happening right now. But yeah, I think it depends on how the team is behaving at that moment. There's someone who facilitates that kind of communication too. \n\nDAVE: You've touched on an idea that I've tried to communicate for a while now about remote work, which is that for remote workers, there's no communication channel for...I call them priority four communications. So, like, priority three work is work that is in the backlog, and you do it when you can get to it. Priority 2 work is work that's at the top of the backlog, and you need to work on that right away. \n\nAnd then priority 1 is stuff where they're like, \"Don't go home until this is done.\" It's like we have to have this in place by tomorrow. There's also priority 0, which is don't go to the bathroom until this works. The server's down, and we're losing $100,000 a minute. You don't have time to go potty. \n\nBut priority 4 is communication that is not strictly necessary. Like, if somebody came in and said, \"Hey, keep it down and get back to work,\" you would probably be having priority four communication. And to be clear, I'm not talking about socialization or talking about the ball game last night, or any of that. I'm talking about actual work discussions. I'm talking about the thing where somebody sits down and says, \"So, how come we don't use SQL Server instead of this other data lake product?\"\n\nAnd the other person in the room can go, \"Hmmm, yeah, the CFO hates SQL Server.\" That's not going to be in the prospectus for the company. That's not an official doctrine. That's not something somebody wants to commit to in an email to tell you. But it is nonetheless a guiding factor for the entire company. So if you're like a database guy and you really, really love SQL Server, then you need to be aware that this is never going to fly here. You're going to have to do this. And that's what I call a priority four communication. \n\nAnd what I've noticed is that...oh, the other way you can define a P4 is it's something that if you had a question, you would never write an email to your team starting with, \"What do you think is the best way to...?\" You would never write this email, right? It's like, \"What do you guys think is the best way to store data? What do you guys think is the best web framework?\" The company already has a web framework. We already have a data storage solution. We already have networking vendors. But these are communications that, as a team, you need to have. \n\nAnd what you said was really, really important, David, that if there's a facilitator on the call to say, \"David, what do you think about this?\" They can drive a wedge into the conversation and create space for you to float into the conversation. But it's really hard. Without that facilitator; there's almost no way for you to engage in P4s. Nobody's going to sit down and say, \"Oh, by the way, everybody knows that the CFO hates SQL Server.\" Nobody's going to start that conversation with you. But it's an important conversation. \n\nThese are things that I call the lore of a project, the lore of a team, or the lore of a company, things that are not written down anywhere, and they're not official records, but nonetheless, they are very strong guiding rules to how the company is run. And I don't have a solution for that yet. But I think as we see more and more teams move to 100% remote, I think we're going to have to tackle this. I think we're going to have to find ways to get people rubbing elbows virtually, if not physically so that these communications can take place because I think they're actually pretty important. \n\nMARCOS: I kinda like what Atlas team does before their meeting. They set a time in the beginning of a meeting where people could talk about anything under the sun, let's say. So that's something that might come up or something that someone could share.\n\nDAVE: I like that. I've walked in on many conversations on the Atlas team and people who had been in there early...and people are talking about their kids. They're talking about their hobbies. They're talking about what they did over the weekend. And that's a lot of fun to walk in on that and to basically have human beings that I'm hanging out with that I don't have to get anything done with, and it's really nice. \n\nThere's a...ooh, don't quote me on this. They call it the FROG mechanic. If you need to communicate with somebody socially and you're socially awkward like I am, so, I mean, I literally had to Google how to make small talk with people. And the acronym that they give is FROG, F-R-O-G. If you can't think of anything to make small talk about, use the FROG acronym. You can talk about their family, their recreation, their...I can't remember what O is...occupation, which I mean with co-workers, is obviously...and I can't remember what G is...goals maybe, I can't remember. \n\nBut these are like safe topics that you can bring up with pretty much any stranger, like at a cocktail party or the equivalent. Yeah, walking in on a conversation where they're talking about FROG is awesome because you know that you can jump in and be part of the team and discuss. Eric...and oh, and Eddy Lopez has joined the call. Welcome, Eddy. I see some hands up on the call.\n\nERIC: Yeah. So I'm happy to hear that those conversations are happening with engineers, especially on the Atlas team. And I'm not surprised that those conversations are happening there. You know, obviously, I work with the Founding Fathers' team. When I first started working with them, that team, this is how I describe those guys; they will never kill a fly, but they're very intimidating [laughs] at the same time, very smart individuals, very straight to the point, very senior developers. \n\nAnd I do remember those first conversations. They were kind of awkward. I was trying to figure out the balance between, like, all right, here are things that we need to focus on. Here are things that I'm looking at you guys for directions. But going back to the point to, you know, working remotely versus working from office, so two members of that team are local here, and I remember having conversations outside of work, topic-related things helped build rapport, and then eventually build some trust in terms of projects, when we worked on projects. We have another team member who's based in Texas. \n\nOne thing about me that I think some of you guys know is I love to travel, and I like to find any excuse to go any place, from going to Panguitch, Utah to Russia, [laughs] any excuse that I can find to go somewhere. So Tyler Hall...and I think a lot of you guys know, he prepared for a year mentally, physically to do...what was it? MMA fighting. And I went to...a pretty cool story about how he started and his journey of preparation.\n\nSo I went to his fight. And even though I've only met Tyler once, when I went to the fight, personally, I feel like we have built a long-time relationship if our professional careers take us to different places; same with Adrian and Jordan, Matthew is in Virginia. And during our meetings, we do set some time to kind of shoot the breeze a little bit because that replaces something that happens naturally at an office workspace. \n\nEarlier, you mentioned the cooler water cooler. You have those small conversations that really do have an impact on work relationships, on personal relationships that are missing when you start fully working remotely. So I'm kind of happy that Marcos and David that you guys have found ways to kind of replace that in a remote environment to continue to have those connections, even though we're not physically present in the room, because I think that is one of the many factors that makes a successful team anywhere.\n\nDAVE: That's awesome. Thank you. \n\nEDDY: This is something that's been on my mind for the past few months. And this question is more catered to people that have experience in working remote and in office. The question is like, how would you compare Acima's productivity as the company embraces remote work? Is Acima more or less productive in comparison to other companies that you worked for that don't have remote work?\n\nERIC: I feel like Acima has been, in my experience, one of the companies that has been...we are more efficient. David, what would you say the percentage of all engineers that Acima employees are remote?\n\nDAVE: On the average team, it's close to 100%.\n\nERIC: Yeah, I was going to say I'm like, it's going to be pretty high because -- [laughs]\n\nDAVE: It's pretty high. Zach, are we...on the data team, are we 100% remote? I mean, I know you go into the office about one day a week. I, about every other week or every third week, will come in for a day.\n\nZACH: We're mostly remote. Kenton likes to be in office. So he's probably in the office the most.\n\nDAVE: That's an interesting take, though. It's like we're not requiring people to come in. But we have desks with computers and comfy chairs and sit standard electric desks so that if you do come in, you've got a nice place to sit and work. It's not like you have to come in and sit on a folding chair in a conference room and hate the environment. \n\nERIC: The environment, yeah. Going back to you, Eddy, which, by the way, I miss seeing your face in the office. Whenever you come to the office, it brightens my day. \n\nEDDY: Aw-shucks. \n\nERIC: [laughs] I would say that yes, in my experience, we are a pretty well-oiled machine, if you will if you allow me to use that metaphor. We get things done. We don't have to be all crammed in one room office space to get things done. And I think we have proven that. I mean, Atlas, how many engineers do you guys have? 20? I've lost count. They're a pretty big team. And they are a team that, without that team, we wouldn't have Acima and, of course, not to diss on other teams, right? All of the teams that we have are very integral to the success of Acima. \n\nAnd I think our success is because of you guys, engineering. We're very efficient now. That is my experience from other companies that I have worked with. And I wouldn't necessarily say it is the environment, whether you're working remotely or from home. I also think that it is the people that work for Acima are very good at what they do, and they're very competent individuals. That's also a key aspect that makes this company efficient and successful.\n\nDAVE: I have a question that I want to throw out. I want to kind of address the billionaire elephant in the room, which is a couple of months ago, Elon Musk bought Twitter. He made the news last week by going and addressing the employees of Twitter and saying, \"You need to get back to the office.\" And a lot of people were saying, \"Why?\" I'm more productive at home. I can write a line of code, and then if my kid wants to walk around the block, I can go do that with my kid. I can't do that when I'm at the office.\" Elon's response was that...he phrased it very interestingly. \n\nHe said you need to have...I'm not quoting, but he said something along the lines of you need to have a mindset of collaborating for innovation. And he definitely phrased it in a way that he was; basically, I think, addressing this kind of communication scarcity that happens with remote that if we don't have people together in the same room, we miss out on the breeder reactor reaction of having everybody in close proximity where they can bounce ideas off of each other at an increasingly high frequency. And he phrased this in very strong terms, like, I, as your employer, I don't get that benefit if you're not in the office. And I'm very curious to see, especially if --\n\nERIC: He's just a control freak. That's all it is. \n\nDAVE: Yeah, I mean --\n\nERIC: [laughs] That's all it is.\n\nDAVE: I've worked with a couple of...that's where I was going to go next. I've worked for a couple of CEOs that didn't like remote work, and they both used the word vibe. They're like, \"Oh, I like the vibe when people are in the office.\" And I'm like, you know, is there --\n\nERIC: That's translation, for I like to control you and making people come into the office. It's like, where are we? In kindergarten? Do we not have that trust? Do we not have that trust in our people? And I think this is something that...culture here, right? There is trust all around. And you guys are engineers, and we're able to deliver things. And we're able to ideate from people who work remotely. We're able to do things. And I just think Elon Musk was, you know, he's just a control freak. [laughs]\n\nMARCOS: I think I could also argue with that statement. So let's say we have this scenario, right? There are people in the office, but they're all looking at their computers doing each of their own stuff. And let's say they're doing it also remotely. So we could probably say that they have no interaction altogether, right? So working remotely and working in an office doesn't have any difference at all. \n\nSo it boils down to the people and the culture that the company has. So it's not about the physical interaction. I mean, this is my personal opinion. It boils down to people and culture of the company rather than physical presence or the setup of your company or working remotely or working in office.\n\nDAVE: Yeah. As you were saying that, I realized that there's a communication channel that is present or not a communication...I'm going to say communication channel, but what I mean is like it's almost like a nebulous like a psychological...we all have Slack. We all have instant message. We all have video calls. But we made a conscious decision. And we've set an example on the Atlas team to say, we're going to ask really dumb, low-priority questions or questions that you might think twice about asking or you might consider, oh, this question is noise. \n\nAnd at the Atlas team, we ask those, and they get answered, and it's super beneficial. And the key example that I have cited over the years...and this is purely anecdotal from my experience. I love remote work, but I step back, and I say, \"Well, are there advantages to working in the office?\" \n\nAnd I've had the experience of working with a pair programmer, and we're talking about, okay, we got to run this. We got to get this test working. And all of a sudden, the database goes away and stops working. And we're like, wait a minute, why can't we connect to the database anymore? Something in the connection pool. Wait, we don't use a connection pool. \n\nAnd because I'm talking with my pair and I'm talking with them out loud, the pair programming team sitting right next to us heard us and turned and said, \"Oh, you guys, we just pushed up a connection pooling thing. You just need to pull and synchronize. And then you just need to touch this file, and you'll be good to go.\" And we immediately got up and running. And that could have sidelined if we were remote and none of that was overheard. That could have sidelined us for a long time. \n\nAnd I've had that experience as well where I've been sidelined by something nitpicky and stupid that somebody did and then didn't tell everybody else on the team. I think Atlas has done a really good job of addressing that by having one of the team channels be a place where it's absolutely...we have like a company-wide channel for our team where anybody can come and go that wants to have interaction with our team. \n\nBut the Atlas team, in particular, had a private engineering channel that they could go into. And that was a place where you could just go, \"Oh my gosh, I'm getting this error message. Does anybody know anything about this?\" And you get kind of that same feedback where another person on the team will say, \"Oh, yeah, I did that to you, sorry.\" \n\nThe nice thing is that they will usually follow that with a link in the Slack channel to the conversation that they kicked off four hours ago or in the middle of the night last night or two days ago, depending on how long you've been out of sync with the repo. They'll come back and say, \"Here's the conversation where I said this. These are the steps that you need to do to correct this.\" That's something you can't do at the water cooler is you can't be in the middle of a conversation with somebody and then hand somebody a link to the conversation that was had at the water cooler three days ago. That's kind of a fun sidebar. \n\nThere are some efficiencies that you can leverage of remote work that I think we address the entire conversation around is remote work good enough to replace office work? And I think we overlook some things that remote work is very, very good at and very especially adapted to. So that's kind of a side tangent.\n\nMARCOS: Yeah. And to add to that, I think you can encounter this many times. Like, there are some devs that ask a question, then there is someone that's going to reply to that thread. And he said that \"Yes, I've been encountering that for many days,\" or something. And then there's going to be another dev which, \"Oh, I introduced this some time ago.\" So if you could see that, there's that individuality of a developer that they do not tend to ask questions because not all developers are equal, so some ask questions, some don't. So they tend to just adjust to that scenario without asking. \n\nSo because of that channel, they could surface their question, or they could say, \"Yeah, I also experienced that.\" So now that there's a commonality with that, we could actually address that since it's a common problem for all. So that's one thing that I noticed very differently in other companies and here in Acima is that collaboration is really a priority. Everybody has a ticket, right? Everybody's busy. But everyone always checks the message and sees, oh, someone is having trouble. And if they knew or something came up to mind, they're not afraid to just chat it there. So that encourages you also to ask questions rather than keep it to yourself.\n\nDAVE: That's awesome. Thank you. I think there might still be some meat on this bone to talk through. But we're coming up close on our hour here for record time. Do we have any parting shots, any closing thoughts? I'm assuming everyone in the room is pro versus against remote work. Any other shots?\n\nDAVID: I think this has been a great conversation. I just wanted to finish with something that just comes to my mind. If you're working remotely, remember that you also need to be open to feedback. I think that's important. If you want to grow up there and to find the way and the standard of the team, that's something you have to keep in mind.\n\nDAVE: Yeah, that's a nice circling comment to what you said at the top of the call where the necessary feedback was lacking that you have to go...and what I'm saying is if you're remote, you have to go after that feedback sometimes so people that will just like, oh, well, if I don't talk about it, maybe the problem will go away and --\n\nMARCOS: And maybe people will forget if you don't chase that feedback. [laughs]\n\nDAVE: Yeah. And that feedback can be essential to keeping your job. So you can accidentally let some information go by that you absolutely need. And if you were in the office, you would just pick it up and absorb it because it's kind of in the air. And if you're remote, you have to go digging for it sometimes.\n\nEDDY: I have a question for those who prefer to go in the office or aren't opposed to. How can you be productive when it's really easy to reach over someone's shoulder and start a conversation? I don't know about you guys, but everyone in Acima is really nice. And it's really easy to start a conversation. I'll go on record and say if I'm in the office, [laughs] it's hard to get more work done as opposed to when I'm at home.\n\nDAVE: Yeah, that's a really fair point. We've been talking about the communication channels purely from the viewpoint of communication carries sideband information that's really, really valuable, and we lose that when we're remote. But the advantage of being remote is that you lose that communication channel. That communication channel doesn't come find you and distract you. Having peace and quiet and time to think is kind of nice working remote.\n\nEDDY: Yeah, being secluded, for me anyways, I can be more productive. But I'm just curious to gauge other people's opinions.\n\nMARCOS: I've been someone asking someone in the office for some help. So that actually, like request timing also, like, let's say, what if the person is busy? So that's one thing that I encounter most of the time in the office when I was working in the office. So that actually sometimes discourages you to ask someone a question. \n\nSo what I typically do is, even though I'm in the office, I just leave him a message. If that person is known to be like the busy guy, because there's always the busy guy that always stares at his computer, so I just leave him a message. So that kind of works the same way with working remotely. You can leave a message to the people and let them take their time to do the stuff that they need and just wait for them to reply.\n\nDAVE: Yeah, that's actually a really good point that when you are in the office, it's very, very easy to have highly urgent conversations, not necessarily important conversation but urgent conversation. And when you are remote, it's much more easier to have asynchronous communication where you fire something off, and then you wait for a little while to get back. \n\nAnd when you're remote, you can kind of get a little hamstrung where if you're like, \"Hey, I need help with this,\" because you're down, right? It's like if your machine isn't working, you can't write software today until this gets fixed. You don't want to be in an asynchronous situation. You don't want to just like, oh, by the way, if anybody sees this sometime today or tomorrow, could you maybe get around it? No, it's like you need help right now, right? So it's kind of like urgent. \n\nOne of the things that I have lamented this multiple times in the past but one of the things you can't do when you're remote is you can't go stand at somebody's desk and just be silent and awkward until they give you what you want. I love that about working in the office. It's just being awkward at your desk until you make me go away. And you can make me go away by giving me what I want, which is nice.\n\nERIC: And it's more efficient. [laughs]\n\nDAVE: Yeah.\n\nEDDY: I'll tell you this because it brings up a pretty interesting point that we ran into a few weeks ago in the QA team where we're like, \"Hey, should we update our laptops? Is it safe to update or not?\" And we never got a concrete answer from IT. And I'm going to bring Zsolt in, and I'm sorry, Zsolt, to hear this, like, hello. But he's the only one really on the team who prefers to work in office, like in an office setting. So we just messaged, and we're like, \"Hey, can you go bug IT really quick and just ask them a direct answer? Like, this would be nice to have.\" And he's like, \"Yeah, sure. Give me like five minutes.\" \n\nAnd so he's like, AFK. And then he comes back about 10 minutes later. And he's just like, \"Oh, I have an answer. This is what it is.\" And I'm just like, well, that was fast. So you can be more efficient, I guess, and you can get your answers quicker [laughs] if you're in the office.\n\nDAVE: Yeah. It's important to remember that when the shoe is on the other foot, it's the exact opposite. Like you just said, it's nice when you're remote to have that solitude and get your head down and get some work done. And you can't do that if David Brady is standing at your desk being awkward, waiting for you to babysit him. It's like, I got to get work done too, man. It's an interesting balance. And that's what I would say is it's a balance. Sometimes you got to lean hard to one side versus the other. \n\nZACH: So there's a quick story I wanted to share from my last company of how we got, like, limited the hovering over the desk, especially for questions. And I think all of us as developers have done this before where you go and ask a question, and as you're talking through it, the answer just pops in your head, and you didn't actually need to take somebody else's time.\n\nSo we were on a project that was just a big time crunch. And our VP of data science actually brought in like a six-foot stuffed bear [laughter] with a Jazz jersey and a hat, and he sat him in a chair at one of the desks at the beginning of our aisle. And before somebody was allowed to actually come talk to us, they had to talk it through with the bear to see if they got their solution from that or not. \n\nDAVE: Nice.\n\nZACH: I mean, it limited the distractions, and we were able to get the project out in time, half because I think a lot of people don't want to go sit and talk to a stuffed bear, and then the other half just basically they figured it out on their own talking to the stuffed bear.\n\nEDDY: Kind of rubber ducking.\n\nDAVE: I've heard that referred to as teddy bear debugging, or rubber ducking or teddy bear debugging, yeah.\n\nEDDY: Rubberducking, yep.\n\nDAVE: And yeah, like, by the time you serialize a problem in your brain to be able to stream it out as words, that's usually enough to reframe the problem in your head, not usually, but there's a fair amount where that's enough to solve...yeah, you said it already. I'll just...I'll shut up. [laughs]\n\nZACH: And on the flipside of that, I think that when you work remote, it's more conscious effort to reach out to somebody than to turn your head and say, \"Hey,\" right?\n\nDAVE: Yeah.\n\nZACH: Or just walk three feet away, five feet away. And so I think a lot of people actually kind of do that internally when they're remote.\n\nEDDY: Zach, I'd argue that maybe there's been times where you'd you start to type a message to someone because you can't figure it out. In the middle of typing that out, you're like, oh yeah, that's the answer. It's kind of like a similar concept. \n\nZACH: Yep.\n\nMARCOS: And it happens most of the time.\n\n[laughter]\n\nZACH: I just noticed since we've gone remote, when I get questions, they're hard issues. I mean, some of the time, it's something that I just know because of my experience here. But a lot of the time, it's something where I'm like just researching with one of the team members on how to get past it.\n\nDAVE: Yeah. That is awesome. I want to thank everybody for coming out today. David, Marcos, you're still here, Zach is still here, Eddy is still here. Thanks for coming out today. This was a fun chat.","content_html":"In this episode, we talk about remote work vs. being in the office. Pros and cons! Ups and downs!
\n\nTranscript:
\n\nDAVE: Hello. Welcome and good morning to the Acima Development Podcast. We are going to talk today about remote versus in-office work, and that's going to be kind of exciting. I'm your host, Dave Brady. I've been programming at Acima for a little over a year. And I started out on the Atlas web dev team building the website that the merchants use, and now I'm over on the data engineering team. And it's a lot of fun. Today on the panel, we have Eric Martinez.
\n\nERIC: Hello, Hello. Eric Martinez, Product Manager. I've been at Acima for one year, and I'm excited to engage in this conversation with you all.
\n\nDAVE: Awesome. We also have David Solano.
\n\nDAVID: Hey, guys. I've been here in Acima for one year too, and I'm a developer.
\n\nDAVE: Right on. David, where are you from?
\n\nDAVID: Costa Rica. [laughs]
\n\nDAVE: Costa Rica.
\n\nDAVID: Ya.
\n\nDAVE: We want everybody to know that we're not all in the middle of Utah. So it's kind of nice. Speaking of people that are not in the middle of Utah, we also have today Marcos Yu.
\n\nMARCOS: Yeah. Hi. I'm a new developer in Acima.
\n\nDAVE: Welcome. Where are you from, Marcos?
\n\nMARCOS: I am from the Philippines.
\n\nDAVE: Awesome. Welcome. We also have Ramses Bateman.
\n\nRAMSES: Hello, hello. I am from Utah. Full-time developer for about six months now.
\n\nDAVE: Right on. And, you know, if the Philippines and Costa Rica wasn't far enough away, we also have Aniket Tiwari.
\n\nANIKET: Hi, everyone. I'm a contract developer, and I'm currently working from India.
\n\nDAVE: Right on. Welcome. So we have people from pretty much every time zone. Well, I mean, not literally every timezone; we'd need 24 people here. But yeah, we've got pretty good global coverage, which is actually a pretty good introduction to the topic today, which is the benefits and trade-offs to remote work versus in-office work. I kind of want to just kick things off with a question, which is just to ask everybody on the team or everybody here on the panel what's your opinion? What do you think, bad idea, good idea?
\n\nDAVID: Well, I've been in both scenarios. Right now, for Acima, I work remotely. But I think right from my side; I like to be at home working or busy working from a different location. It has its benefits, but I think that it also...sometimes you miss to see people just kind of networking or contact with others stuck around the office. So I think both sides have pros and cons.
\n\nDAVE: 100% agreed.
\n\nERIC: There is an argument to both, right? Work remotely versus coming into the office, and I think a lot of the national conversation regarding this topic has intensified because during the pandemic, obviously, working remotely was a thing because we couldn't gather. And I think a lot of benefits came out of that, good and bad. You have a segment of the population who probably it took a mental toll working remotely and not being able to connect with their peers at the office, not being able to have those connections with people outside of your home environment.
\n\nThen you have people who reported they were more productive. And then they started to see like, hey, I don't have to go to the office. [laughs] I don't have to get up at 5:30 in the morning, try to get a peloton ride, shower, and take the kids to school, then drive 20 to 30 minutes to the office, and then drive back. So it became more efficient for those individuals.
\n\nAnd then you have someone like me where...so when the pandemic happened, I was kind of doing some contract work, you know, there were some jobs. And when I came to Acima, it was kind of towards the tail end of the pandemic, but I think that we were still kind of starting from...a lot of companies had shifted to completely working remotely. And this is where I felt like in order to start a job; I think it will be really, really hard to start remotely. Now, that's my opinion based on my experience.
\n\nI don't know. Maybe there are others here in the panel that might share a similar feeling. For the type of role that I have...so I partner with a team of engineers who manage a lot of the financial transactions and all the systems that manage all that money when you send it out with accounting. And a lot of my job for me to be successful is, I need to have personal relationships with accounting, with lots of people that I would have found a little bit hard to do remotely in a fully remote environment.
\n\nIs there a straight answer? I think I'm kind of standing in the middle of the line with one foot on one side and one foot on the other. But now that I have built those relationships, I'm starting to like, hey, I want to work from home, maybe a hybrid model where I don't have to come into the office as much where I have built those personal relationships that now I can work with individuals remotely, right?
\n\nDAVE: You actually make some really, really good points. I love this; can you start a job if you're 100% remote? We have some people on the team that did not come into the office [laughs] to get started, right? Aniket, David, Marcos. Like, how did you get started at this gig? How did you get started at previous gigs where you were 100% remote? Have you ever had jobs where you go in for the beginning and then roll out, or do you...oh, wow, my boss just joined the podcast. Welcome, Zach.
\n\nZACH: Hey, how's it going?
\n\nDAVE: Are you here to join the podcast, or are you here to tell me to get back to work?
\n\nZACH: Join the podcast. I've been meaning to do it for a while.
\n\nDAVE: Oh, thank goodness. Thank goodness. So awesome. Zach, you are the...what do you do here?
\n\nZACH: My official title is Senior Data Service Manager managing the data services team.
\n\nDAVE: Nice. So that would make me a senior data service.
\n\nZACH: Senior data engineer, I believe.
\n\nDAVE: Just, I mean, you are the senior data service manager. So if I'm a senior engineer, then you don't manage me, cool. I'm sure you'll set me straight later. Today we're talking about remote work versus in-office work. And Eric just raised a really good question of can you be 100% remote? And we've got three people; we've got a Costa Rican, a Filipino, and an Indian on the podcast today. And those are all 10-hour flights or more. I wanted to throw out to you guys, David, Marcos, Aniket, what is it like getting started in a job where you're 100% remote?
\n\nMARCOS: Maybe I can share my experience around 2015.
\n\nDAVE: Sure.
\n\nMARCOS: So this is not actually my first time working remotely. So I was working under a UK client. So the time zone that I work with is very different, so that was a very different experience for me, for instance. So this happened way, way before the pandemic, so I was pretty happy back then, the productivity surge because I don't need to commute and stuff. And also, I feel that I'm accomplishing many things on a day-to-day basis because I feel that I could work six hours straight rather than at the office that I need to consider the traffic to go home to my family, so everything was good.
\n\nBut then it was also my worst working experience. That's when I learned the importance of communication, especially with working remotely. While working in the company, there was no feedback loop in terms of the work quality that I'd been delivering and stuff. In my head, at that time, during those two years, I'd been doing great. I've been contributing well because I have this bunch of code that I've been pushing on our codebase, and it gets deployed.
\n\nThen one day, they told me that they're going to stop working with me because the project is almost ending and stuff. So I was the first one to have been let go. I can understand the situation back then that it is kind of like a project basis and stuff. While looking for a job at that stage, that's when I noticed that my skills haven't grown for the two years, maybe because...I could factor in the lack of communication with my teammates also. You're not able to check the code quality that you're delivering and stuff.
\n\nI would agree with the sentiment earlier that it works both ways. Yeah, you're being productive and stuff. Still, you need to communicate with your client and your peers. That's one of the most important points because that will show you where you are currently and if not, you might get lost working alone by yourself.
\n\nDAVID: When I started working as a developer, I didn't have work from home, so I needed to travel two hours from my house to work. And from time to time, I could ask like, "Hey, can I work from home this day?" I need maybe to go to the doctor at the end of the day, and it's easy for me to go after job and be here in the house. Then I switched to another place, and I'd go two days, and that was a big change for me. I could rest a little bit longer. I could still network with the guys, with my partners, and that was great.
\n\nAnd then, I switched to another place. And I was in a project where they weren't used to having work-from-home people. But I was completely remote because I was here in Costa Rica. And this client and this project was from the U.S., so it was extremely hard because they were not used to having tools to communicate better. Slack was something that they were barely using.
\n\nAnd even though you tried to communicate with them, the team was not like in that way of facilitating everything for the remote guys. And I was not the only one. So it came to one point when they decided that they couldn't work with people working remotely. So they started to finish contracts because it was not working for them.
\n\nThen I switched to another one where remote work was the thing. No one was at the office. Actually, there was no office. And it was pretty fun because they encouraged communication. It's easy for everyone. And then I joined here at Acima, and I think it's kind of both scenarios when you can go to the office; some people love to go to the office.
\n\nBut for us that are working remotely from a totally different country, it's just awesome because here in Acima, the communication is just great. If have questions, you ask, and you get answers. If you have problems with the things that you are doing, you can pair program with your co-workers. And that is great because everyone here is willing to help you. So I think this is just amazing. For me, this has been the best experience of all time working remotely because I think Acima is just prepared for remote work.
\n\nDAVE: I love how you talked about the existence of communication channels. I had forgotten this, but you're absolutely right; I've had that experience where eight of the people on the team were in the office, and two of us were remote. And we absolutely got starved for information because the team that was in the office all their communication channels were implicit, locally-convenient channels.
\n\nIt's like they would go stand by each other's desk, or they would go hang out at the ping pong table or play foosball or whatever, or they would go eat in the lunch room together. And if you're outside, it's really hard to force your way into that communication circle, and it's actually seen as an annoyance or an intrusion. [laughs]
\n\nThere was a team that I was on, and we had really good remote communication. And so at one point, we actually started doing telepresence where I would literally come in the morning, and I would jump into...it wasn't Skype but before Zoom existed, but it was one of those get on and do a video call. And in the office, they had a spare machine. So they could just turn that machine on, put my face on that screen, and then they could carry me around like a little disembodied head around the office.
\n\nIt sounds really cool, but in practice, it's kind of, eh, it wasn't great. All the people that are like, "This is not a good idea," they turned out to be right. But the hallmark, worst moment with that came when a couple of people on my team went to do a special side project with another local team that was entirely local. And I wanted to join with as well, so I'm like, cool, yeah.
\n\nSo I had them take the telepresence laptop into the conference room where this other team was working. And they sat me down at the end of the table facing down the table, and it was pretty good. And immediately, nobody talked to me because the laptop the sound isn't that great. And I'm getting 12 people's audio slamming into me and that sort of thing. And I kind of got quiet, and I just started listening to everybody, and they started ignoring me.
\n\nAnd at one point, somebody bumped the laptop and turned it like 90 degrees, 120 degrees, so I'm staring into a wall. And I'm like, "Guys, hey. Guys, hello? [laughs] Can somebody turn me around?" And either nobody could hear me or nobody cared. And after 10 minutes of waiting to see if somebody would notice that my laptop was turned around and nobody doing it, I'm finally like, eh, fine, I'll just drop out. And I ended up not doing the rest of that special team project because I literally could not force my way into the communication channel.
\n\nDAVID: I was in that position a long time ago, same scenario. It was a webcam. The whole team was in the office. I was remote. And if you talk to them, they were not paying attention. So I decided to drop off, and no one even noticed. [laughs]
\n\nDAVE: Yeah. That was the same experience I had. I dropped out of the thing. And I had to go find somebody and tell them, "Hey, you might want to get the telepresence laptop out of the conference room." And they're like, "Oh, is it still there?" I'm like, "Yeah, it's still there. [laughs] It's still pointed at the wall."
\n\nDAVID: Yeah. And I've been in the other scenario where they don't have webcams with laptops and all that, but they just have this speaker.
\n\nDAVE: Oh, like a conference call, yeah.
\n\nDAVID: Right. And it's fine because sometimes, if there's someone who is able to facilitate how the conversation is going, it's easy for the one that is remote. And I actually like that he asked questions, "Hey, David, what do you think about this?" And so everyone listens, and everyone keeps silent and listens to what you have to say. And this enables you to participate in the, even now, in the meeting that is happening right now. But yeah, I think it depends on how the team is behaving at that moment. There's someone who facilitates that kind of communication too.
\n\nDAVE: You've touched on an idea that I've tried to communicate for a while now about remote work, which is that for remote workers, there's no communication channel for...I call them priority four communications. So, like, priority three work is work that is in the backlog, and you do it when you can get to it. Priority 2 work is work that's at the top of the backlog, and you need to work on that right away.
\n\nAnd then priority 1 is stuff where they're like, "Don't go home until this is done." It's like we have to have this in place by tomorrow. There's also priority 0, which is don't go to the bathroom until this works. The server's down, and we're losing $100,000 a minute. You don't have time to go potty.
\n\nBut priority 4 is communication that is not strictly necessary. Like, if somebody came in and said, "Hey, keep it down and get back to work," you would probably be having priority four communication. And to be clear, I'm not talking about socialization or talking about the ball game last night, or any of that. I'm talking about actual work discussions. I'm talking about the thing where somebody sits down and says, "So, how come we don't use SQL Server instead of this other data lake product?"
\n\nAnd the other person in the room can go, "Hmmm, yeah, the CFO hates SQL Server." That's not going to be in the prospectus for the company. That's not an official doctrine. That's not something somebody wants to commit to in an email to tell you. But it is nonetheless a guiding factor for the entire company. So if you're like a database guy and you really, really love SQL Server, then you need to be aware that this is never going to fly here. You're going to have to do this. And that's what I call a priority four communication.
\n\nAnd what I've noticed is that...oh, the other way you can define a P4 is it's something that if you had a question, you would never write an email to your team starting with, "What do you think is the best way to...?" You would never write this email, right? It's like, "What do you guys think is the best way to store data? What do you guys think is the best web framework?" The company already has a web framework. We already have a data storage solution. We already have networking vendors. But these are communications that, as a team, you need to have.
\n\nAnd what you said was really, really important, David, that if there's a facilitator on the call to say, "David, what do you think about this?" They can drive a wedge into the conversation and create space for you to float into the conversation. But it's really hard. Without that facilitator; there's almost no way for you to engage in P4s. Nobody's going to sit down and say, "Oh, by the way, everybody knows that the CFO hates SQL Server." Nobody's going to start that conversation with you. But it's an important conversation.
\n\nThese are things that I call the lore of a project, the lore of a team, or the lore of a company, things that are not written down anywhere, and they're not official records, but nonetheless, they are very strong guiding rules to how the company is run. And I don't have a solution for that yet. But I think as we see more and more teams move to 100% remote, I think we're going to have to tackle this. I think we're going to have to find ways to get people rubbing elbows virtually, if not physically so that these communications can take place because I think they're actually pretty important.
\n\nMARCOS: I kinda like what Atlas team does before their meeting. They set a time in the beginning of a meeting where people could talk about anything under the sun, let's say. So that's something that might come up or something that someone could share.
\n\nDAVE: I like that. I've walked in on many conversations on the Atlas team and people who had been in there early...and people are talking about their kids. They're talking about their hobbies. They're talking about what they did over the weekend. And that's a lot of fun to walk in on that and to basically have human beings that I'm hanging out with that I don't have to get anything done with, and it's really nice.
\n\nThere's a...ooh, don't quote me on this. They call it the FROG mechanic. If you need to communicate with somebody socially and you're socially awkward like I am, so, I mean, I literally had to Google how to make small talk with people. And the acronym that they give is FROG, F-R-O-G. If you can't think of anything to make small talk about, use the FROG acronym. You can talk about their family, their recreation, their...I can't remember what O is...occupation, which I mean with co-workers, is obviously...and I can't remember what G is...goals maybe, I can't remember.
\n\nBut these are like safe topics that you can bring up with pretty much any stranger, like at a cocktail party or the equivalent. Yeah, walking in on a conversation where they're talking about FROG is awesome because you know that you can jump in and be part of the team and discuss. Eric...and oh, and Eddy Lopez has joined the call. Welcome, Eddy. I see some hands up on the call.
\n\nERIC: Yeah. So I'm happy to hear that those conversations are happening with engineers, especially on the Atlas team. And I'm not surprised that those conversations are happening there. You know, obviously, I work with the Founding Fathers' team. When I first started working with them, that team, this is how I describe those guys; they will never kill a fly, but they're very intimidating [laughs] at the same time, very smart individuals, very straight to the point, very senior developers.
\n\nAnd I do remember those first conversations. They were kind of awkward. I was trying to figure out the balance between, like, all right, here are things that we need to focus on. Here are things that I'm looking at you guys for directions. But going back to the point to, you know, working remotely versus working from office, so two members of that team are local here, and I remember having conversations outside of work, topic-related things helped build rapport, and then eventually build some trust in terms of projects, when we worked on projects. We have another team member who's based in Texas.
\n\nOne thing about me that I think some of you guys know is I love to travel, and I like to find any excuse to go any place, from going to Panguitch, Utah to Russia, [laughs] any excuse that I can find to go somewhere. So Tyler Hall...and I think a lot of you guys know, he prepared for a year mentally, physically to do...what was it? MMA fighting. And I went to...a pretty cool story about how he started and his journey of preparation.
\n\nSo I went to his fight. And even though I've only met Tyler once, when I went to the fight, personally, I feel like we have built a long-time relationship if our professional careers take us to different places; same with Adrian and Jordan, Matthew is in Virginia. And during our meetings, we do set some time to kind of shoot the breeze a little bit because that replaces something that happens naturally at an office workspace.
\n\nEarlier, you mentioned the cooler water cooler. You have those small conversations that really do have an impact on work relationships, on personal relationships that are missing when you start fully working remotely. So I'm kind of happy that Marcos and David that you guys have found ways to kind of replace that in a remote environment to continue to have those connections, even though we're not physically present in the room, because I think that is one of the many factors that makes a successful team anywhere.
\n\nDAVE: That's awesome. Thank you.
\n\nEDDY: This is something that's been on my mind for the past few months. And this question is more catered to people that have experience in working remote and in office. The question is like, how would you compare Acima's productivity as the company embraces remote work? Is Acima more or less productive in comparison to other companies that you worked for that don't have remote work?
\n\nERIC: I feel like Acima has been, in my experience, one of the companies that has been...we are more efficient. David, what would you say the percentage of all engineers that Acima employees are remote?
\n\nDAVE: On the average team, it's close to 100%.
\n\nERIC: Yeah, I was going to say I'm like, it's going to be pretty high because -- [laughs]
\n\nDAVE: It's pretty high. Zach, are we...on the data team, are we 100% remote? I mean, I know you go into the office about one day a week. I, about every other week or every third week, will come in for a day.
\n\nZACH: We're mostly remote. Kenton likes to be in office. So he's probably in the office the most.
\n\nDAVE: That's an interesting take, though. It's like we're not requiring people to come in. But we have desks with computers and comfy chairs and sit standard electric desks so that if you do come in, you've got a nice place to sit and work. It's not like you have to come in and sit on a folding chair in a conference room and hate the environment.
\n\nERIC: The environment, yeah. Going back to you, Eddy, which, by the way, I miss seeing your face in the office. Whenever you come to the office, it brightens my day.
\n\nEDDY: Aw-shucks.
\n\nERIC: [laughs] I would say that yes, in my experience, we are a pretty well-oiled machine, if you will if you allow me to use that metaphor. We get things done. We don't have to be all crammed in one room office space to get things done. And I think we have proven that. I mean, Atlas, how many engineers do you guys have? 20? I've lost count. They're a pretty big team. And they are a team that, without that team, we wouldn't have Acima and, of course, not to diss on other teams, right? All of the teams that we have are very integral to the success of Acima.
\n\nAnd I think our success is because of you guys, engineering. We're very efficient now. That is my experience from other companies that I have worked with. And I wouldn't necessarily say it is the environment, whether you're working remotely or from home. I also think that it is the people that work for Acima are very good at what they do, and they're very competent individuals. That's also a key aspect that makes this company efficient and successful.
\n\nDAVE: I have a question that I want to throw out. I want to kind of address the billionaire elephant in the room, which is a couple of months ago, Elon Musk bought Twitter. He made the news last week by going and addressing the employees of Twitter and saying, "You need to get back to the office." And a lot of people were saying, "Why?" I'm more productive at home. I can write a line of code, and then if my kid wants to walk around the block, I can go do that with my kid. I can't do that when I'm at the office." Elon's response was that...he phrased it very interestingly.
\n\nHe said you need to have...I'm not quoting, but he said something along the lines of you need to have a mindset of collaborating for innovation. And he definitely phrased it in a way that he was; basically, I think, addressing this kind of communication scarcity that happens with remote that if we don't have people together in the same room, we miss out on the breeder reactor reaction of having everybody in close proximity where they can bounce ideas off of each other at an increasingly high frequency. And he phrased this in very strong terms, like, I, as your employer, I don't get that benefit if you're not in the office. And I'm very curious to see, especially if --
\n\nERIC: He's just a control freak. That's all it is.
\n\nDAVE: Yeah, I mean --
\n\nERIC: [laughs] That's all it is.
\n\nDAVE: I've worked with a couple of...that's where I was going to go next. I've worked for a couple of CEOs that didn't like remote work, and they both used the word vibe. They're like, "Oh, I like the vibe when people are in the office." And I'm like, you know, is there --
\n\nERIC: That's translation, for I like to control you and making people come into the office. It's like, where are we? In kindergarten? Do we not have that trust? Do we not have that trust in our people? And I think this is something that...culture here, right? There is trust all around. And you guys are engineers, and we're able to deliver things. And we're able to ideate from people who work remotely. We're able to do things. And I just think Elon Musk was, you know, he's just a control freak. [laughs]
\n\nMARCOS: I think I could also argue with that statement. So let's say we have this scenario, right? There are people in the office, but they're all looking at their computers doing each of their own stuff. And let's say they're doing it also remotely. So we could probably say that they have no interaction altogether, right? So working remotely and working in an office doesn't have any difference at all.
\n\nSo it boils down to the people and the culture that the company has. So it's not about the physical interaction. I mean, this is my personal opinion. It boils down to people and culture of the company rather than physical presence or the setup of your company or working remotely or working in office.
\n\nDAVE: Yeah. As you were saying that, I realized that there's a communication channel that is present or not a communication...I'm going to say communication channel, but what I mean is like it's almost like a nebulous like a psychological...we all have Slack. We all have instant message. We all have video calls. But we made a conscious decision. And we've set an example on the Atlas team to say, we're going to ask really dumb, low-priority questions or questions that you might think twice about asking or you might consider, oh, this question is noise.
\n\nAnd at the Atlas team, we ask those, and they get answered, and it's super beneficial. And the key example that I have cited over the years...and this is purely anecdotal from my experience. I love remote work, but I step back, and I say, "Well, are there advantages to working in the office?"
\n\nAnd I've had the experience of working with a pair programmer, and we're talking about, okay, we got to run this. We got to get this test working. And all of a sudden, the database goes away and stops working. And we're like, wait a minute, why can't we connect to the database anymore? Something in the connection pool. Wait, we don't use a connection pool.
\n\nAnd because I'm talking with my pair and I'm talking with them out loud, the pair programming team sitting right next to us heard us and turned and said, "Oh, you guys, we just pushed up a connection pooling thing. You just need to pull and synchronize. And then you just need to touch this file, and you'll be good to go." And we immediately got up and running. And that could have sidelined if we were remote and none of that was overheard. That could have sidelined us for a long time.
\n\nAnd I've had that experience as well where I've been sidelined by something nitpicky and stupid that somebody did and then didn't tell everybody else on the team. I think Atlas has done a really good job of addressing that by having one of the team channels be a place where it's absolutely...we have like a company-wide channel for our team where anybody can come and go that wants to have interaction with our team.
\n\nBut the Atlas team, in particular, had a private engineering channel that they could go into. And that was a place where you could just go, "Oh my gosh, I'm getting this error message. Does anybody know anything about this?" And you get kind of that same feedback where another person on the team will say, "Oh, yeah, I did that to you, sorry."
\n\nThe nice thing is that they will usually follow that with a link in the Slack channel to the conversation that they kicked off four hours ago or in the middle of the night last night or two days ago, depending on how long you've been out of sync with the repo. They'll come back and say, "Here's the conversation where I said this. These are the steps that you need to do to correct this." That's something you can't do at the water cooler is you can't be in the middle of a conversation with somebody and then hand somebody a link to the conversation that was had at the water cooler three days ago. That's kind of a fun sidebar.
\n\nThere are some efficiencies that you can leverage of remote work that I think we address the entire conversation around is remote work good enough to replace office work? And I think we overlook some things that remote work is very, very good at and very especially adapted to. So that's kind of a side tangent.
\n\nMARCOS: Yeah. And to add to that, I think you can encounter this many times. Like, there are some devs that ask a question, then there is someone that's going to reply to that thread. And he said that "Yes, I've been encountering that for many days," or something. And then there's going to be another dev which, "Oh, I introduced this some time ago." So if you could see that, there's that individuality of a developer that they do not tend to ask questions because not all developers are equal, so some ask questions, some don't. So they tend to just adjust to that scenario without asking.
\n\nSo because of that channel, they could surface their question, or they could say, "Yeah, I also experienced that." So now that there's a commonality with that, we could actually address that since it's a common problem for all. So that's one thing that I noticed very differently in other companies and here in Acima is that collaboration is really a priority. Everybody has a ticket, right? Everybody's busy. But everyone always checks the message and sees, oh, someone is having trouble. And if they knew or something came up to mind, they're not afraid to just chat it there. So that encourages you also to ask questions rather than keep it to yourself.
\n\nDAVE: That's awesome. Thank you. I think there might still be some meat on this bone to talk through. But we're coming up close on our hour here for record time. Do we have any parting shots, any closing thoughts? I'm assuming everyone in the room is pro versus against remote work. Any other shots?
\n\nDAVID: I think this has been a great conversation. I just wanted to finish with something that just comes to my mind. If you're working remotely, remember that you also need to be open to feedback. I think that's important. If you want to grow up there and to find the way and the standard of the team, that's something you have to keep in mind.
\n\nDAVE: Yeah, that's a nice circling comment to what you said at the top of the call where the necessary feedback was lacking that you have to go...and what I'm saying is if you're remote, you have to go after that feedback sometimes so people that will just like, oh, well, if I don't talk about it, maybe the problem will go away and --
\n\nMARCOS: And maybe people will forget if you don't chase that feedback. [laughs]
\n\nDAVE: Yeah. And that feedback can be essential to keeping your job. So you can accidentally let some information go by that you absolutely need. And if you were in the office, you would just pick it up and absorb it because it's kind of in the air. And if you're remote, you have to go digging for it sometimes.
\n\nEDDY: I have a question for those who prefer to go in the office or aren't opposed to. How can you be productive when it's really easy to reach over someone's shoulder and start a conversation? I don't know about you guys, but everyone in Acima is really nice. And it's really easy to start a conversation. I'll go on record and say if I'm in the office, [laughs] it's hard to get more work done as opposed to when I'm at home.
\n\nDAVE: Yeah, that's a really fair point. We've been talking about the communication channels purely from the viewpoint of communication carries sideband information that's really, really valuable, and we lose that when we're remote. But the advantage of being remote is that you lose that communication channel. That communication channel doesn't come find you and distract you. Having peace and quiet and time to think is kind of nice working remote.
\n\nEDDY: Yeah, being secluded, for me anyways, I can be more productive. But I'm just curious to gauge other people's opinions.
\n\nMARCOS: I've been someone asking someone in the office for some help. So that actually, like request timing also, like, let's say, what if the person is busy? So that's one thing that I encounter most of the time in the office when I was working in the office. So that actually sometimes discourages you to ask someone a question.
\n\nSo what I typically do is, even though I'm in the office, I just leave him a message. If that person is known to be like the busy guy, because there's always the busy guy that always stares at his computer, so I just leave him a message. So that kind of works the same way with working remotely. You can leave a message to the people and let them take their time to do the stuff that they need and just wait for them to reply.
\n\nDAVE: Yeah, that's actually a really good point that when you are in the office, it's very, very easy to have highly urgent conversations, not necessarily important conversation but urgent conversation. And when you are remote, it's much more easier to have asynchronous communication where you fire something off, and then you wait for a little while to get back.
\n\nAnd when you're remote, you can kind of get a little hamstrung where if you're like, "Hey, I need help with this," because you're down, right? It's like if your machine isn't working, you can't write software today until this gets fixed. You don't want to be in an asynchronous situation. You don't want to just like, oh, by the way, if anybody sees this sometime today or tomorrow, could you maybe get around it? No, it's like you need help right now, right? So it's kind of like urgent.
\n\nOne of the things that I have lamented this multiple times in the past but one of the things you can't do when you're remote is you can't go stand at somebody's desk and just be silent and awkward until they give you what you want. I love that about working in the office. It's just being awkward at your desk until you make me go away. And you can make me go away by giving me what I want, which is nice.
\n\nERIC: And it's more efficient. [laughs]
\n\nDAVE: Yeah.
\n\nEDDY: I'll tell you this because it brings up a pretty interesting point that we ran into a few weeks ago in the QA team where we're like, "Hey, should we update our laptops? Is it safe to update or not?" And we never got a concrete answer from IT. And I'm going to bring Zsolt in, and I'm sorry, Zsolt, to hear this, like, hello. But he's the only one really on the team who prefers to work in office, like in an office setting. So we just messaged, and we're like, "Hey, can you go bug IT really quick and just ask them a direct answer? Like, this would be nice to have." And he's like, "Yeah, sure. Give me like five minutes."
\n\nAnd so he's like, AFK. And then he comes back about 10 minutes later. And he's just like, "Oh, I have an answer. This is what it is." And I'm just like, well, that was fast. So you can be more efficient, I guess, and you can get your answers quicker [laughs] if you're in the office.
\n\nDAVE: Yeah. It's important to remember that when the shoe is on the other foot, it's the exact opposite. Like you just said, it's nice when you're remote to have that solitude and get your head down and get some work done. And you can't do that if David Brady is standing at your desk being awkward, waiting for you to babysit him. It's like, I got to get work done too, man. It's an interesting balance. And that's what I would say is it's a balance. Sometimes you got to lean hard to one side versus the other.
\n\nZACH: So there's a quick story I wanted to share from my last company of how we got, like, limited the hovering over the desk, especially for questions. And I think all of us as developers have done this before where you go and ask a question, and as you're talking through it, the answer just pops in your head, and you didn't actually need to take somebody else's time.
\n\nSo we were on a project that was just a big time crunch. And our VP of data science actually brought in like a six-foot stuffed bear [laughter] with a Jazz jersey and a hat, and he sat him in a chair at one of the desks at the beginning of our aisle. And before somebody was allowed to actually come talk to us, they had to talk it through with the bear to see if they got their solution from that or not.
\n\nDAVE: Nice.
\n\nZACH: I mean, it limited the distractions, and we were able to get the project out in time, half because I think a lot of people don't want to go sit and talk to a stuffed bear, and then the other half just basically they figured it out on their own talking to the stuffed bear.
\n\nEDDY: Kind of rubber ducking.
\n\nDAVE: I've heard that referred to as teddy bear debugging, or rubber ducking or teddy bear debugging, yeah.
\n\nEDDY: Rubberducking, yep.
\n\nDAVE: And yeah, like, by the time you serialize a problem in your brain to be able to stream it out as words, that's usually enough to reframe the problem in your head, not usually, but there's a fair amount where that's enough to solve...yeah, you said it already. I'll just...I'll shut up. [laughs]
\n\nZACH: And on the flipside of that, I think that when you work remote, it's more conscious effort to reach out to somebody than to turn your head and say, "Hey," right?
\n\nDAVE: Yeah.
\n\nZACH: Or just walk three feet away, five feet away. And so I think a lot of people actually kind of do that internally when they're remote.
\n\nEDDY: Zach, I'd argue that maybe there's been times where you'd you start to type a message to someone because you can't figure it out. In the middle of typing that out, you're like, oh yeah, that's the answer. It's kind of like a similar concept.
\n\nZACH: Yep.
\n\nMARCOS: And it happens most of the time.
\n\n[laughter]
\n\nZACH: I just noticed since we've gone remote, when I get questions, they're hard issues. I mean, some of the time, it's something that I just know because of my experience here. But a lot of the time, it's something where I'm like just researching with one of the team members on how to get past it.
\n\nDAVE: Yeah. That is awesome. I want to thank everybody for coming out today. David, Marcos, you're still here, Zach is still here, Eddy is still here. Thanks for coming out today. This was a fun chat.
","summary":"In this episode, we talk about remote work vs. being in the office. Pros and cons! Ups and downs!\r\n","date_published":"2023-01-18T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/eb53402e-b15c-4091-8704-515d53bd6a89.mp3","mime_type":"audio/mpeg","size_in_bytes":45085219,"duration_in_seconds":2470}]},{"id":"3633e7aa-333c-4304-9ea9-903d6dd17caf","title":"Episode 8: Code Cleanliness and Organization","url":"https://acima-development.fireside.fm/8","content_text":"Today we talk about code cleanliness and organization and the importance of it all.\n\nTranscript:\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'll be hosting today. We are going to be talking about code cleanliness and organization and the importance of that. Let's go ahead and introduce the other people who are here today. David, do you want to introduce yourself?\n\nDAVID: Sure. I'm David Solano. I've been here in Acima for a little bit more than a year, basically programming Ruby on Rails. I would love to talk about this important subject.\n\nMIKE: Great. Ramses, do you want to introduce yourself? \n\nRAMSES: Hi, everyone. I am Ramses. I'm primarily a Rubyist, a little bit of JavaScript as well. So I'm excited to be in this discussion. \n\nMIKE: Eddy, do you want to introduce yourself?\n\nEDDY: Hey, everyone. I love these. Thanks for including me. As he said, I'm Eddy. Thank you for having me.\n\nMIKE: Yeah, let's introduce our topic a little bit. And I've been thinking about a good way to introduce this topic. I wanted to start with a story and talk a little bit about my wife; she is an organizer. Let me clarify that there are a lot of people who like to have things organized. It's like something that they like; that's not what I'm talking about. My wife treats organization as a science. [laughs] She doesn't just think, oh yeah, I like to have things organized. She treats it almost professionally. \n\nWhen she comes into an area of a home or a building and wants to make use of it, she looks at the space, thinks about the shape of the space, and thinks about it in great detail, does research. Her mind just gets cranking and figures out the ideal way to organize the space so that it's most useful. She's taken, classes. She follows prominent organizers (There's such a thing.) since before they were popular. It's like a thing she's brilliant at, a lot of background. And this spills over to other areas where she'll come up with better ways to do things like an algorithm for solving a problem that's slow; she'll think, well, why don't you do it this way? Oh yeah, that's better. \n\nBut just on a very small scale, we have a pantry where we store stuff near our kitchen. We'd buy stuff for years and throw stuff in there, and it just went there to die. [laughs] It wasn't very well organized. There was food in there that we liked to eat, but it would end up tucked behind something, and we'd forget about it. And we'd end up buying the same thing a while later, forgetting the original stuff was there. Then we'd go clean out like, oh, wait, this has gone bad. It was never very useful. \n\nSo my wife thought about that, did her planning that I talked about, got an appropriate set of containers, put in shelving, arranged the pantry so that everything that is in there is in. And, you know, we had to decide what we were going to put in there. There are some things that didn't get a go. And everything that is in there is an appropriately sized container that is labeled and highly visible on a shelf; there's no too deep anywhere. And things we use less of are in smaller containers. There's some shelving on the inside of the door as well that nests in, so it fits perfectly. It's kind of amazing, honestly. [laughs] \n\nThe interesting thing is you can't just throw stuff into the pantry anymore. But we use it far more than we ever did before. Although it takes a little bit of time to make sure everything's put in the appropriate bins, it's immediately obvious. You walk in there, and you know in a moment where the thing that you want is. And we use it multiple times a day. That's where we go for a lot of our food because it just works so well. \n\nThere are several interesting things that I've learned from this. Organization isn't just about convenience. It fundamentally changes the way that something can work. This area went from a place that we occasionally used for things we thought, oh yeah, I think we can have long-term storage in here, to kind of a fundamental extension to our kitchen and where most of the stuff that we actually cook with is because that organization allowed us to use it differently. I think that code being so abstract it's easy to misunderstand or to just not be able to think about it very easily. And having these parallels in the physical world allows us to understand better that, hey, wait, there's something to be said about that. \n\nWhen we're writing code, we run into a lot of similar constraints. When we have code that we've just kind of thrown stuff together and allowed it to build over time, which is the easiest way to let things happen, it's kind of how code usually goes. If you're not very conscientious about it, then you end up with a structure that's kind of formed ad hoc, and it gets harder and harder to work with. And it's not just a small thing like superficially hard like, yeah, that's kind of not aesthetically pleasing to me. But it makes it less and less useful. \n\nYou accumulate what we call technical debt, which is doing something quickly now that you'll have to pay back later. It can actually accumulate to the point where it's very hard to get anything done because it's really hard to tell when you make a change whether it will have ripple effects somewhere else in the code that's really hard to understand because you can't see it. You can't wrap your head around it. I've got other stories I could tell, but I wanted to start with that one to set the stage for our discussion.\n\nRAMSES: I think you bring up an interesting point; when the code is organized well, it makes it easier to think about and easier to find things. Like, in a pantry that's disorganized, back to your analogy, if it is disorganized, it's hard to find things. And you often buy the same thing even though you already have it, and it's perfectly usable.\n\nMIKE: Oh, I'm thinking about times I've had to navigate messy code and tried to find something. [laughs] I have absolutely seen people rewrite code that does the same thing as what was already there because they couldn't find it.\n\nDAVID: This just reminds me, like when I started coding, there were no standards obviously in the place that I was. So I was just writing code, writing code, at the end, it was working. Six months later, when you have to go back to make a change or something, it was extremely difficult because you probably have forgotten about it. When you take a look at it, it is like, oh my God, who did this? Oh, it was me, but I don't remember now. \n\nMIKE: [laughs]\n\nDAVID: And it's working. But why did I do it in this way? Nowadays, it's, for example, people working in places like Acima, which has standards, we follow our code review process. We guarantee that new code always follows good standards, and it's probably a little bit more easy to organize. That doesn't mean that maybe we're going to switch it later to a team that needs to do delivery faster. \n\nI have also been there on teams that there is one team which has time to build code in a proper way and another team that they just deliver. It doesn't matter how you write it; try to write as good as you can but just write your code and try to do the delivery as fast as the client requests. And as you mentioned, add a ticket to work on this later for the other team, but unfortunately, I think sometimes it adds a little bit more complexity to the code. I believe it's something that we need to avoid.\n\nMIKE: That's interesting, one team that does a bunch and the other team that cleans up. Do you think that that actually ends up going faster in the long run? One team that just tries to go fast, another team cleans up?\n\nDAVID: No, it will definitely add more time to the other team, especially if they need to do a change of something.\n\nMIKE: Yeah, there are some choices that you can make, shortcuts you can take in the code that might save a little time in implementing it in the short term, maybe, but in the long term, make it much slower because it's harder to work with, and sometimes very small changes that have big impacts for years afterward. I believe strongly that taking a little bit more time to do it better upfront usually doesn't take more time. \n\nTo share a recent story, I won't go into deep details about the project; there's a team that was trying to get a project done quickly. And they thought, well, this is so urgent. We don't really have the time to coordinate and get all of the names in common, and it's just names, right? Making sure that we're on the same page about what things should be called. We're not going to get all that straight ahead of time because we just need to get going, so we just need to get coding. \n\nAnd several months later, after implementing it the third time, [laughs] they finally got it out after having coordinated and gotten all the names straight. The process of trying to get things working across teams when they didn't have the contracts well established, and those boundaries well understood meant that they didn't match, and it was kind of a disaster. And doing it the way that should have been done in the first place actually worked. Luckily, we don't have a habit of doing things that way around here. It was anomalous, but it was kind of eye-opening to see that this one project that they tried to rush didn't work. It didn't work. And that's just a single example.\n\nIf you build your code that way for years...and I've been in a number of places over time, and I've seen code that just created things on top of the mess, more and more and more, you know, just shovel it onto the pile. It may save a small amount of time upfront, but oftentimes it doesn't even save you time then. It can take more time to try to take the shortcut than to do it the long way. Everybody who has in the real world tried to take a shortcut has likely found that oftentimes the shortcut actually takes longer. [laughs] It works that way in software too. Have you all had that experience?\n\nDAVID: Probably I've mentioned this in other podcasts; I'm not sure. But there was one big function, so big that it takes like, I don't know, hours to finish. It needed to be completed in minutes because we needed to run it at night, so we don't affect any clients. But we needed to do some changes there. The function was extremely confusing to understand, and to fix it that we decided to just drop it and start one from the business side logic and created a new one following good standards. \n\nOnce we finished it, from hours to finish, it just took minutes. It still was heavy, but the approach we followed was to just build it from scratch because it was so difficult to understand. There was so much business logic there that it was just better to do it from scratch than to try to fix something that is already too tight.\n\nMIKE: And did you even rebuild it with performance in mind, or did you just rebuild it, and it worked?\n\nDAVID: Oh no, we built it with performance in mind because we took a look at some of the ways they were doing some cycles in the code. And they were performing a lot of queries to the database. Instead of just pulling one amount of records first, work on them, and then pull some other records later, they were just pulling on one record. They had the N+1 problem a lot of times there. So yeah, we thought about performance first. \n\nAnd we also thought of something which I've mentioned some times in architectural meetings. We thought of building a guide about how this process works because all the business logic was in the code, but it was spread across multiple people. So you have to ask someone from legal, someone from, I don't know, who worked with the clients to know why this process works in this way, someone from another department to know why this process works in this way. So we gathered all that information, and we built some guide first, so we documented everything. And then, we managed to code the version again.\n\nAnd after we coded in a proper way, there was already a guide and some documentation that you can first read and understand from like a lecture. And then you can go and take a look at the code, and then you'll see, oh, now this makes more sense. So we did those two approaches, which I think was a good approach in order to do that.\n\nMIKE: To talk about refactoring something for performance, I was involved in a project a number of years ago. I was working for a company to build a CMS, a content management, and we had code that would display advertisements. But the CMS we provided was...the company is defunct now, so I could probably talk about it, but it was for primarily newspapers, magazines. The publishers were moving online. And sometimes, they worked with advertisers, so we had to have our own ad network. But mostly, we worked with external ad networks. \n\nBut we also had our own in-house ad network at the time so that these publishers could run ads from their local merchants. A car dealership, for example, might want to advertise on the site, and we had support for that. And we noticed that the serving of ads because there were a lot of them on a page, was more than half of all of our database load. And just our overall time in our application, more than half of it, was just serving these ads, which seemed really excessive given that the ads were relatively simple. And there's all the work of publishing the articles and showing all of that content, but the ads ended up dominating that. \n\nSo we extracted that code out and just built it from scratch in a really small microservice. It really didn't do very much. It just was very focused on delivering the ads, and that's it. And once we had that built and took it out of the primary app, it went from being most of our database load to being almost unmeasurable; it was just 1% or 2%, I think. It was an insignificant part of our load. Just cleaning it up, just cleaning up the code, and getting it out into its own place where you could see it and think about it made a tremendous difference. And then we basically forgot about it because it just worked.\n\nDAVID: Yeah, that sounds great. I wanted to bring something now that we're talking about cleanliness. I'm not a big fan of unit tests, [laughs] but I know they are pretty good in order to ensure that your code works as expected. And this is something that I found in this process of knowing how to code in a better way. If you find that your unit tests, for us RSpec, if you find that your code is getting a bit more complicated to test, that means that maybe your code is not coded in the proper way, and you're adding more than you need there. \n\nSo this is something that I actually use to ensure that I'm writing something that other people can understand and that I'm doing it in a proper way too. Because I've been there that I'm trying to test something that is just not possible to test in the same class, and you know, oh, maybe I need to move this to another class because it's a completely different thing. So yeah, I believe unit tests are a good tool to write better code, clean code. \n\nAnd I think this is something that here we can do; I mean, we have good examples here because we're being clean in the current RSpec we have writing here in our project. And, I don't know, the other guys can tell me if they have found it, but I have seen some examples where trying to test the code is hard sometimes because maybe we could have done a bit better in the way we did that class or something like that. But yeah, I think it is just amazing to ensure that you are making an easier code or clean code to save some time.\n\nMIKE: I think that's a fantastic point. Well, unit tests have several things that they are good for; sometimes, what their primary value is is not what you think their primary value is, [laughs] I'll put it that way. You think, well, I just want to verify that my code is correct and unit tests are good at that. But if you've thought through your code wrong, you're likely to think through it wrong on your test as well. So you're testing that your code does what you expect it to do, which was not what you should have done in the first place. \n\nTests can actually be misleading in that regard, but there are some things they're very good at, like allowing you to refactor and make sure your code isn't broken. And what you just said is a tremendous one, I think. It's a tool, an instrument. It gives you visibility into your code quality. If your code is easy to test, then that suggests that it's easy to think about because your tests are kind of like an external observer. And if your code is really easy to test, good on this branch, good on this branch, test both of them, and everything's good, that's a really good sign that your code is good. \n\nAnd if your code is really hard to test, then you probably have too much going on, right? I'm with you 100%. It's an excellent indicator. Ramses or Eddy, do you have any thoughts about using tests to kind of force yourself to keep your code clean?\n\nEDDY: So I can see the more in-depth I get into picking up tickets and breaking unit testing, I'm starting to see the benefit of why we have them. If you test with QA and unit testing, like, you're ensuring that the ticket or the dev ticket that you picked when you're deploying the master is working the way it's intended. So not only are you testing the code, but you're also testing the UI side of stuff. So I do see the benefit behind it. It can be quite stressful to wrap your head around at first, but I do see the benefits on unit testing for sure.\n\nMIKE: Another thing that got mentioned...I think somebody mentioned it. I think you mentioned it, David, but it may be you just said something that made me think about it, but I think you mentioned it. You talked about, I believe, RuboCop, which is what they call a linter, but it's also a static code analysis tool. We have those across languages that a linter is a tool that checks your code syntax and makes sure that it's clean. Static code analysis goes a little bit further and does some analysis on your code to check whether it has some security vulnerabilities or whether it has some complexity and just some kind of broader tests. And the boundary is a little bit fuzzy between those two. \n\nA really sophisticated linter might start going into some of the static code analysis. And a purely static code analysis tool might actually have some linting built in as well. But these related tools exist in a lot of languages. And I didn't use those early in my career, and now that I do use them, I think that they are fantastic. And I say I didn't use them; I didn't use them as much, I'll say that. I don't think I've ever completely gone without using those kinds of tools, whether your IDE makes them suggestions or I would run...certainly there's compiling where I'd run syntax checks. \n\nNow that these tools are more broadly available, I love them, RuboCop in the Ruby world, because it takes the job of enforcing consistency out of the hands of your peers. So your peers don't have to nag at you and say, \"Oh, you forgot to indent here.\" Instead, you can together come to a standard and usually use a community standard that says, \"This is how we're going to do it.\" And you all agree that you're going to do it that way, and now you don't have to think about it. Now everybody is coding to the same standard. \n\nAnd, generally, it's enforcing not just arbitrary choices like how far should you indent, resolve the tab versus space arguments [laughs] by just not having them, whatever linter you're using is going to make the choice for you, and you don't have to have the argument. But it goes further than that. It means that because you're not having those disagreements over...I'll come back to the idea of a bike shed. You're not having disagreements over irrelevant things. You can actually talk about relevant things in your reviews. \n\nWhen you have one of your peers reviewing your code, they are not thinking about how distracted they are by some syntax somewhere because they don't have to. They get to think about structure and whether it actually solves the problems that it's intended to solve, and that's a much better thing to be thinking about. It's much better discussions to be having. They're much more fruitful and likely to lead to better changes than just making some superficial changes. \n\nComing back to the idea, there's a widespread idea in software about bikeshedding and the idea that, as a verb, you bikeshed. It's a verb. And where that verb comes from is the idea you build something very complicated like a nuclear power plant. People in the community are really not going to share an opinion as to what the design of the reactor is going to be because they don't have the expertise to make that kind of choice. There are going to be a few people who have that expertise who will evaluate the parameters and come to a decision. So it's a very important decision that will have decades-long impact, but only a few people will participate. \n\nBut if you build a shed out front to keep bikes dry when people go up to park at the facility, and you ask what color it should be painted, you will have long, maybe months-long arguments and debates of people expressing their opinion as to what color that shed should be painted. And the idea here is that the debate over something is usually inversely proportional to how important it is. The more important a decision is, the less likely it is to be debated. \n\nAnd linters help with that problem because they remove that lengthy discussion over irrelevant topics. And what colors should be painted? Well, it's always going to be black, and you don't have to make that decision. In the end, that decision didn't matter very much. It frees your mind to talk about the more important things. It's an aspect of code cleanliness, keeping your syntax clean, that I think it's fundamentally important. You can't understand code very well if it's a mess. But you can solve that by using an automated tool to tell you how to do it and then do it that way. \n\nDAVID: Yeah, I totally agree. And I'm glad you brought this up, Mike, about RuboCop. I also have...sorry about that. So when I started coding and I was introduced to RuboCop, I was angry [laughs] because it was highlighting all my errors in the code and, like, who invented RuboCop? I was so angry. \n\nMIKE: [laughs]\n\nDAVID: Of course, I was a junior, and in those times, I was thinking that I was right in the way I was writing code. And then I realized that, no, this is actually a good tool because it provides you a better way to do things. And it also ensures that other people that are going to, which is the most important thing. Also, if other people are going to change your code, at least it follows a standard there. So yeah, it's a pretty good tool. \n\nAnd this is something that I'm glad that Ruby has, so RuboCop is one of those. And I also wanted to mention another one which is Rails best practices, which also allows you to follow good practices in Rails. So this is just great in order to talk about important topics, as you mentioned, in your code and not only maybe the way you just coded something. A tool is already going to provide you with a fix, with highlighting the error and using it in a proper way. So yeah, I'm glad we use those tools here in Acima.\n\nMIKE: You know, some languages, you can take languages with syntactic whitespace like Python, for example, they structure the whole language to enforce certain conventions. So you can't argue with it. Your code won't work unless you write it cleanly. And it doesn't solve all problems, but it does solve some. And there are proponents and detractors of that idea out there; not everybody loves it. \n\nBut there's a reason that people would have that idea and push it forward because it's just so important to have that consistent syntax to be able to work together as a team that it's worth having it baked in the language where you can't even get your code to run unless you follow that standard. There's a reason that people would build something that way, whether or not you think that you should do it that way. It suggests that there's enough value that some people have considered doing it that way.\n\nDAVID: Yeah, definitely. And this also saves time. And I wanted to mention this because last time we had our weekly meeting, we mentioned that no one is going to code review your code if you don't ensure that RuboCop passes. [laughs] And it's something good because it is our team's standard. And it also ensures that you're going to present some code that follows the team standard and follows the rules that RuboCop currently has. So this is something really good.\n\nMIKE: I agree with you on that. If you're not used to doing it that way, it can sound like, wow, that's a pretty strict rule. You won't even review my code if it doesn't have clean syntax? I'd say the opposite is true. If you don't have a rule like that, then you're forcing the reviewer to have to make comments like, \"I don't like the way this is structured. It doesn't really follow the standards.\" You are coercing your peer into evaluating parts of your code that it shouldn't be their job to have to review.\nWhy should they have to enforce community standards when that can be automated? It's kind of silly and, arguably, kind of rude that you would ask somebody else to do work that you could have automated. It's part of, I think, taking pride in your code, being a craftsperson to be willing to just take that little extra time to make sure that you follow the standards.\n\nDAVID: I agree. A few years ago, we didn't implement this RuboCop in one of our projects, and we, the devs, spent a lot of time just trying to have our team standards like, hey, make a breakpoint here; this is a new line. And oh no, do an end instead of curly brackets here. And all that time could have been saved if we had used RuboCop. Because we used to have like 20 comments per code review [laughs], and that was just a lot, something that RuboCop could have just fixed in a couple of minutes or seconds, actually.\n\nMIKE: And you can integrate that into your editor, and then you don't even think about it. Because you get syntax highlighting that says, \"Your code is not following the standard here.\" I learned to see from a long way off in my editor; oh, I know exactly what's going on there. It's just got the underline or the color saying something is going on here. \n\nI know, even without having hovered over to see what the message is, I know exactly what the problem is. Because, like, oh yeah, I bet that that's saying I haven't added a comment on my class to say what it does, or I bet that's saying my line is too long. So you end up internalizing it to where you do it without even thinking about it, which is great. \n\nSo let's see, we've talked about how messy code takes longer to work with and may not even save you time to make the mess in the first place. We have talked about the value of following standards. We've talked about the value of sometimes refactoring and starting over from scratch and building something clean because it saves you more time than trying to fix code that is so messy that it is unsalvageable. \n\nI think there are some other interesting questions here. One interesting one, I think, is how do you start a project clean? How do you start it with standards such that you avoid a lot of these problems upfront? You're never going to avoid all the problems. Just by natural growth, I think any system is going to develop parts that are more complex than other parts. And in that natural progression, you'll notice that this part has become more complex than it was initially, and I need to go in and refactor it. \n\nSo I don't think you can universally avoid problems, and just naturally, some things are going to be more complex than others. However, I do think that you can avoid a lot of the worst pitfalls by starting off with good standards and good structure. I have some thoughts on this, but I'm curious what you all think.\n\nEDDY: I like the idea of clean code; for example, the concept of self-documenting code is really important, especially to me when I'm viewing a file for the first time. And I think that the code should be describing what the code intends to do by itself without the need of following the syntax per se. I think the Ruby syntax really aids in that as well because it reads in English. But having the code do the talk for you is really important.\n\nMIKE: That's interesting. We've talked about things we can use to measure whether the code is good or not. Like you say, if you read the code and it looks like English and reads like prose, the code itself reads like documentation, that's a good sign that it's well-organized and easy to understand. And if you have to stop and think about it or if you have to have a lot of comments to explain it, maybe you've done it in a way that is not easily thought about, and it'd be better to reorganize that. \n\nAs David was saying, that person that comes back and doesn't understand it is likely to be you six months from now or maybe one month from now sometimes. [laughs] Future you is not going to remember current you very well. And it's going to come and try to figure out what current you is doing and wish that you had been more conscientious.\n\nEDDY: Or having easy-to-understand names, [laughs] like, that's really, really, really important.\n\nMIKE: I think we could have a whole session on that one. I think it's funny that, as developers, we'll sometimes think we're saving time by dropping a few characters in a variable name, like, oh, I'm not going to put these characters in there because I want to save those three characters of typing, which takes you some fraction of a second. But then, when you come back and try to think about the problem, you have to figure out what that variable name is, and it takes you several seconds every time you look at it. What time have you saved? \n\nI think you almost never save time by coming up with abbreviations because they force you to have to think more about it. And that thinking about it takes a lot more time than the trivial amount of time it takes to type a couple more characters. I mean, we've got good tools for input. Even if you have some, you know, I sometimes get some repetitive stress of it, and I don't want to be banging away on the keyboard all the time. And despite that, I think variable names should be long because it just doesn't add very much to write a few more characters to make your names easy to read. \n\nAnd yeah, to ask my question that I was asking before a little bit again, how do you get the standards from the beginning? I could make some suggestion there that, in most cases, it makes sense to go with some sort of community framework rather than thinking I'm just going to start things from scratch and put it together as it goes. I want it to grow organically. Well, okay, things do grow organically, but people who garden put up a trellis for their climbing vines because they want to give them an opportunity to grow and not just sprawl out across the ground. \n\nThis idea that things growing should not be restricted at all, I think, is misguided. Things grow better when given an opportunity to climb up a structure toward the sky. And if we give them that structure, to begin with, then things will grow organically to fill in the space that you're providing for them. And if you don't provide them that space, then they'll hit those constraints very quickly. And you're going to have to rebuild it, and rebuild it, and rebuild it, and create those constraints over time, which is much harder than adding some constraints up front. \n\nAnd specifically, I think it makes sense to say, well, this is where these kinds of files go. In some languages, you're not going to have as much opportunity there. But almost everything you're going to work in is going to have some sort of framework, and then you can think about architecture. Well, what if I'm going to use model–view–controller architecture? So I'm going to have my data layer over here, and I'm going to have my logic layer here. And I got my presentation layer over here. \n\nTaking the time upfront to separate those ideas, to separate that code, and organize it is worth it. It is absolutely worth it, and that's why frameworks are popular. Also, they do a lot of the lifting for you. But the convention, the code conventions, this is where you put things is sometimes underappreciated as a vital part of what those frameworks provide you. It's not just the libraries they provide, which are invaluable, but it's also the structure.\n\nDAVID: I totally agree with that. I've tried to create a few projects in the last few months just for fun. So I like the fact that when you're going to start a new project, the language itself or the framework itself provides you with the tools as you manage your code better. I don't want to start to go into details, but, for example, with React, if you try to use React, sometimes they enable the ESLint; I think maybe it is called. \n\nSo if you make some syntax errors or just code in some weird way, it will highlight the error, and your code won't compile, [laughs] and that's good. You probably get a little frustrated at the beginning, and then you'll be glad that it highlighted that error because it will definitely save you in the future.\n\nIn the case of Ruby, I do agree that when you're going to start a Ruby or a Ruby on Rails project, you should add these valuable gems we talked about, like RuboCop is one of them. Bullet is another one which will highlight the N+1 error or how your queries are in the database. So yeah, I think that's a good approach; use everything that frameworks provide in order to code better and clean.\n\nMIKE: I'm with you. [laughs] Bullet is a nice tool. As you say, it looks for things you do with the database that you shouldn't. [laughs]\n\nDAVID: Yeah, it has saved me sometimes, [laughs] a lot of times to be honest.\n\nMIKE: Great. I think that we're reaching the end here, the time we were going to spend. Does anybody have any final thoughts that they've been holding in they'd like to share about code cleanliness and organization?\n\nDAVID: I just wanted to close that having team standards is extremely valuable in projects because they let you grow up as a developer and also as a person because you will understand the way the team works and the way you should also think if you go into that team. That also provides or gives you a way of knowing how mature a team is. And here in Acima, it's something that we actually have. \n\nWe have changed our standards too. I mean, we have had a few meetings where we'll talk about why we changed this in this other way. And we come to an agreement, and if it is good for our team, we change it. And so this is something great that a team should have. And it is something that is so valuable because it will help you code better. It will help you understand more the way to code and also the way the team works. I just want to highlight that. I'll finish with that line.\n\nMIKE: Again, you said it wonderfully. Those team standards just make such a difference. Maybe I conclude here by tying back to where we started, the idea of organization. And I say we should all be more like my wife [laughs] and treat organization not just as an aesthetic concern, like, I like the way this looks, but realize that it's a fundamental characteristic of something that is easy to use, and that is maintainable in the long term. \n\nTake some time to learn some of that science of some of the process that is involved in creating good structure, good hygiene, good cleanliness in our code so that we can maintain our software into the future. Take the time to develop those team standards because it's worth it. It's been great talking, and I'll see you next time on our Acima Development Podcast.","content_html":"Today we talk about code cleanliness and organization and the importance of it all.
\n\nTranscript:
\n\nMIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'll be hosting today. We are going to be talking about code cleanliness and organization and the importance of that. Let's go ahead and introduce the other people who are here today. David, do you want to introduce yourself?
\n\nDAVID: Sure. I'm David Solano. I've been here in Acima for a little bit more than a year, basically programming Ruby on Rails. I would love to talk about this important subject.
\n\nMIKE: Great. Ramses, do you want to introduce yourself?
\n\nRAMSES: Hi, everyone. I am Ramses. I'm primarily a Rubyist, a little bit of JavaScript as well. So I'm excited to be in this discussion.
\n\nMIKE: Eddy, do you want to introduce yourself?
\n\nEDDY: Hey, everyone. I love these. Thanks for including me. As he said, I'm Eddy. Thank you for having me.
\n\nMIKE: Yeah, let's introduce our topic a little bit. And I've been thinking about a good way to introduce this topic. I wanted to start with a story and talk a little bit about my wife; she is an organizer. Let me clarify that there are a lot of people who like to have things organized. It's like something that they like; that's not what I'm talking about. My wife treats organization as a science. [laughs] She doesn't just think, oh yeah, I like to have things organized. She treats it almost professionally.
\n\nWhen she comes into an area of a home or a building and wants to make use of it, she looks at the space, thinks about the shape of the space, and thinks about it in great detail, does research. Her mind just gets cranking and figures out the ideal way to organize the space so that it's most useful. She's taken, classes. She follows prominent organizers (There's such a thing.) since before they were popular. It's like a thing she's brilliant at, a lot of background. And this spills over to other areas where she'll come up with better ways to do things like an algorithm for solving a problem that's slow; she'll think, well, why don't you do it this way? Oh yeah, that's better.
\n\nBut just on a very small scale, we have a pantry where we store stuff near our kitchen. We'd buy stuff for years and throw stuff in there, and it just went there to die. [laughs] It wasn't very well organized. There was food in there that we liked to eat, but it would end up tucked behind something, and we'd forget about it. And we'd end up buying the same thing a while later, forgetting the original stuff was there. Then we'd go clean out like, oh, wait, this has gone bad. It was never very useful.
\n\nSo my wife thought about that, did her planning that I talked about, got an appropriate set of containers, put in shelving, arranged the pantry so that everything that is in there is in. And, you know, we had to decide what we were going to put in there. There are some things that didn't get a go. And everything that is in there is an appropriately sized container that is labeled and highly visible on a shelf; there's no too deep anywhere. And things we use less of are in smaller containers. There's some shelving on the inside of the door as well that nests in, so it fits perfectly. It's kind of amazing, honestly. [laughs]
\n\nThe interesting thing is you can't just throw stuff into the pantry anymore. But we use it far more than we ever did before. Although it takes a little bit of time to make sure everything's put in the appropriate bins, it's immediately obvious. You walk in there, and you know in a moment where the thing that you want is. And we use it multiple times a day. That's where we go for a lot of our food because it just works so well.
\n\nThere are several interesting things that I've learned from this. Organization isn't just about convenience. It fundamentally changes the way that something can work. This area went from a place that we occasionally used for things we thought, oh yeah, I think we can have long-term storage in here, to kind of a fundamental extension to our kitchen and where most of the stuff that we actually cook with is because that organization allowed us to use it differently. I think that code being so abstract it's easy to misunderstand or to just not be able to think about it very easily. And having these parallels in the physical world allows us to understand better that, hey, wait, there's something to be said about that.
\n\nWhen we're writing code, we run into a lot of similar constraints. When we have code that we've just kind of thrown stuff together and allowed it to build over time, which is the easiest way to let things happen, it's kind of how code usually goes. If you're not very conscientious about it, then you end up with a structure that's kind of formed ad hoc, and it gets harder and harder to work with. And it's not just a small thing like superficially hard like, yeah, that's kind of not aesthetically pleasing to me. But it makes it less and less useful.
\n\nYou accumulate what we call technical debt, which is doing something quickly now that you'll have to pay back later. It can actually accumulate to the point where it's very hard to get anything done because it's really hard to tell when you make a change whether it will have ripple effects somewhere else in the code that's really hard to understand because you can't see it. You can't wrap your head around it. I've got other stories I could tell, but I wanted to start with that one to set the stage for our discussion.
\n\nRAMSES: I think you bring up an interesting point; when the code is organized well, it makes it easier to think about and easier to find things. Like, in a pantry that's disorganized, back to your analogy, if it is disorganized, it's hard to find things. And you often buy the same thing even though you already have it, and it's perfectly usable.
\n\nMIKE: Oh, I'm thinking about times I've had to navigate messy code and tried to find something. [laughs] I have absolutely seen people rewrite code that does the same thing as what was already there because they couldn't find it.
\n\nDAVID: This just reminds me, like when I started coding, there were no standards obviously in the place that I was. So I was just writing code, writing code, at the end, it was working. Six months later, when you have to go back to make a change or something, it was extremely difficult because you probably have forgotten about it. When you take a look at it, it is like, oh my God, who did this? Oh, it was me, but I don't remember now.
\n\nMIKE: [laughs]
\n\nDAVID: And it's working. But why did I do it in this way? Nowadays, it's, for example, people working in places like Acima, which has standards, we follow our code review process. We guarantee that new code always follows good standards, and it's probably a little bit more easy to organize. That doesn't mean that maybe we're going to switch it later to a team that needs to do delivery faster.
\n\nI have also been there on teams that there is one team which has time to build code in a proper way and another team that they just deliver. It doesn't matter how you write it; try to write as good as you can but just write your code and try to do the delivery as fast as the client requests. And as you mentioned, add a ticket to work on this later for the other team, but unfortunately, I think sometimes it adds a little bit more complexity to the code. I believe it's something that we need to avoid.
\n\nMIKE: That's interesting, one team that does a bunch and the other team that cleans up. Do you think that that actually ends up going faster in the long run? One team that just tries to go fast, another team cleans up?
\n\nDAVID: No, it will definitely add more time to the other team, especially if they need to do a change of something.
\n\nMIKE: Yeah, there are some choices that you can make, shortcuts you can take in the code that might save a little time in implementing it in the short term, maybe, but in the long term, make it much slower because it's harder to work with, and sometimes very small changes that have big impacts for years afterward. I believe strongly that taking a little bit more time to do it better upfront usually doesn't take more time.
\n\nTo share a recent story, I won't go into deep details about the project; there's a team that was trying to get a project done quickly. And they thought, well, this is so urgent. We don't really have the time to coordinate and get all of the names in common, and it's just names, right? Making sure that we're on the same page about what things should be called. We're not going to get all that straight ahead of time because we just need to get going, so we just need to get coding.
\n\nAnd several months later, after implementing it the third time, [laughs] they finally got it out after having coordinated and gotten all the names straight. The process of trying to get things working across teams when they didn't have the contracts well established, and those boundaries well understood meant that they didn't match, and it was kind of a disaster. And doing it the way that should have been done in the first place actually worked. Luckily, we don't have a habit of doing things that way around here. It was anomalous, but it was kind of eye-opening to see that this one project that they tried to rush didn't work. It didn't work. And that's just a single example.
\n\nIf you build your code that way for years...and I've been in a number of places over time, and I've seen code that just created things on top of the mess, more and more and more, you know, just shovel it onto the pile. It may save a small amount of time upfront, but oftentimes it doesn't even save you time then. It can take more time to try to take the shortcut than to do it the long way. Everybody who has in the real world tried to take a shortcut has likely found that oftentimes the shortcut actually takes longer. [laughs] It works that way in software too. Have you all had that experience?
\n\nDAVID: Probably I've mentioned this in other podcasts; I'm not sure. But there was one big function, so big that it takes like, I don't know, hours to finish. It needed to be completed in minutes because we needed to run it at night, so we don't affect any clients. But we needed to do some changes there. The function was extremely confusing to understand, and to fix it that we decided to just drop it and start one from the business side logic and created a new one following good standards.
\n\nOnce we finished it, from hours to finish, it just took minutes. It still was heavy, but the approach we followed was to just build it from scratch because it was so difficult to understand. There was so much business logic there that it was just better to do it from scratch than to try to fix something that is already too tight.
\n\nMIKE: And did you even rebuild it with performance in mind, or did you just rebuild it, and it worked?
\n\nDAVID: Oh no, we built it with performance in mind because we took a look at some of the ways they were doing some cycles in the code. And they were performing a lot of queries to the database. Instead of just pulling one amount of records first, work on them, and then pull some other records later, they were just pulling on one record. They had the N+1 problem a lot of times there. So yeah, we thought about performance first.
\n\nAnd we also thought of something which I've mentioned some times in architectural meetings. We thought of building a guide about how this process works because all the business logic was in the code, but it was spread across multiple people. So you have to ask someone from legal, someone from, I don't know, who worked with the clients to know why this process works in this way, someone from another department to know why this process works in this way. So we gathered all that information, and we built some guide first, so we documented everything. And then, we managed to code the version again.
\n\nAnd after we coded in a proper way, there was already a guide and some documentation that you can first read and understand from like a lecture. And then you can go and take a look at the code, and then you'll see, oh, now this makes more sense. So we did those two approaches, which I think was a good approach in order to do that.
\n\nMIKE: To talk about refactoring something for performance, I was involved in a project a number of years ago. I was working for a company to build a CMS, a content management, and we had code that would display advertisements. But the CMS we provided was...the company is defunct now, so I could probably talk about it, but it was for primarily newspapers, magazines. The publishers were moving online. And sometimes, they worked with advertisers, so we had to have our own ad network. But mostly, we worked with external ad networks.
\n\nBut we also had our own in-house ad network at the time so that these publishers could run ads from their local merchants. A car dealership, for example, might want to advertise on the site, and we had support for that. And we noticed that the serving of ads because there were a lot of them on a page, was more than half of all of our database load. And just our overall time in our application, more than half of it, was just serving these ads, which seemed really excessive given that the ads were relatively simple. And there's all the work of publishing the articles and showing all of that content, but the ads ended up dominating that.
\n\nSo we extracted that code out and just built it from scratch in a really small microservice. It really didn't do very much. It just was very focused on delivering the ads, and that's it. And once we had that built and took it out of the primary app, it went from being most of our database load to being almost unmeasurable; it was just 1% or 2%, I think. It was an insignificant part of our load. Just cleaning it up, just cleaning up the code, and getting it out into its own place where you could see it and think about it made a tremendous difference. And then we basically forgot about it because it just worked.
\n\nDAVID: Yeah, that sounds great. I wanted to bring something now that we're talking about cleanliness. I'm not a big fan of unit tests, [laughs] but I know they are pretty good in order to ensure that your code works as expected. And this is something that I found in this process of knowing how to code in a better way. If you find that your unit tests, for us RSpec, if you find that your code is getting a bit more complicated to test, that means that maybe your code is not coded in the proper way, and you're adding more than you need there.
\n\nSo this is something that I actually use to ensure that I'm writing something that other people can understand and that I'm doing it in a proper way too. Because I've been there that I'm trying to test something that is just not possible to test in the same class, and you know, oh, maybe I need to move this to another class because it's a completely different thing. So yeah, I believe unit tests are a good tool to write better code, clean code.
\n\nAnd I think this is something that here we can do; I mean, we have good examples here because we're being clean in the current RSpec we have writing here in our project. And, I don't know, the other guys can tell me if they have found it, but I have seen some examples where trying to test the code is hard sometimes because maybe we could have done a bit better in the way we did that class or something like that. But yeah, I think it is just amazing to ensure that you are making an easier code or clean code to save some time.
\n\nMIKE: I think that's a fantastic point. Well, unit tests have several things that they are good for; sometimes, what their primary value is is not what you think their primary value is, [laughs] I'll put it that way. You think, well, I just want to verify that my code is correct and unit tests are good at that. But if you've thought through your code wrong, you're likely to think through it wrong on your test as well. So you're testing that your code does what you expect it to do, which was not what you should have done in the first place.
\n\nTests can actually be misleading in that regard, but there are some things they're very good at, like allowing you to refactor and make sure your code isn't broken. And what you just said is a tremendous one, I think. It's a tool, an instrument. It gives you visibility into your code quality. If your code is easy to test, then that suggests that it's easy to think about because your tests are kind of like an external observer. And if your code is really easy to test, good on this branch, good on this branch, test both of them, and everything's good, that's a really good sign that your code is good.
\n\nAnd if your code is really hard to test, then you probably have too much going on, right? I'm with you 100%. It's an excellent indicator. Ramses or Eddy, do you have any thoughts about using tests to kind of force yourself to keep your code clean?
\n\nEDDY: So I can see the more in-depth I get into picking up tickets and breaking unit testing, I'm starting to see the benefit of why we have them. If you test with QA and unit testing, like, you're ensuring that the ticket or the dev ticket that you picked when you're deploying the master is working the way it's intended. So not only are you testing the code, but you're also testing the UI side of stuff. So I do see the benefit behind it. It can be quite stressful to wrap your head around at first, but I do see the benefits on unit testing for sure.
\n\nMIKE: Another thing that got mentioned...I think somebody mentioned it. I think you mentioned it, David, but it may be you just said something that made me think about it, but I think you mentioned it. You talked about, I believe, RuboCop, which is what they call a linter, but it's also a static code analysis tool. We have those across languages that a linter is a tool that checks your code syntax and makes sure that it's clean. Static code analysis goes a little bit further and does some analysis on your code to check whether it has some security vulnerabilities or whether it has some complexity and just some kind of broader tests. And the boundary is a little bit fuzzy between those two.
\n\nA really sophisticated linter might start going into some of the static code analysis. And a purely static code analysis tool might actually have some linting built in as well. But these related tools exist in a lot of languages. And I didn't use those early in my career, and now that I do use them, I think that they are fantastic. And I say I didn't use them; I didn't use them as much, I'll say that. I don't think I've ever completely gone without using those kinds of tools, whether your IDE makes them suggestions or I would run...certainly there's compiling where I'd run syntax checks.
\n\nNow that these tools are more broadly available, I love them, RuboCop in the Ruby world, because it takes the job of enforcing consistency out of the hands of your peers. So your peers don't have to nag at you and say, "Oh, you forgot to indent here." Instead, you can together come to a standard and usually use a community standard that says, "This is how we're going to do it." And you all agree that you're going to do it that way, and now you don't have to think about it. Now everybody is coding to the same standard.
\n\nAnd, generally, it's enforcing not just arbitrary choices like how far should you indent, resolve the tab versus space arguments [laughs] by just not having them, whatever linter you're using is going to make the choice for you, and you don't have to have the argument. But it goes further than that. It means that because you're not having those disagreements over...I'll come back to the idea of a bike shed. You're not having disagreements over irrelevant things. You can actually talk about relevant things in your reviews.
\n\nWhen you have one of your peers reviewing your code, they are not thinking about how distracted they are by some syntax somewhere because they don't have to. They get to think about structure and whether it actually solves the problems that it's intended to solve, and that's a much better thing to be thinking about. It's much better discussions to be having. They're much more fruitful and likely to lead to better changes than just making some superficial changes.
\n\nComing back to the idea, there's a widespread idea in software about bikeshedding and the idea that, as a verb, you bikeshed. It's a verb. And where that verb comes from is the idea you build something very complicated like a nuclear power plant. People in the community are really not going to share an opinion as to what the design of the reactor is going to be because they don't have the expertise to make that kind of choice. There are going to be a few people who have that expertise who will evaluate the parameters and come to a decision. So it's a very important decision that will have decades-long impact, but only a few people will participate.
\n\nBut if you build a shed out front to keep bikes dry when people go up to park at the facility, and you ask what color it should be painted, you will have long, maybe months-long arguments and debates of people expressing their opinion as to what color that shed should be painted. And the idea here is that the debate over something is usually inversely proportional to how important it is. The more important a decision is, the less likely it is to be debated.
\n\nAnd linters help with that problem because they remove that lengthy discussion over irrelevant topics. And what colors should be painted? Well, it's always going to be black, and you don't have to make that decision. In the end, that decision didn't matter very much. It frees your mind to talk about the more important things. It's an aspect of code cleanliness, keeping your syntax clean, that I think it's fundamentally important. You can't understand code very well if it's a mess. But you can solve that by using an automated tool to tell you how to do it and then do it that way.
\n\nDAVID: Yeah, I totally agree. And I'm glad you brought this up, Mike, about RuboCop. I also have...sorry about that. So when I started coding and I was introduced to RuboCop, I was angry [laughs] because it was highlighting all my errors in the code and, like, who invented RuboCop? I was so angry.
\n\nMIKE: [laughs]
\n\nDAVID: Of course, I was a junior, and in those times, I was thinking that I was right in the way I was writing code. And then I realized that, no, this is actually a good tool because it provides you a better way to do things. And it also ensures that other people that are going to, which is the most important thing. Also, if other people are going to change your code, at least it follows a standard there. So yeah, it's a pretty good tool.
\n\nAnd this is something that I'm glad that Ruby has, so RuboCop is one of those. And I also wanted to mention another one which is Rails best practices, which also allows you to follow good practices in Rails. So this is just great in order to talk about important topics, as you mentioned, in your code and not only maybe the way you just coded something. A tool is already going to provide you with a fix, with highlighting the error and using it in a proper way. So yeah, I'm glad we use those tools here in Acima.
\n\nMIKE: You know, some languages, you can take languages with syntactic whitespace like Python, for example, they structure the whole language to enforce certain conventions. So you can't argue with it. Your code won't work unless you write it cleanly. And it doesn't solve all problems, but it does solve some. And there are proponents and detractors of that idea out there; not everybody loves it.
\n\nBut there's a reason that people would have that idea and push it forward because it's just so important to have that consistent syntax to be able to work together as a team that it's worth having it baked in the language where you can't even get your code to run unless you follow that standard. There's a reason that people would build something that way, whether or not you think that you should do it that way. It suggests that there's enough value that some people have considered doing it that way.
\n\nDAVID: Yeah, definitely. And this also saves time. And I wanted to mention this because last time we had our weekly meeting, we mentioned that no one is going to code review your code if you don't ensure that RuboCop passes. [laughs] And it's something good because it is our team's standard. And it also ensures that you're going to present some code that follows the team standard and follows the rules that RuboCop currently has. So this is something really good.
\n\nMIKE: I agree with you on that. If you're not used to doing it that way, it can sound like, wow, that's a pretty strict rule. You won't even review my code if it doesn't have clean syntax? I'd say the opposite is true. If you don't have a rule like that, then you're forcing the reviewer to have to make comments like, "I don't like the way this is structured. It doesn't really follow the standards." You are coercing your peer into evaluating parts of your code that it shouldn't be their job to have to review.
\nWhy should they have to enforce community standards when that can be automated? It's kind of silly and, arguably, kind of rude that you would ask somebody else to do work that you could have automated. It's part of, I think, taking pride in your code, being a craftsperson to be willing to just take that little extra time to make sure that you follow the standards.
DAVID: I agree. A few years ago, we didn't implement this RuboCop in one of our projects, and we, the devs, spent a lot of time just trying to have our team standards like, hey, make a breakpoint here; this is a new line. And oh no, do an end instead of curly brackets here. And all that time could have been saved if we had used RuboCop. Because we used to have like 20 comments per code review [laughs], and that was just a lot, something that RuboCop could have just fixed in a couple of minutes or seconds, actually.
\n\nMIKE: And you can integrate that into your editor, and then you don't even think about it. Because you get syntax highlighting that says, "Your code is not following the standard here." I learned to see from a long way off in my editor; oh, I know exactly what's going on there. It's just got the underline or the color saying something is going on here.
\n\nI know, even without having hovered over to see what the message is, I know exactly what the problem is. Because, like, oh yeah, I bet that that's saying I haven't added a comment on my class to say what it does, or I bet that's saying my line is too long. So you end up internalizing it to where you do it without even thinking about it, which is great.
\n\nSo let's see, we've talked about how messy code takes longer to work with and may not even save you time to make the mess in the first place. We have talked about the value of following standards. We've talked about the value of sometimes refactoring and starting over from scratch and building something clean because it saves you more time than trying to fix code that is so messy that it is unsalvageable.
\n\nI think there are some other interesting questions here. One interesting one, I think, is how do you start a project clean? How do you start it with standards such that you avoid a lot of these problems upfront? You're never going to avoid all the problems. Just by natural growth, I think any system is going to develop parts that are more complex than other parts. And in that natural progression, you'll notice that this part has become more complex than it was initially, and I need to go in and refactor it.
\n\nSo I don't think you can universally avoid problems, and just naturally, some things are going to be more complex than others. However, I do think that you can avoid a lot of the worst pitfalls by starting off with good standards and good structure. I have some thoughts on this, but I'm curious what you all think.
\n\nEDDY: I like the idea of clean code; for example, the concept of self-documenting code is really important, especially to me when I'm viewing a file for the first time. And I think that the code should be describing what the code intends to do by itself without the need of following the syntax per se. I think the Ruby syntax really aids in that as well because it reads in English. But having the code do the talk for you is really important.
\n\nMIKE: That's interesting. We've talked about things we can use to measure whether the code is good or not. Like you say, if you read the code and it looks like English and reads like prose, the code itself reads like documentation, that's a good sign that it's well-organized and easy to understand. And if you have to stop and think about it or if you have to have a lot of comments to explain it, maybe you've done it in a way that is not easily thought about, and it'd be better to reorganize that.
\n\nAs David was saying, that person that comes back and doesn't understand it is likely to be you six months from now or maybe one month from now sometimes. [laughs] Future you is not going to remember current you very well. And it's going to come and try to figure out what current you is doing and wish that you had been more conscientious.
\n\nEDDY: Or having easy-to-understand names, [laughs] like, that's really, really, really important.
\n\nMIKE: I think we could have a whole session on that one. I think it's funny that, as developers, we'll sometimes think we're saving time by dropping a few characters in a variable name, like, oh, I'm not going to put these characters in there because I want to save those three characters of typing, which takes you some fraction of a second. But then, when you come back and try to think about the problem, you have to figure out what that variable name is, and it takes you several seconds every time you look at it. What time have you saved?
\n\nI think you almost never save time by coming up with abbreviations because they force you to have to think more about it. And that thinking about it takes a lot more time than the trivial amount of time it takes to type a couple more characters. I mean, we've got good tools for input. Even if you have some, you know, I sometimes get some repetitive stress of it, and I don't want to be banging away on the keyboard all the time. And despite that, I think variable names should be long because it just doesn't add very much to write a few more characters to make your names easy to read.
\n\nAnd yeah, to ask my question that I was asking before a little bit again, how do you get the standards from the beginning? I could make some suggestion there that, in most cases, it makes sense to go with some sort of community framework rather than thinking I'm just going to start things from scratch and put it together as it goes. I want it to grow organically. Well, okay, things do grow organically, but people who garden put up a trellis for their climbing vines because they want to give them an opportunity to grow and not just sprawl out across the ground.
\n\nThis idea that things growing should not be restricted at all, I think, is misguided. Things grow better when given an opportunity to climb up a structure toward the sky. And if we give them that structure, to begin with, then things will grow organically to fill in the space that you're providing for them. And if you don't provide them that space, then they'll hit those constraints very quickly. And you're going to have to rebuild it, and rebuild it, and rebuild it, and create those constraints over time, which is much harder than adding some constraints up front.
\n\nAnd specifically, I think it makes sense to say, well, this is where these kinds of files go. In some languages, you're not going to have as much opportunity there. But almost everything you're going to work in is going to have some sort of framework, and then you can think about architecture. Well, what if I'm going to use model–view–controller architecture? So I'm going to have my data layer over here, and I'm going to have my logic layer here. And I got my presentation layer over here.
\n\nTaking the time upfront to separate those ideas, to separate that code, and organize it is worth it. It is absolutely worth it, and that's why frameworks are popular. Also, they do a lot of the lifting for you. But the convention, the code conventions, this is where you put things is sometimes underappreciated as a vital part of what those frameworks provide you. It's not just the libraries they provide, which are invaluable, but it's also the structure.
\n\nDAVID: I totally agree with that. I've tried to create a few projects in the last few months just for fun. So I like the fact that when you're going to start a new project, the language itself or the framework itself provides you with the tools as you manage your code better. I don't want to start to go into details, but, for example, with React, if you try to use React, sometimes they enable the ESLint; I think maybe it is called.
\n\nSo if you make some syntax errors or just code in some weird way, it will highlight the error, and your code won't compile, [laughs] and that's good. You probably get a little frustrated at the beginning, and then you'll be glad that it highlighted that error because it will definitely save you in the future.
\n\nIn the case of Ruby, I do agree that when you're going to start a Ruby or a Ruby on Rails project, you should add these valuable gems we talked about, like RuboCop is one of them. Bullet is another one which will highlight the N+1 error or how your queries are in the database. So yeah, I think that's a good approach; use everything that frameworks provide in order to code better and clean.
\n\nMIKE: I'm with you. [laughs] Bullet is a nice tool. As you say, it looks for things you do with the database that you shouldn't. [laughs]
\n\nDAVID: Yeah, it has saved me sometimes, [laughs] a lot of times to be honest.
\n\nMIKE: Great. I think that we're reaching the end here, the time we were going to spend. Does anybody have any final thoughts that they've been holding in they'd like to share about code cleanliness and organization?
\n\nDAVID: I just wanted to close that having team standards is extremely valuable in projects because they let you grow up as a developer and also as a person because you will understand the way the team works and the way you should also think if you go into that team. That also provides or gives you a way of knowing how mature a team is. And here in Acima, it's something that we actually have.
\n\nWe have changed our standards too. I mean, we have had a few meetings where we'll talk about why we changed this in this other way. And we come to an agreement, and if it is good for our team, we change it. And so this is something great that a team should have. And it is something that is so valuable because it will help you code better. It will help you understand more the way to code and also the way the team works. I just want to highlight that. I'll finish with that line.
\n\nMIKE: Again, you said it wonderfully. Those team standards just make such a difference. Maybe I conclude here by tying back to where we started, the idea of organization. And I say we should all be more like my wife [laughs] and treat organization not just as an aesthetic concern, like, I like the way this looks, but realize that it's a fundamental characteristic of something that is easy to use, and that is maintainable in the long term.
\n\nTake some time to learn some of that science of some of the process that is involved in creating good structure, good hygiene, good cleanliness in our code so that we can maintain our software into the future. Take the time to develop those team standards because it's worth it. It's been great talking, and I'll see you next time on our Acima Development Podcast.
","summary":"Today we talk about code cleanliness and organization and the importance of it all.","date_published":"2023-01-04T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/3633e7aa-333c-4304-9ea9-903d6dd17caf.mp3","mime_type":"audio/mpeg","size_in_bytes":40896268,"duration_in_seconds":2274}]},{"id":"5e1f62fb-43ec-4c9f-bea0-c7e8b48c3ff9","title":"Episode 7: Debugging Skills","url":"https://acima-development.fireside.fm/7","content_text":"Let's talk debugging skills! The conversation starts with some fun stories and experiences regarding debugging in general, and then panelists share thoughts about how to find bugs, lessons learned struggling through debugging, and how the way we structure code has a great deal of impact on debugging.\n\nTranscript:\n\nMIKE: Welcome to another episode of our Acima Development Podcast. We have, I think, an exciting discussion today. It's relevant to anybody doing development. We're going to be talking about debugging skills. Before going to that, let's go around and do some quick introductions. I'm Mike. I'll be hosting today. I've been a software developer for over 20 years, a Rubyist for most of that. Ramses, do want to introduce yourself?\n\nRAMSES: Hey, everyone. I've been a familiar voice on this podcast for a while now. I've been a Rubyist developer for about a year and a half and a professional developer, I guess now, for about six months, and at Acima for almost four years now. \n\nMIKE: Thank you. Afton.\n\nAFTON: Hi, this is Afton again. I am also hitting my four-year mark this week here at Acima. And I've been in Ruby and Ruby on Rails my whole career.\n\nMIKE: Thank you. Zsolt.\n\nZSOLT: Hello. I'm Zsolt. I've been doing hobbyist development for a little over ten years. I have been a Rubyist for about three months of that so far, very wonderful thing.\n\nMIKE: Great. I think that we've got a range of experience levels here, which will be really great for the discussion. I wanted to start the discussion with, let's say, a couple of stories. The first one is not my own. I had a friend who had a professor [laughs] who told me this story. This friend got the story from the professor. He had a professor who said...when he was teaching the class, he taught them the way you find the last blue wolf in Ireland. \n\nAnd the way you find the last blue wolf in Ireland is that you build a wall across Ireland. And then you stand up on the wall at night, and you listen for which side of the wall the wolf howls on. And then when you figure out which side that is, you build a wall through the middle of that side of Ireland. And then you stand up on the wall at night, and you listen, and when you hear the wolf howl, you know it's on that side of the wall. And then you build the wall through that section and do the same thing. And after a few iterations of this, you've found your wolf because you've cut down the problem size by half every time. That's my first story. \n\n[laughter]\n\nThe second one is more of a personal one. I've got a window well that has regularly flooded for years, and it's just been a persistent problem. Luckily, the basement is unfinished or mostly unfinished, but it's a hassle. When it floods, we have to peel up the...we got some foam floor, and we peel it off the ground and have to mop up the floor and scoop up the water and put it in a bucket and dump it. It's a pain. [laughs] And I've had to do this often, particularly when the rain comes from that side of the house. \n\nAnd I've tried all sorts of things to solve the problem. First thing I did was dug out some extra dirt in the window well. I thought, well, if I add some capacity to the window, well, the problem is that it's not big enough. Well, it didn't help. And I noticed that there's a drain pipe in there. It's a perforated pipe that goes down into the ground and connects to some others that go to a drain that comes into a sump with a sump pump. It drains the foundation, so we don't get flooding.\n\nAnd the pipe, I thought, well, you know, this pipe is really long. It's hanging up at the top. Maybe some kids shoved some stuff in the end of it because it's just perforated. Maybe water can't get in the top. So I shortened the pipe, didn't help at all. [chuckles] We still got flooding. I used some caulk, and I sealed the edges of the window well. I thought, well, maybe water is pouring in from the side when it rains heavily from that side, and if I seal the joints, that will help. And the same problem still happened. \n\nEarlier this year, I got a pipe auger or a pipe snake, like, long ones, so I could really run it down there, 50-foot long. And I attached a drill to the end, and I put it in there. And I thought, okay, there's probably some debris in there because it's just draining really slowly. So I ran in there, and I ran it in there, bzzzzzz, spun it around for a while. And I pulled out a little bit of mud and a little bit of grass, and not enough to matter.\n\n[sighs] What is up with this? As I was standing there looking at the window well, kind of scratching my head, I noticed that there is a drain coming down from the roof into some drain pipe that ran out through under the lawn and drained over into a low spot that drains out to the road. And I noticed that where that drain pipe came out, the grass had grown over it, so it was plugged over. And I thought, oh, I should do something to fix that, you know, I bet the water is not able to get down there very well. I should have thought a little harder about this. \n\nSo I went over and took a little shovel and cut out around the end so the water could drain out there. And I took a hose, and I thought, okay, I'm going to test this. And I took the hose over to the end of the drain pipe coming off the roof. And I noticed that where that drain pipe met the pipe that goes under the ground, they'd become dissociated. The ground drain pipe had loosened over time. It had been washed out a little behind and fallen off and slipped over to the side. \n\nSo the drain pipe coming off the roof wasn't going into the drain from the ground at all, and if it had, it was plugged at the end. So any water that was coming down there, and it was about three feet away from the window well, would have immediately just started flooding the area next to the house, gone straight down to the window well, and poured inside.\n\nAfter all these years of trying to figure out what was wrong with the window well, I realized the problem wasn't the window well at all. The water was coming off the roof and pouring straight into the window well. And there's no amount of drainage [laughs] that would have helped to solve that problem. The problem is it was just dumping water in every time it rained. \n\nI took the pipe that went underneath, connected it to the drain pipe, stuck a couple of rocks under it, just some pebbles nearby, to brace it so that it was high enough. And presumably, the problem is solved with a couple of little pebbles. Had I looked around the window well ten years ago when this problem started happening, I would have saved myself a lot of trouble. \n\nA couple of things I want to point out from this story, additional tools did not solve the problem. You know, I cut the pipe. I used the caulk to seal the joints, used the pipe auger, you know, I kept on escalating the tools I used to solve the problem. None of that solved it. What solved my problem was better observation of the situation and, in particular, of the context. Looking bigger than just at the window well and seeing the context that it was in allowed me to see that I was targeting the wrong problem. If I had looked a little bigger, I'd have seen what the underlying cause was for all the troubles I was having. \n\nI thought through these stories ahead of time since we're talking about debugging because I think they'll really inform our discussion talking about software and how to find the problems that we have. With that, [laughs] any thoughts from the rest of you about...well, you can start with the stories or about debugging in general, your thoughts about how to find bugs given this discussion so far.\n\nAFTON: That's such a good story. It brought a quote to mind from The Pragmatic Programmer I've been listening to. And I'm going to botch it. And I'm not even 100% sure it's related, but it's what came into my mind. [laughs] So it was saying that novices tend to try to fix problems by adding more correct code, or writing something to be more correct, or a new workable code. And experts go in and try to remove the problematic code. [laughs] So, I mean, first of all, you tried to add all these new solutions in, and then, in the end, you had something that was existing. You just had to refactor. I don't know how that works in -- [laughs]\n\nMIKE: Oh yeah, refactor, exactly. \n\nAFTON: Yeah. [laughs] That was a good quote.\n\nMIKE: The direction I've thought about this is I see a lot of people lean hard into their debuggers. And debuggers can be a useful tool. So I want to be careful here. I don't want to suggest that you should never use a debugger. That being said, a debugger is a sophisticated, complicated tool. And if you've got a complicated, hard-to-think-about problem, then adding something complicated and hard to think about as part of your solution may be problematic. \n\nAnd I have not, in my career, seen that debuggers have tended, you know, the fanciest of the debugger has not gone very far to helping people solve problems. For myself, I honestly don't use debuggers very often. I print out to the screen, and that's worked in every language I've ever worked in. It works in C; it works in Java; it works in Python; it works in JavaScript; it works in Ruby. If you print something out, and they've all got tools to do it, whether you're doing your console.log() or your puts, or your System.out.println(), if you can print something out to your screen while your program is running, you get that context.\n\nAnd you can put it where you think the problem is. You can put it on one side of the problem, going back to that blue wolf in Ireland. You can put it on one side of the problem and the other side of the problem, and you can isolate it, split the problem in half, figure which side it's happening. And such a simple tool means you don't really have to think about it; instead, you're just trying to identify which side of the wall the problem is on, cutting out half the problem that way. \n\nYou know, which side is it on? It gives you that visibility in a way that leaning really hard and trying to find all the things in one specific spot might not give you, you know, looking with a larger scope to cut the problem in half rather than getting hyperfocused on one spot. \n\nI'm going to say debuggers could be a solution; you know, there are some pipes that need an auger to be cleaned out. [laughs] But, in general, it's the awareness that you need to be concerned about, and if you get that with the debugger, great. But, you know, if you can just print something out to your screen, that probably will work just about as well and maybe even better because you don't have to think about it as much.\n\nZSOLT: Right. The interesting thing is that, for years, I've been told that print debugging is a terrible practice and you shouldn't do it. And I'm like, you know what? I'm going to respectfully disagree with that and do it anyway. \n\nMIKE: [laughs]\n\nZSOLT: Because it works very well for me. But I've also recently started using more actual debugging tools, and I do see where their uses stem from. But I do agree that you don't want to eat a bowl of cereal with an industrial food processor; I don't know.\n\nMIKE: [laughs] You can use that to process the cereal and avoid the chewing, but it might not be fun. \n\nZSOLT: Exactly. \n\nMIKE: Really well said. I've seen developers who are really, really good, and they often have minimal tools. They know the tools they use really well. I'm not trying to suggest that we shouldn't use tools, but they use them judiciously. [laughs] They learn that the tools don't necessarily solve the problem. It's the problem-solving that solves the problem. Ramses, what's been your experience with debugging?\n\nRAMSES: I'm pretty simple with debugging. I'll use a lot of print or put statements in combination with regular debuggers. If it's JavaScript, I'll just use a debugger. If it's Ruby, I'll use byebug or binding.pry, just so that I can do a quick analysis of whatever objects or logic I'm trying to investigate. \n\nMIKE: Makes sense. I want to talk a little bit about the first story that I shared about finding the last blue wolf in Ireland. It's a silly story, and sometimes the best ones are like that because they stick. [laughs] They don't have to be very serious, but they stick in your head. If you can cut up the scope of a problem in half repeatedly, it gets much smaller very quickly. It ends up taking the time relative to the base two logarithm of the data you're looking at. \n\nAnd the code that we look at is not generally tremendously big. And we might be working with millions of lines. Even if you have a million lines of code, you cut that in half once, and you're down to 500,000. That's a large size, but after you've gone through 20 iterations of cutting it in half, you've gotten to a pretty small problem set. It really doesn't take very long to cut things down when you cut them in half every time. \n\nBut I think a lot of times we neglect that idea when we're looking for problems. We think, well, I know where the problem is, so I'm going to look really, really close there and do a lot of looking there and don't look next to the window well. There's another story that I've heard that I was sharing yesterday that I've seen shared a number of times, but I think is great. \n\nYou got a drunk guy who's looking for his keys, and somebody notices he's looking for his keys under the streetlight. He's like, \"What are you doing?\" He's like, \"Well, I'm looking for my keys.\" And he's like, \"Oh, so you dropped them here?\" And he's like, \"No, I dropped them somewhere over there.\" \"Oh, why are you looking here?\" \"Well, the light's here. I can see here.\" [laughs] \n\nAnd it makes us laugh out loud when you think about somebody doing that. But we totally do that; we look where we can see or where we think the problem might be. And if we spend too much time looking where there's a lot of visibility rather than expanding the scope of what we're looking at, find some way to add visibility to other parts of our code, then we're likely to waste a lot of effort looking where there really isn't a problem. And instead, thinking, well, what can I do to look at the broader scope and eliminate where those problems are?\n\nZSOLT: I also have something to add to that. In the same vein, it's also important to not over-isolate because then you'll just end up confusing yourself even more. Because there have been several instances where I have cut out too much, and then I just didn't understand how I got from not working to not working in a different way. I'm like, this is giving me even more unintended results. What's happening, you know?\n\nMIKE: That's interesting. And how do you go about fixing that?\n\nZSOLT: So when I find that I've, I guess, you could say that I've overscoped the problem, then I will try to take a step back and then rethink my strategy for isolation of the problem. Because sometimes I'll be like, all right, so I have this set of functions that do these things, and then I'll take a look at one function that I think might be causing the issue. And then, if it's not that, I have to re-scope to another thing.\n\nMIKE: Okay, so you hyperfocus on the problem is here in this function, and you realize, wait, maybe it's not.\n\nZSOLT: Exactly, because you start seeing that, wait, this is actually what I expected, or something else is wrong, you know?\n\nMIKE: Yeah, absolutely. But you suggested something, and you said, but I think the problem is this function. A lot of times, if you're going through a series of functions, just something as simple as logging in each of those functions and to find out where the problem starts is really helpful. And you don't necessarily have to have it in all the places. You start by putting some sort of statement halfway through and figure out which side of that logging statement the problem happened on. You've cut down a lot of scope, that binary search. \n\nCutting the problem in half every time is just tremendously powerful, I think. It's not just powerful in debugging; it's how indexes work. And it's the reason you can search your database and get answers back quickly [laughs] instead of having to search every row. The internet wouldn't work without that kind of algorithm. \n\nSo I've asked Ramses and Zsolt specifically about some of their experience. Afton, I know that you were self-taught for a while as well. I'm curious what kind of lessons you learned while you were struggling through debugging alone during that time. I suspect you found some interesting lessons about how to track down tricky bugs.\n\nAFTON: I was building a new project, and most of my struggles were how do I implement a new thing? How do I address a new problem? So, learning to research and going and finding answers was a big thing that I spent a lot of time doing and getting better at. But my own codebase at the time wasn't; I don't know, I'm not sure that debugging...because isn't debugging kind of fundamentally existing stuff, existing code, the problems in it, right?\n\nMIKE: New code has problems, too. Just because it compiles doesn't mean it works.\n\nAFTON: [laughs] Yeah, I'm not thinking about my learning stage and any scenarios really about debugging. I will say I've been thinking about how I go about debugging now. I typically find an entry point where, okay, the bug is being identified as this kind of process issue, or it's this feature-related. So I find the entry point, find what UI kicks off what processes, and go start at the controller. \n\nAnd, I'll even, in my notes, outline as I'm going through the code; okay, the first entry point is here. This is what the code is doing, and either this can happen or this can happen. And what is the next step? And so I step through, you know, service objects and other methods and functions and just document this is what the code says it's doing. And I'll throw in my binding.pry at each new entry point to ensure that the data that I'm getting at that moment is what is expected. \n\nSo stop at each point, look at the data. Is this what the code is expecting? Okay, if so, great, move on to the next step. And work my way down to the point where, okay, it's expecting this value or this attribute and can find something that is inconsistent or unexpected or not present but should be. That's usually pretty effective for me, and creating an outline in my notes helps me gain this big-picture context, going from broader and narrowing as I go. So I think that's kind of a way of cutting in half, cutting in half. \n\nThis cutting in half thing I was trying to think, how do you do that? How do you start with a problem and cut it in half? How do you know you're cutting in the right place? How do you know what the boundaries are in order to cut it in half? [laughs] I mean, you have to see the borders of your zone in order to cut it in half. Those are kind of the questions that were running through my head, and I'm like, do I do something like that? And how do you know that you're doing that effectively?\n\nMIKE: And as you were talking, I was envisioning pipes again (Talking about pipes today.), and I thought about sewage lines. They have access points, right? Once every block or so. When something's blocked up, they can go into each of those access points and find and check which one was blocked. They can't necessarily check everywhere in between. But there are those boundaries that you're talking about where you can check if things flowed correctly in between. \n\nAFTON: Right. [chuckles]\n\nMIKE: And, if you have a wide area, we'll start by checking some points in the middle, and you might be nowhere near the right spot. But you at least know that things were flowing there. And then you go downstream and say, well is it flowing here? It's your idea of you got to drill down through all this area. Well, you got to start somewhere, and maybe you don't know it. And maybe you're going to start at the wrong place. \n\nThat's the beautiful thing about binary search, though, is you can start at the wrong place, and that's okay. [laughs] Is it right here? And if it is, well, then you know it's farther down the pipe. It's farther down the call chain. And if it's broken there, well, then it was farther up the call chain. That's the idea, is your idea of this call chain. Again, I'm visualizing it as pipes again, but it's just calls, right? You got calls from function to function to function. \n\nYou can figure out, you know, start somewhere and see if it's right there, if it's correct, you know, if everything is flowing properly at that point, and if it is, well, then the problem is probably downstream from there, farther down the call chain. And if it's incorrect, well, then it's farther up the call chain.\n\nAFTON: Right. Yeah, no, that makes sense. That's really good. Yeah, so I think that's essentially what I'm doing then.\n\nMIKE: Yeah. I think these metaphors...so I like to throw out a lot of them because they capture ideas, I think, better than talking about the actual thing often does. Because if you can visualize something, if you can easily grasp it, then you can relate it to the problem and better understand that problem. As humans, we talk in symbols all the time. Words themselves are symbols representing ideas. They have great utility that we don't have to hold up an apple to communicate about an apple. \n\nI can say the word apple, and that is a symbol that represents the idea of an apple, and communicate with you that way. It's not the thing itself but a token or a representation of that idea that allows us to talk in a more abstract way. Stories are a great way to abstract ideas to think about them in a higher level way than getting lost in the weeds as we sometimes do. \n\nI want to make another observation about debugging. How easy is it to debug code that is sprawling and complicated, methods hundreds of lines long or functions (I'm using those synonymously.) methods or functions hundreds of lines long with lots of branching logic? Thoughts?\n\nAFTON: That is very difficult [laughs] because there are so many things that can go wrong, and all in one place, supposedly returning one result is not easy. [laughs]\n\nMIKE: No. And you think, well, it's just code, right? It does the same thing. The broader structural organization shouldn't matter; I mean, it's still just code. I say that, but I know it's not true. The way we structure our code has a great deal of impact on debugging. And I found that sometimes for tricky problems, the best way to debug the problem is not to but rather to restructure the code, refactor that code. Sometimes it's remarkable how much difference that makes. \n\nTo share another story, my son was doing some Minecraft modding a number of years ago, and he came to me for some help. And he said, \"Yeah, my code is not working. Can you tell me why?\" And I looked at it. And it was this deeply nested function. I think it was nested like ten levels deep or more, and the code wasn't formatted cleanly at all. I mean, there were double curly braces, and the indentation was inconsistent from line to line. \n\nI looked at that, and I said, \"You know, I really want to help you, but I can't.\" If you can go and just clean up your syntax, get your curly braces aligned, and your code indented, that's all I ask.\" I said, \"Just get your indentation right and your braces in alignment so that I can see the structure of your code because right now, I can't. It's all over the place.\" He was young. He can be excused. [laughs] \"It's just not lined up. I can't see it. I can't understand what's going on here because it's not organized.\" \n\nAnd I didn't ask him to refactor the function. I didn't ask him to break it up into separate functions at all, just to order the code. He came back to me a couple of hours later, kind of with his tail between his legs, and said, \"Well, I did what you asked, and the code works now.\" \n\nAFTON: [laughs]\n\nMIKE: All he did was clean up the syntax. And somehow, he had gotten some braces misaligned so that there was an if block somewhere that shouldn't have been. And by cleaning that up, without even noticing that he had fixed it, he had fixed his problem. That moment has really stuck with me because I remember, oh, wow, all he did was clean up the syntax. I'm not saying that cleaning up your syntax is always going to solve your problems, but it says something. \n\nI mean, debugging is a human endeavor. It's something that we have to do to make better sense of the code. And things that we can do to better wrap our heads around what's going on are going to allow us to find the problem better. And that applies, first, not just to debugging but building the code; anything that we can do to easier think about the problem is going to be likely to help us move faster, not slower. \n\nIt's not working against you to organize your code well. It's actually helping you work faster and more easily. It may feel like it's a constraint that I can't just quickly get all the ideas out of my head. I understand that idea. But I would argue pretty strongly that organizing those ideas as you get them out, even though it's difficult, even though it's a constraint, even though it's hard to do that when you just want to get it out, is actually going to help you work faster. \n\nIt's similar to the idea of writing an outline of a paper before you just start banging away on the keyboard. Getting that organization in place is extremely helpful to being able to better express your ideas because it gives you kind of a map. It allows you to not have to worry about everything at once but to be able to understand what's going on elsewhere and then not think about it. It allows you to better wrap your head around the global context so that you can forget about it and focus on the local context. That's really powerful. It's a tool that allows you to use your brain.\n\nOne thing you said, Afton, I think goes along with that. I'm talking about taking notes and organizing an outline. Well, you said you do that when you're looking to solve a problem. You write things down, and you outline what the problem is so that you can see the overall scale of what's going on and then focus in on the parts that actually matter. \n\nAFTON: Yeah, that helps a lot. And what you've been saying goes right along with our team convention of creating single-purpose methods and single-purpose service objects in order to take complexity out of one class and divvy it up into small, understandable, manageable pieces. Because, like you were saying, if the piece is small and we can hold it all in our head at once, it's going to be a lot easier to debug, to understand, and to utilize. So yeah, our team works really hard to do that. And that does aid in easier debugging, single-purpose methods, and classes.\n\nMIKE: You've spent a lot of time working with a team that cares about those kinds of things. I've not always had that luxury. When you're working with sprawling code with a class that has thousands of lines, and hundreds of functions, and multiple different workflows that pass through the same class, they overlap each other. You're not sure which one is deprecated or how much they cross over or not. [laughs] Sometimes they touch each other, sometimes they don't. It is really hard to figure out what's going on. \n\nSometimes the best way to debug is to rebuild. I say rebuild; starting from scratch is often not tenable. Most of us who are in the industry are working on applications that are in production. And we can't just throw out this thing of value that we've built and start over. So, somehow, we need to improve it in place while being a running system. People talk about upgrading the airplane while it's flying; we've got to do that sort of thing. \n\nBut refactoring can be done. You can take something big and messy and replace it with something tidy in place, in particular, if you have written your code to be highly decoupled so that everything around it has a single entry point into that code and is able to, you know, just call that method. As long as it gets the same thing back, you can completely redo everything inside. \n\nNow, maybe your problem is that it's not decoupled, and you've got a couple of things that are closely coupled and entangled with each other. Well, then, your problem is to figure out where to divide those. That's a whole different discussion that we should probably have some time. But by getting those divided so that they are decoupled, and there's a clear boundary there, it's likely to help you to solve the problem because now you've isolated the two components, and you can fix the problem where it is rather than having to deal with its repercussions everywhere else. \n\nI'm just spending some time talking about this idea of debugging via refactoring. I think it's not something that we always talk about when we're talking about debugging, but I think it's a real thing. And sometimes, it's the most useful tool that we have. Finding problems in the code through isolating by using a binary search, following the call chain, cutting the problem in half every time is very useful. And it may even get you to the problem quite quickly and allow you to solve it there locally. \n\nBut if you're often having problems in the piece of code, that suggests a bigger problem than just a quick patch is going to fix. There can be larger structural problems that are leading to those bugs. I've seen this many times where there's code that's just problematic all the time, and it's generally because it's too complicated. And by complicated, I'm going to...let me define that. And it goes back to what you were saying, Afton. It's usually when things are doing more than one purpose, serving more than one purpose. \n\nSo if you've got a function that does multiple things or does something with a number of side effects, well, now you've got lots of things happening in one place, and you have to think about all of them going on at once, and that's hard to do. It's hard to make sure that all of the combinations are covered. One of the best ways to solve that is to disentangle the multiple things that are happening in that code into single-purpose components. Depending on the language you're in, there are different ways you could have those components, functions, classes, modules of some sort. The important part is that they have a single purpose. \n\nOnce you've done that, well, your code is still doing the same thing. So by some measures, the complexity is identical. But by disentangling the components, they both become more reusable. But they also become easier to comprehend and are less likely to have unexpected side effects when they interact with each other, unexpected interactions because they don't have any interactions other than through their public interfaces. And removing the opportunity for accidental interactions is what I mean by removing complexity. I think, oftentimes, we can do that. And that should be one of our primary focuses of refactoring. And that leads to code that is less likely to be buggy and may also be the most important thing we can do to debug problems. \n\nI'm thinking about a particular problem that a team worked on a year or two ago. There were two workflows. I'm not going to get into the details, but the overall workflow for one object and the overall workflow for a related thing. They were entangled with each other and presented as one overall workflow. The problem was having both of those together meant that there were a whole lot of intermediate states. You think of a state machine, and there are a whole lot of states you have to accommodate because it was the combinations you have to accommodate, all of the combinations of all of the states of those two different things. \n\nAnd by extracting one of the things out into its own thing and giving it its own workflow, we were able to dramatically simplify the number of states in each of the things because now we didn't have to account for the combinations. Each one just had to think about its own set of states. And there was a perennial series of bugs that was happening in one of these two things. And by just extracting them, the problem went away and hasn't been back since [laughs] because we disentangled them. The key to debugging wasn't just to fix that local problem, which would have patched that one little spot, but it would have left all the other problems of entangled state, and disentangling them was the real solution.\n\nAFTON: Yeah, I'm pretty sure I remember what you're referencing. And I just remember whenever someone had to go in and make changes in that code; it was like a nightmare of, oh, good luck in there, you know. [laughter] But then someone new had to go in and try to make sense of this complicated system, which was more likely to create more bugs because it was so complex and hard to change that it was going to likely produce more bugs when changes were made. So yeah, extracting those out made the scope of the one feature easier to understand and, therefore, easier to change, which helps mitigate the likeliness of bugs. [laughs]\n\nMIKE: Yeah, and I think the engineer when he was going in there, he was going in there specifically to solve a bug, and he said, \"You know what? I'm not going to be able to solve this bug because the concept is not well enough disentangled.\" There's this concept that wasn't a concrete object. And by having it fuzzily spread around within the other object, it didn't have its own representation.\n\nGoing back to this idea of abstracting ideas, by giving something its own representation, there's a place to put everything. I worked with a developer once who said, \"You know, you always need to create a new class, so you have a place to put stuff so that there's a place for everything.\" And I think that was really wise. By creating this new class, this new representation of the idea, there was a place to put the code that needed to be there. \n\nThe idea is you could give it its own database table easily, for example, and then have all of the attributes persisted cleanly and separately. And by being able to represent that idea separately, we're able to persist the state in a way that we couldn't previously because it was all entangled. And it was able to solve the problem because the idea could be represented. Before, there were key ideas that weren't even saved. They were just inferred, and sometimes the inferences couldn't be accurately made. Having that disentangled allowed us to see that, oh, wait, we need to be able to save this idea. And we couldn't see that before until it was disentangled.\n\nZSOLT: I do agree about the importance of making sure that you have discrete chunks of code, I guess you could say, to ensure that you don't have weird conflicts like that. Because I've had several scenarios like that in my personal experience where I had everything in a handful of functions, and that was not good. And then, I separated everything out, and things started working significantly better. And I'm like, oh, maybe that's smart. Maybe I should do that more often.\n\nMIKE: [laughs] It just sort of magically starts working better, right?\n\nZSOLT: Yeah. It's kind of weird when your code is written right that it works right. \n\n[laughter]\n\nMIKE: Yeah, there's an uncanny parallel between code organization and code working. Again, it's not what we always talk about when we're talking about debugging, but I think it's an important thing to recognize and think about.\n\nI think there's maybe one idea we've touched on but haven't dug into as much as we could, which is this idea of looking outside the local scope to see the context a bit more. There have been a number of times when I have been working on a problem, and I got some output. And I said, \"That's just not possible. I don't understand. It's impossible.\" And I've learned that as soon as I think that, I need to recognize, yep, that is impossible, which means I'm looking at the problem wrong. \n\nIf an impossible thing is happening, it means I'm looking too closely. And I need to step back and think about what context this code could be operating in that could make this impossible thing happen. It means that there is some input or some state that I was not accounting for that is causing the problem. I talked about the drain pipe that was flooding my window well. I wasn't accounting for that. I was assuming that all of the problems were just coming from water pouring off the wall into the window well. And it just seemed impossible that so much water could come up in there. \n\nWell, it was impossible, given the scope of where I was looking. And I needed to stop, take a step back, and think, where am I not looking? What am I not looking at? And that moment of pause where you stop and say, well, this doesn't seem possible; I need to take a step back and figure out what I'm not looking at, I think is one of the most valuable things that we can learn when we're debugging.\n\nZSOLT: The only way that you will have an impossible problem is if you're impossibly scoped because everything is either defined or undefined behavior. If you're getting something that doesn't match either of those, then your scope is wrong.\n\nMIKE: Well, that's interesting: if you're impossibly scoped. Yeah, I think that's a really interesting idea you're saying. When you see something impossible, it means that your scope is wrong. The behavior you're saying is defined within this scope is really not the key source of the problem. \n\nZSOLT: Right. \n\nMIKE: Interesting. Yeah, I think that's very well said. If you're seeing something that seems impossible, then it's almost certainly a scope problem. The problem is the scope, not the code necessarily you're looking at. \n\nZSOLT: Right. I deal with a lot of unmanaged code like C, and C++, and Assembly. And you get a lot of issues like that where if your scope is wrong, everything's just going to be really confusing.\n\nMIKE: Yeah, that's really interesting. It seems to dovetail really neatly with what I was saying. When you see those impossible problems, it's evidence that your scope is wrong. You're looking too closely. And you need to step back and look at the context, well, let me look a little bit bigger. What is the environment of this problem? And maybe the environment isn't what I thought it was.\n\nZSOLT: As they say, you're missing the forest for the trees. \n\nMIKE: Oh, that's great. Any other thoughts about this idea of scope or context of a problem and the impossible results, how to identify that moment to step back and look elsewhere?\n\nZSOLT: Sort of to touch back on what was previously discussed, a pretty solid way of making sure that you don't get into these impossible situations is to just make sure that you're writing your code in a cohesive way that doesn't cause these conflicts to happen in the first place. If you build a building out of garbage material, then that building is going to fall apart. \n\nBut if you build a building out of solid materials, it's much more likely to last longer. And the same thing can be applied to code. If you write code like crap, then it's not going to last very long because you're going to see that it's going to start falling apart at the seams. But if you write solid, well-documented code, then it's significantly easier to debug. It's significantly easier to maintain in the future.\n\nMIKE: Thank you. \n\nRAMSES: It's really interesting. I've been thinking about that a lot lately on how to reduce the number of bugs that are introduced by writing cleaner and more concise code. \n\nMIKE: Yeah, it's interesting that by making your code properly modular, large groups of bugs just never happen in the first place.\n\nZSOLT: Somebody once told me that the best way to debug your code is to ensure that bugs don't happen in the first place.\n\nMIKE: [laughs] I will say that in the real world, we don't always have the code we wish we had, [laughs] whether it be our own fault or that of others. But one of the things we've talked about of reducing the scope of the problem and then also looking back outward and seeing the problem in context, looking for what the true source of the problem is rather than getting too focused on right where we're at is likely to help you even when you're working with code that isn't ideal. \n\nAnd then, if it's persistently a problem, you can avoid those bugs by refactoring. That's just part of the work we do. We improve the code that we're working on and leave it better for that iteration but also for ourselves in the future. \n\nI think that ties up the discussion we've had nicely. We've talked about the various ways to address the problems by filtering away things that aren't relevant, by expanding our scope to find things that we hadn't looked for, and by improving the code so that the problems are easier to find. I think that's a great discussion on debugging. We'll leave it there. Thank you, everybody, for being here today. And we'll see you next time.","content_html":"Let's talk debugging skills! The conversation starts with some fun stories and experiences regarding debugging in general, and then panelists share thoughts about how to find bugs, lessons learned struggling through debugging, and how the way we structure code has a great deal of impact on debugging.
\n\nTranscript:
\n\nMIKE: Welcome to another episode of our Acima Development Podcast. We have, I think, an exciting discussion today. It's relevant to anybody doing development. We're going to be talking about debugging skills. Before going to that, let's go around and do some quick introductions. I'm Mike. I'll be hosting today. I've been a software developer for over 20 years, a Rubyist for most of that. Ramses, do want to introduce yourself?
\n\nRAMSES: Hey, everyone. I've been a familiar voice on this podcast for a while now. I've been a Rubyist developer for about a year and a half and a professional developer, I guess now, for about six months, and at Acima for almost four years now.
\n\nMIKE: Thank you. Afton.
\n\nAFTON: Hi, this is Afton again. I am also hitting my four-year mark this week here at Acima. And I've been in Ruby and Ruby on Rails my whole career.
\n\nMIKE: Thank you. Zsolt.
\n\nZSOLT: Hello. I'm Zsolt. I've been doing hobbyist development for a little over ten years. I have been a Rubyist for about three months of that so far, very wonderful thing.
\n\nMIKE: Great. I think that we've got a range of experience levels here, which will be really great for the discussion. I wanted to start the discussion with, let's say, a couple of stories. The first one is not my own. I had a friend who had a professor [laughs] who told me this story. This friend got the story from the professor. He had a professor who said...when he was teaching the class, he taught them the way you find the last blue wolf in Ireland.
\n\nAnd the way you find the last blue wolf in Ireland is that you build a wall across Ireland. And then you stand up on the wall at night, and you listen for which side of the wall the wolf howls on. And then when you figure out which side that is, you build a wall through the middle of that side of Ireland. And then you stand up on the wall at night, and you listen, and when you hear the wolf howl, you know it's on that side of the wall. And then you build the wall through that section and do the same thing. And after a few iterations of this, you've found your wolf because you've cut down the problem size by half every time. That's my first story.
\n\n[laughter]
\n\nThe second one is more of a personal one. I've got a window well that has regularly flooded for years, and it's just been a persistent problem. Luckily, the basement is unfinished or mostly unfinished, but it's a hassle. When it floods, we have to peel up the...we got some foam floor, and we peel it off the ground and have to mop up the floor and scoop up the water and put it in a bucket and dump it. It's a pain. [laughs] And I've had to do this often, particularly when the rain comes from that side of the house.
\n\nAnd I've tried all sorts of things to solve the problem. First thing I did was dug out some extra dirt in the window well. I thought, well, if I add some capacity to the window, well, the problem is that it's not big enough. Well, it didn't help. And I noticed that there's a drain pipe in there. It's a perforated pipe that goes down into the ground and connects to some others that go to a drain that comes into a sump with a sump pump. It drains the foundation, so we don't get flooding.
\n\nAnd the pipe, I thought, well, you know, this pipe is really long. It's hanging up at the top. Maybe some kids shoved some stuff in the end of it because it's just perforated. Maybe water can't get in the top. So I shortened the pipe, didn't help at all. [chuckles] We still got flooding. I used some caulk, and I sealed the edges of the window well. I thought, well, maybe water is pouring in from the side when it rains heavily from that side, and if I seal the joints, that will help. And the same problem still happened.
\n\nEarlier this year, I got a pipe auger or a pipe snake, like, long ones, so I could really run it down there, 50-foot long. And I attached a drill to the end, and I put it in there. And I thought, okay, there's probably some debris in there because it's just draining really slowly. So I ran in there, and I ran it in there, bzzzzzz, spun it around for a while. And I pulled out a little bit of mud and a little bit of grass, and not enough to matter.
\n\n[sighs] What is up with this? As I was standing there looking at the window well, kind of scratching my head, I noticed that there is a drain coming down from the roof into some drain pipe that ran out through under the lawn and drained over into a low spot that drains out to the road. And I noticed that where that drain pipe came out, the grass had grown over it, so it was plugged over. And I thought, oh, I should do something to fix that, you know, I bet the water is not able to get down there very well. I should have thought a little harder about this.
\n\nSo I went over and took a little shovel and cut out around the end so the water could drain out there. And I took a hose, and I thought, okay, I'm going to test this. And I took the hose over to the end of the drain pipe coming off the roof. And I noticed that where that drain pipe met the pipe that goes under the ground, they'd become dissociated. The ground drain pipe had loosened over time. It had been washed out a little behind and fallen off and slipped over to the side.
\n\nSo the drain pipe coming off the roof wasn't going into the drain from the ground at all, and if it had, it was plugged at the end. So any water that was coming down there, and it was about three feet away from the window well, would have immediately just started flooding the area next to the house, gone straight down to the window well, and poured inside.
\n\nAfter all these years of trying to figure out what was wrong with the window well, I realized the problem wasn't the window well at all. The water was coming off the roof and pouring straight into the window well. And there's no amount of drainage [laughs] that would have helped to solve that problem. The problem is it was just dumping water in every time it rained.
\n\nI took the pipe that went underneath, connected it to the drain pipe, stuck a couple of rocks under it, just some pebbles nearby, to brace it so that it was high enough. And presumably, the problem is solved with a couple of little pebbles. Had I looked around the window well ten years ago when this problem started happening, I would have saved myself a lot of trouble.
\n\nA couple of things I want to point out from this story, additional tools did not solve the problem. You know, I cut the pipe. I used the caulk to seal the joints, used the pipe auger, you know, I kept on escalating the tools I used to solve the problem. None of that solved it. What solved my problem was better observation of the situation and, in particular, of the context. Looking bigger than just at the window well and seeing the context that it was in allowed me to see that I was targeting the wrong problem. If I had looked a little bigger, I'd have seen what the underlying cause was for all the troubles I was having.
\n\nI thought through these stories ahead of time since we're talking about debugging because I think they'll really inform our discussion talking about software and how to find the problems that we have. With that, [laughs] any thoughts from the rest of you about...well, you can start with the stories or about debugging in general, your thoughts about how to find bugs given this discussion so far.
\n\nAFTON: That's such a good story. It brought a quote to mind from The Pragmatic Programmer I've been listening to. And I'm going to botch it. And I'm not even 100% sure it's related, but it's what came into my mind. [laughs] So it was saying that novices tend to try to fix problems by adding more correct code, or writing something to be more correct, or a new workable code. And experts go in and try to remove the problematic code. [laughs] So, I mean, first of all, you tried to add all these new solutions in, and then, in the end, you had something that was existing. You just had to refactor. I don't know how that works in -- [laughs]
\n\nMIKE: Oh yeah, refactor, exactly.
\n\nAFTON: Yeah. [laughs] That was a good quote.
\n\nMIKE: The direction I've thought about this is I see a lot of people lean hard into their debuggers. And debuggers can be a useful tool. So I want to be careful here. I don't want to suggest that you should never use a debugger. That being said, a debugger is a sophisticated, complicated tool. And if you've got a complicated, hard-to-think-about problem, then adding something complicated and hard to think about as part of your solution may be problematic.
\n\nAnd I have not, in my career, seen that debuggers have tended, you know, the fanciest of the debugger has not gone very far to helping people solve problems. For myself, I honestly don't use debuggers very often. I print out to the screen, and that's worked in every language I've ever worked in. It works in C; it works in Java; it works in Python; it works in JavaScript; it works in Ruby. If you print something out, and they've all got tools to do it, whether you're doing your console.log() or your puts, or your System.out.println(), if you can print something out to your screen while your program is running, you get that context.
\n\nAnd you can put it where you think the problem is. You can put it on one side of the problem, going back to that blue wolf in Ireland. You can put it on one side of the problem and the other side of the problem, and you can isolate it, split the problem in half, figure which side it's happening. And such a simple tool means you don't really have to think about it; instead, you're just trying to identify which side of the wall the problem is on, cutting out half the problem that way.
\n\nYou know, which side is it on? It gives you that visibility in a way that leaning really hard and trying to find all the things in one specific spot might not give you, you know, looking with a larger scope to cut the problem in half rather than getting hyperfocused on one spot.
\n\nI'm going to say debuggers could be a solution; you know, there are some pipes that need an auger to be cleaned out. [laughs] But, in general, it's the awareness that you need to be concerned about, and if you get that with the debugger, great. But, you know, if you can just print something out to your screen, that probably will work just about as well and maybe even better because you don't have to think about it as much.
\n\nZSOLT: Right. The interesting thing is that, for years, I've been told that print debugging is a terrible practice and you shouldn't do it. And I'm like, you know what? I'm going to respectfully disagree with that and do it anyway.
\n\nMIKE: [laughs]
\n\nZSOLT: Because it works very well for me. But I've also recently started using more actual debugging tools, and I do see where their uses stem from. But I do agree that you don't want to eat a bowl of cereal with an industrial food processor; I don't know.
\n\nMIKE: [laughs] You can use that to process the cereal and avoid the chewing, but it might not be fun.
\n\nZSOLT: Exactly.
\n\nMIKE: Really well said. I've seen developers who are really, really good, and they often have minimal tools. They know the tools they use really well. I'm not trying to suggest that we shouldn't use tools, but they use them judiciously. [laughs] They learn that the tools don't necessarily solve the problem. It's the problem-solving that solves the problem. Ramses, what's been your experience with debugging?
\n\nRAMSES: I'm pretty simple with debugging. I'll use a lot of print or put statements in combination with regular debuggers. If it's JavaScript, I'll just use a debugger. If it's Ruby, I'll use byebug or binding.pry, just so that I can do a quick analysis of whatever objects or logic I'm trying to investigate.
\n\nMIKE: Makes sense. I want to talk a little bit about the first story that I shared about finding the last blue wolf in Ireland. It's a silly story, and sometimes the best ones are like that because they stick. [laughs] They don't have to be very serious, but they stick in your head. If you can cut up the scope of a problem in half repeatedly, it gets much smaller very quickly. It ends up taking the time relative to the base two logarithm of the data you're looking at.
\n\nAnd the code that we look at is not generally tremendously big. And we might be working with millions of lines. Even if you have a million lines of code, you cut that in half once, and you're down to 500,000. That's a large size, but after you've gone through 20 iterations of cutting it in half, you've gotten to a pretty small problem set. It really doesn't take very long to cut things down when you cut them in half every time.
\n\nBut I think a lot of times we neglect that idea when we're looking for problems. We think, well, I know where the problem is, so I'm going to look really, really close there and do a lot of looking there and don't look next to the window well. There's another story that I've heard that I was sharing yesterday that I've seen shared a number of times, but I think is great.
\n\nYou got a drunk guy who's looking for his keys, and somebody notices he's looking for his keys under the streetlight. He's like, "What are you doing?" He's like, "Well, I'm looking for my keys." And he's like, "Oh, so you dropped them here?" And he's like, "No, I dropped them somewhere over there." "Oh, why are you looking here?" "Well, the light's here. I can see here." [laughs]
\n\nAnd it makes us laugh out loud when you think about somebody doing that. But we totally do that; we look where we can see or where we think the problem might be. And if we spend too much time looking where there's a lot of visibility rather than expanding the scope of what we're looking at, find some way to add visibility to other parts of our code, then we're likely to waste a lot of effort looking where there really isn't a problem. And instead, thinking, well, what can I do to look at the broader scope and eliminate where those problems are?
\n\nZSOLT: I also have something to add to that. In the same vein, it's also important to not over-isolate because then you'll just end up confusing yourself even more. Because there have been several instances where I have cut out too much, and then I just didn't understand how I got from not working to not working in a different way. I'm like, this is giving me even more unintended results. What's happening, you know?
\n\nMIKE: That's interesting. And how do you go about fixing that?
\n\nZSOLT: So when I find that I've, I guess, you could say that I've overscoped the problem, then I will try to take a step back and then rethink my strategy for isolation of the problem. Because sometimes I'll be like, all right, so I have this set of functions that do these things, and then I'll take a look at one function that I think might be causing the issue. And then, if it's not that, I have to re-scope to another thing.
\n\nMIKE: Okay, so you hyperfocus on the problem is here in this function, and you realize, wait, maybe it's not.
\n\nZSOLT: Exactly, because you start seeing that, wait, this is actually what I expected, or something else is wrong, you know?
\n\nMIKE: Yeah, absolutely. But you suggested something, and you said, but I think the problem is this function. A lot of times, if you're going through a series of functions, just something as simple as logging in each of those functions and to find out where the problem starts is really helpful. And you don't necessarily have to have it in all the places. You start by putting some sort of statement halfway through and figure out which side of that logging statement the problem happened on. You've cut down a lot of scope, that binary search.
\n\nCutting the problem in half every time is just tremendously powerful, I think. It's not just powerful in debugging; it's how indexes work. And it's the reason you can search your database and get answers back quickly [laughs] instead of having to search every row. The internet wouldn't work without that kind of algorithm.
\n\nSo I've asked Ramses and Zsolt specifically about some of their experience. Afton, I know that you were self-taught for a while as well. I'm curious what kind of lessons you learned while you were struggling through debugging alone during that time. I suspect you found some interesting lessons about how to track down tricky bugs.
\n\nAFTON: I was building a new project, and most of my struggles were how do I implement a new thing? How do I address a new problem? So, learning to research and going and finding answers was a big thing that I spent a lot of time doing and getting better at. But my own codebase at the time wasn't; I don't know, I'm not sure that debugging...because isn't debugging kind of fundamentally existing stuff, existing code, the problems in it, right?
\n\nMIKE: New code has problems, too. Just because it compiles doesn't mean it works.
\n\nAFTON: [laughs] Yeah, I'm not thinking about my learning stage and any scenarios really about debugging. I will say I've been thinking about how I go about debugging now. I typically find an entry point where, okay, the bug is being identified as this kind of process issue, or it's this feature-related. So I find the entry point, find what UI kicks off what processes, and go start at the controller.
\n\nAnd, I'll even, in my notes, outline as I'm going through the code; okay, the first entry point is here. This is what the code is doing, and either this can happen or this can happen. And what is the next step? And so I step through, you know, service objects and other methods and functions and just document this is what the code says it's doing. And I'll throw in my binding.pry at each new entry point to ensure that the data that I'm getting at that moment is what is expected.
\n\nSo stop at each point, look at the data. Is this what the code is expecting? Okay, if so, great, move on to the next step. And work my way down to the point where, okay, it's expecting this value or this attribute and can find something that is inconsistent or unexpected or not present but should be. That's usually pretty effective for me, and creating an outline in my notes helps me gain this big-picture context, going from broader and narrowing as I go. So I think that's kind of a way of cutting in half, cutting in half.
\n\nThis cutting in half thing I was trying to think, how do you do that? How do you start with a problem and cut it in half? How do you know you're cutting in the right place? How do you know what the boundaries are in order to cut it in half? [laughs] I mean, you have to see the borders of your zone in order to cut it in half. Those are kind of the questions that were running through my head, and I'm like, do I do something like that? And how do you know that you're doing that effectively?
\n\nMIKE: And as you were talking, I was envisioning pipes again (Talking about pipes today.), and I thought about sewage lines. They have access points, right? Once every block or so. When something's blocked up, they can go into each of those access points and find and check which one was blocked. They can't necessarily check everywhere in between. But there are those boundaries that you're talking about where you can check if things flowed correctly in between.
\n\nAFTON: Right. [chuckles]
\n\nMIKE: And, if you have a wide area, we'll start by checking some points in the middle, and you might be nowhere near the right spot. But you at least know that things were flowing there. And then you go downstream and say, well is it flowing here? It's your idea of you got to drill down through all this area. Well, you got to start somewhere, and maybe you don't know it. And maybe you're going to start at the wrong place.
\n\nThat's the beautiful thing about binary search, though, is you can start at the wrong place, and that's okay. [laughs] Is it right here? And if it is, well, then you know it's farther down the pipe. It's farther down the call chain. And if it's broken there, well, then it was farther up the call chain. That's the idea, is your idea of this call chain. Again, I'm visualizing it as pipes again, but it's just calls, right? You got calls from function to function to function.
\n\nYou can figure out, you know, start somewhere and see if it's right there, if it's correct, you know, if everything is flowing properly at that point, and if it is, well, then the problem is probably downstream from there, farther down the call chain. And if it's incorrect, well, then it's farther up the call chain.
\n\nAFTON: Right. Yeah, no, that makes sense. That's really good. Yeah, so I think that's essentially what I'm doing then.
\n\nMIKE: Yeah. I think these metaphors...so I like to throw out a lot of them because they capture ideas, I think, better than talking about the actual thing often does. Because if you can visualize something, if you can easily grasp it, then you can relate it to the problem and better understand that problem. As humans, we talk in symbols all the time. Words themselves are symbols representing ideas. They have great utility that we don't have to hold up an apple to communicate about an apple.
\n\nI can say the word apple, and that is a symbol that represents the idea of an apple, and communicate with you that way. It's not the thing itself but a token or a representation of that idea that allows us to talk in a more abstract way. Stories are a great way to abstract ideas to think about them in a higher level way than getting lost in the weeds as we sometimes do.
\n\nI want to make another observation about debugging. How easy is it to debug code that is sprawling and complicated, methods hundreds of lines long or functions (I'm using those synonymously.) methods or functions hundreds of lines long with lots of branching logic? Thoughts?
\n\nAFTON: That is very difficult [laughs] because there are so many things that can go wrong, and all in one place, supposedly returning one result is not easy. [laughs]
\n\nMIKE: No. And you think, well, it's just code, right? It does the same thing. The broader structural organization shouldn't matter; I mean, it's still just code. I say that, but I know it's not true. The way we structure our code has a great deal of impact on debugging. And I found that sometimes for tricky problems, the best way to debug the problem is not to but rather to restructure the code, refactor that code. Sometimes it's remarkable how much difference that makes.
\n\nTo share another story, my son was doing some Minecraft modding a number of years ago, and he came to me for some help. And he said, "Yeah, my code is not working. Can you tell me why?" And I looked at it. And it was this deeply nested function. I think it was nested like ten levels deep or more, and the code wasn't formatted cleanly at all. I mean, there were double curly braces, and the indentation was inconsistent from line to line.
\n\nI looked at that, and I said, "You know, I really want to help you, but I can't." If you can go and just clean up your syntax, get your curly braces aligned, and your code indented, that's all I ask." I said, "Just get your indentation right and your braces in alignment so that I can see the structure of your code because right now, I can't. It's all over the place." He was young. He can be excused. [laughs] "It's just not lined up. I can't see it. I can't understand what's going on here because it's not organized."
\n\nAnd I didn't ask him to refactor the function. I didn't ask him to break it up into separate functions at all, just to order the code. He came back to me a couple of hours later, kind of with his tail between his legs, and said, "Well, I did what you asked, and the code works now."
\n\nAFTON: [laughs]
\n\nMIKE: All he did was clean up the syntax. And somehow, he had gotten some braces misaligned so that there was an if block somewhere that shouldn't have been. And by cleaning that up, without even noticing that he had fixed it, he had fixed his problem. That moment has really stuck with me because I remember, oh, wow, all he did was clean up the syntax. I'm not saying that cleaning up your syntax is always going to solve your problems, but it says something.
\n\nI mean, debugging is a human endeavor. It's something that we have to do to make better sense of the code. And things that we can do to better wrap our heads around what's going on are going to allow us to find the problem better. And that applies, first, not just to debugging but building the code; anything that we can do to easier think about the problem is going to be likely to help us move faster, not slower.
\n\nIt's not working against you to organize your code well. It's actually helping you work faster and more easily. It may feel like it's a constraint that I can't just quickly get all the ideas out of my head. I understand that idea. But I would argue pretty strongly that organizing those ideas as you get them out, even though it's difficult, even though it's a constraint, even though it's hard to do that when you just want to get it out, is actually going to help you work faster.
\n\nIt's similar to the idea of writing an outline of a paper before you just start banging away on the keyboard. Getting that organization in place is extremely helpful to being able to better express your ideas because it gives you kind of a map. It allows you to not have to worry about everything at once but to be able to understand what's going on elsewhere and then not think about it. It allows you to better wrap your head around the global context so that you can forget about it and focus on the local context. That's really powerful. It's a tool that allows you to use your brain.
\n\nOne thing you said, Afton, I think goes along with that. I'm talking about taking notes and organizing an outline. Well, you said you do that when you're looking to solve a problem. You write things down, and you outline what the problem is so that you can see the overall scale of what's going on and then focus in on the parts that actually matter.
\n\nAFTON: Yeah, that helps a lot. And what you've been saying goes right along with our team convention of creating single-purpose methods and single-purpose service objects in order to take complexity out of one class and divvy it up into small, understandable, manageable pieces. Because, like you were saying, if the piece is small and we can hold it all in our head at once, it's going to be a lot easier to debug, to understand, and to utilize. So yeah, our team works really hard to do that. And that does aid in easier debugging, single-purpose methods, and classes.
\n\nMIKE: You've spent a lot of time working with a team that cares about those kinds of things. I've not always had that luxury. When you're working with sprawling code with a class that has thousands of lines, and hundreds of functions, and multiple different workflows that pass through the same class, they overlap each other. You're not sure which one is deprecated or how much they cross over or not. [laughs] Sometimes they touch each other, sometimes they don't. It is really hard to figure out what's going on.
\n\nSometimes the best way to debug is to rebuild. I say rebuild; starting from scratch is often not tenable. Most of us who are in the industry are working on applications that are in production. And we can't just throw out this thing of value that we've built and start over. So, somehow, we need to improve it in place while being a running system. People talk about upgrading the airplane while it's flying; we've got to do that sort of thing.
\n\nBut refactoring can be done. You can take something big and messy and replace it with something tidy in place, in particular, if you have written your code to be highly decoupled so that everything around it has a single entry point into that code and is able to, you know, just call that method. As long as it gets the same thing back, you can completely redo everything inside.
\n\nNow, maybe your problem is that it's not decoupled, and you've got a couple of things that are closely coupled and entangled with each other. Well, then, your problem is to figure out where to divide those. That's a whole different discussion that we should probably have some time. But by getting those divided so that they are decoupled, and there's a clear boundary there, it's likely to help you to solve the problem because now you've isolated the two components, and you can fix the problem where it is rather than having to deal with its repercussions everywhere else.
\n\nI'm just spending some time talking about this idea of debugging via refactoring. I think it's not something that we always talk about when we're talking about debugging, but I think it's a real thing. And sometimes, it's the most useful tool that we have. Finding problems in the code through isolating by using a binary search, following the call chain, cutting the problem in half every time is very useful. And it may even get you to the problem quite quickly and allow you to solve it there locally.
\n\nBut if you're often having problems in the piece of code, that suggests a bigger problem than just a quick patch is going to fix. There can be larger structural problems that are leading to those bugs. I've seen this many times where there's code that's just problematic all the time, and it's generally because it's too complicated. And by complicated, I'm going to...let me define that. And it goes back to what you were saying, Afton. It's usually when things are doing more than one purpose, serving more than one purpose.
\n\nSo if you've got a function that does multiple things or does something with a number of side effects, well, now you've got lots of things happening in one place, and you have to think about all of them going on at once, and that's hard to do. It's hard to make sure that all of the combinations are covered. One of the best ways to solve that is to disentangle the multiple things that are happening in that code into single-purpose components. Depending on the language you're in, there are different ways you could have those components, functions, classes, modules of some sort. The important part is that they have a single purpose.
\n\nOnce you've done that, well, your code is still doing the same thing. So by some measures, the complexity is identical. But by disentangling the components, they both become more reusable. But they also become easier to comprehend and are less likely to have unexpected side effects when they interact with each other, unexpected interactions because they don't have any interactions other than through their public interfaces. And removing the opportunity for accidental interactions is what I mean by removing complexity. I think, oftentimes, we can do that. And that should be one of our primary focuses of refactoring. And that leads to code that is less likely to be buggy and may also be the most important thing we can do to debug problems.
\n\nI'm thinking about a particular problem that a team worked on a year or two ago. There were two workflows. I'm not going to get into the details, but the overall workflow for one object and the overall workflow for a related thing. They were entangled with each other and presented as one overall workflow. The problem was having both of those together meant that there were a whole lot of intermediate states. You think of a state machine, and there are a whole lot of states you have to accommodate because it was the combinations you have to accommodate, all of the combinations of all of the states of those two different things.
\n\nAnd by extracting one of the things out into its own thing and giving it its own workflow, we were able to dramatically simplify the number of states in each of the things because now we didn't have to account for the combinations. Each one just had to think about its own set of states. And there was a perennial series of bugs that was happening in one of these two things. And by just extracting them, the problem went away and hasn't been back since [laughs] because we disentangled them. The key to debugging wasn't just to fix that local problem, which would have patched that one little spot, but it would have left all the other problems of entangled state, and disentangling them was the real solution.
\n\nAFTON: Yeah, I'm pretty sure I remember what you're referencing. And I just remember whenever someone had to go in and make changes in that code; it was like a nightmare of, oh, good luck in there, you know. [laughter] But then someone new had to go in and try to make sense of this complicated system, which was more likely to create more bugs because it was so complex and hard to change that it was going to likely produce more bugs when changes were made. So yeah, extracting those out made the scope of the one feature easier to understand and, therefore, easier to change, which helps mitigate the likeliness of bugs. [laughs]
\n\nMIKE: Yeah, and I think the engineer when he was going in there, he was going in there specifically to solve a bug, and he said, "You know what? I'm not going to be able to solve this bug because the concept is not well enough disentangled." There's this concept that wasn't a concrete object. And by having it fuzzily spread around within the other object, it didn't have its own representation.
\n\nGoing back to this idea of abstracting ideas, by giving something its own representation, there's a place to put everything. I worked with a developer once who said, "You know, you always need to create a new class, so you have a place to put stuff so that there's a place for everything." And I think that was really wise. By creating this new class, this new representation of the idea, there was a place to put the code that needed to be there.
\n\nThe idea is you could give it its own database table easily, for example, and then have all of the attributes persisted cleanly and separately. And by being able to represent that idea separately, we're able to persist the state in a way that we couldn't previously because it was all entangled. And it was able to solve the problem because the idea could be represented. Before, there were key ideas that weren't even saved. They were just inferred, and sometimes the inferences couldn't be accurately made. Having that disentangled allowed us to see that, oh, wait, we need to be able to save this idea. And we couldn't see that before until it was disentangled.
\n\nZSOLT: I do agree about the importance of making sure that you have discrete chunks of code, I guess you could say, to ensure that you don't have weird conflicts like that. Because I've had several scenarios like that in my personal experience where I had everything in a handful of functions, and that was not good. And then, I separated everything out, and things started working significantly better. And I'm like, oh, maybe that's smart. Maybe I should do that more often.
\n\nMIKE: [laughs] It just sort of magically starts working better, right?
\n\nZSOLT: Yeah. It's kind of weird when your code is written right that it works right.
\n\n[laughter]
\n\nMIKE: Yeah, there's an uncanny parallel between code organization and code working. Again, it's not what we always talk about when we're talking about debugging, but I think it's an important thing to recognize and think about.
\n\nI think there's maybe one idea we've touched on but haven't dug into as much as we could, which is this idea of looking outside the local scope to see the context a bit more. There have been a number of times when I have been working on a problem, and I got some output. And I said, "That's just not possible. I don't understand. It's impossible." And I've learned that as soon as I think that, I need to recognize, yep, that is impossible, which means I'm looking at the problem wrong.
\n\nIf an impossible thing is happening, it means I'm looking too closely. And I need to step back and think about what context this code could be operating in that could make this impossible thing happen. It means that there is some input or some state that I was not accounting for that is causing the problem. I talked about the drain pipe that was flooding my window well. I wasn't accounting for that. I was assuming that all of the problems were just coming from water pouring off the wall into the window well. And it just seemed impossible that so much water could come up in there.
\n\nWell, it was impossible, given the scope of where I was looking. And I needed to stop, take a step back, and think, where am I not looking? What am I not looking at? And that moment of pause where you stop and say, well, this doesn't seem possible; I need to take a step back and figure out what I'm not looking at, I think is one of the most valuable things that we can learn when we're debugging.
\n\nZSOLT: The only way that you will have an impossible problem is if you're impossibly scoped because everything is either defined or undefined behavior. If you're getting something that doesn't match either of those, then your scope is wrong.
\n\nMIKE: Well, that's interesting: if you're impossibly scoped. Yeah, I think that's a really interesting idea you're saying. When you see something impossible, it means that your scope is wrong. The behavior you're saying is defined within this scope is really not the key source of the problem.
\n\nZSOLT: Right.
\n\nMIKE: Interesting. Yeah, I think that's very well said. If you're seeing something that seems impossible, then it's almost certainly a scope problem. The problem is the scope, not the code necessarily you're looking at.
\n\nZSOLT: Right. I deal with a lot of unmanaged code like C, and C++, and Assembly. And you get a lot of issues like that where if your scope is wrong, everything's just going to be really confusing.
\n\nMIKE: Yeah, that's really interesting. It seems to dovetail really neatly with what I was saying. When you see those impossible problems, it's evidence that your scope is wrong. You're looking too closely. And you need to step back and look at the context, well, let me look a little bit bigger. What is the environment of this problem? And maybe the environment isn't what I thought it was.
\n\nZSOLT: As they say, you're missing the forest for the trees.
\n\nMIKE: Oh, that's great. Any other thoughts about this idea of scope or context of a problem and the impossible results, how to identify that moment to step back and look elsewhere?
\n\nZSOLT: Sort of to touch back on what was previously discussed, a pretty solid way of making sure that you don't get into these impossible situations is to just make sure that you're writing your code in a cohesive way that doesn't cause these conflicts to happen in the first place. If you build a building out of garbage material, then that building is going to fall apart.
\n\nBut if you build a building out of solid materials, it's much more likely to last longer. And the same thing can be applied to code. If you write code like crap, then it's not going to last very long because you're going to see that it's going to start falling apart at the seams. But if you write solid, well-documented code, then it's significantly easier to debug. It's significantly easier to maintain in the future.
\n\nMIKE: Thank you.
\n\nRAMSES: It's really interesting. I've been thinking about that a lot lately on how to reduce the number of bugs that are introduced by writing cleaner and more concise code.
\n\nMIKE: Yeah, it's interesting that by making your code properly modular, large groups of bugs just never happen in the first place.
\n\nZSOLT: Somebody once told me that the best way to debug your code is to ensure that bugs don't happen in the first place.
\n\nMIKE: [laughs] I will say that in the real world, we don't always have the code we wish we had, [laughs] whether it be our own fault or that of others. But one of the things we've talked about of reducing the scope of the problem and then also looking back outward and seeing the problem in context, looking for what the true source of the problem is rather than getting too focused on right where we're at is likely to help you even when you're working with code that isn't ideal.
\n\nAnd then, if it's persistently a problem, you can avoid those bugs by refactoring. That's just part of the work we do. We improve the code that we're working on and leave it better for that iteration but also for ourselves in the future.
\n\nI think that ties up the discussion we've had nicely. We've talked about the various ways to address the problems by filtering away things that aren't relevant, by expanding our scope to find things that we hadn't looked for, and by improving the code so that the problems are easier to find. I think that's a great discussion on debugging. We'll leave it there. Thank you, everybody, for being here today. And we'll see you next time.
","summary":"Let's talk debugging skills! The conversation starts with some fun stories and experiences regarding debugging in general, and then panelists share thoughts about how to find bugs, lessons learned struggling through debugging, and how the way we structure code has a great deal of impact on debugging.","date_published":"2022-12-21T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/5e1f62fb-43ec-4c9f-bea0-c7e8b48c3ff9.mp3","mime_type":"audio/mpeg","size_in_bytes":41395859,"duration_in_seconds":2403}]},{"id":"d8d5df6e-e0b4-4ae7-9d7e-7fb65455a914","title":"Episode 6: Overcoming Imposter Syndrome Part II","url":"https://acima-development.fireside.fm/6","content_text":"Impostor Syndrome is definitely a topic that deserves more than one discussion. It's easy to be at a desk and feel like you're not sure; do I belong here? People around me seem to know what they're doing, do I? The answer to both is Yes. We return for Part 2. \n\nICYMI: Here's Overcoming Impostor Syndrom Part I!\n\nTranscript:\n\nMIKE: Welcome to another episode of our Acima Development Podcast. We've got what I think is a good one today. So I think it's something that we struggle with as developers. I think most, if not all of us, hit this occasionally, at least. And we've got a perfect group today to talk about this subject because we've got a wide range of experience. \n\nThe topic we're going to be addressing today is impostor syndrome. Before we dive into that, let's go ahead and introduce ourselves. I'm Mike. I'm going to be hosting today. Well, let's go around. Eddy, do you want to introduce yourself?\n\nEDDY: My name is Eddy from the QA team. Happy to be here. Thanks for having me, as always.\n\nMIKE: Great. Damon.\n\nDAMON: My name is Damon, and I am on the application support team.\n\nMIKE: Thank you. And Ramses. \n\nRAMSES: Hey, everyone. I'm Ramses. I'm on the Atlas development team. Excited to be here. \n\nMIKE: Thank you. And I'm currently Director of Engineering here at Acima. So we've got a range of experiences, of backgrounds which I think is perfect. We've got somebody who's been doing software development for decades, somebody who's officially on the team who has only been doing it for a short time, somebody from support, and somebody from QA, both of which hope to get into development. It gives us a chance to talk about the different perspectives that we might have on a career in software and how that feels from those different positions. And there are similarities and differences, but I think you'll find that there are more similarities than differences. \n\nLet me give a little introduction of this idea of imposter syndrome. It doesn't just apply to software; I think it applies in a number of fields but particularly in software where our job is to solve problems. There's no handbook, and there's no clear set of guidelines that this is exactly what you do. Instead, you're sitting in front of a computer with a problem to solve and sort of go ahead, solve it, and that's it. \n\nAnd you certainly have peers who can help you. But it's easy to be sitting there in that desk and feel like I'm not sure; do I belong here? People around me seem to know what they're doing, do I? [laughs] I have a hard time imagining that there's anybody who doesn't feel that way sometimes. To talk a little bit about my background, I've been, as I mentioned, doing this for over 20 years. I started my full-time software career right after the dot-com bust. \n\nA lot of those big dot-com companies from the late '90s went belly up in the early 2000s. And the industry was flooded with developers, skilled developers who had just been let go from their jobs. And there was a glut of people to do work, and the jobs hadn't quite caught up yet. And it was very challenging to find work. I eventually found full-time work. My recollection is I was making less at the time than I had been doing working construction previously. [laughs] \n\nAnd I went and got a degree for this. It was certainly easy to feel like I didn't belong and I had made some wrong choices along the way. That led to some interesting developments. I was working for a startup that went really big and then crashed spectacularly. They actually let go of all the software development team but one, and then he quit. They ended up hiring me back on. So I went from being just a junior developer to running all the software for the company within just a few years. And I wasn't perfect yet, and there was a lot of pressure. \n\nI learned a lot during that time, trying to run things on my own. I also made some mistakes and had that, you know, I'm swimming in the deep end now. There's nobody here to help me experience lots of mixed feelings. Do I belong here? Do I not belong here? I had some respect in that I was doing the job, but then I wasn't doing it perfectly. And I had all those questions. \n\nI later moved to another company where I had a somewhat similar experience. We grew tremendously and then slowly tapered off. That company finally shut down operations back in January. And I ended up there at the department for a while and asking myself, am I doing okay? Am I not doing okay? And after a while, after that, I went to contract work. \n\nAcross all of this time, I had experiences that taught me a lot and had positions where they seemed to show some respect. But all along, all along my entire career, I've wondered, am I really doing okay here? Do I really belong? And now I'm here at Acima. I recently got my title to Director of Engineering, and it sounds kind of respectable. [laughs] But just like everybody else, I'm figuring it out. I can't claim to know everything. There's a lot that I don't know. And I'm always trying to learn just by reading and paying attention to my peers, trying to figure out how to do this the best way. \n\nI've learned to recognize that I'm never going to know everything. It's a fast-moving field with so much to learn that I couldn't possibly know. And doing well in this industry is not about knowing everything but about having that humility, recognizing you don't and being willing to ask, and further, just trying to solve problems. \n\nAnd with that, I'd like to, you know, I wanted to give an intro there. Now I'm going to be quiet for a while. And I'm interested in the thoughts of the others here on the call to share what their experience has been and how they perceive things given that background, this idea of imposter syndrome.\n\nDAMON: Maybe you can add to what you were saying. You mentioned you were in the field for over 20 years. How did you warm up to the idea of imposter syndrome, and how did you get over it?\n\nMIKE: That's a good question. I don't think I heard the term until much after my career had started. I don't think it's gone into widespread use; I could be wrong; one of those things that I might just not have heard about. But I don't think it's been in widespread use until the last few years. So I think there might be a few answers to that. First of all, when I heard the term, I thought, oh yes, that's what it is. \n\nAnd I've noticed that as I've mentored a lot of people...and that's something I'll point out that has helped a lot. As I've mentored a lot of people, I've noticed that most developers I've worked with tend to feel that way. They'll express something along the lines of, you know, how am I doing? Do I really belong here? I feel maybe out of place, not because the people around them aren't supportive, but, wow, I'm around a lot of smart, capable people; am I really that? And the answer universally has always been yes. Yes, you are that. \n\nAnd we have differences in experience. It's not that everybody has exactly the same skill level and exactly the same background. But everyone that I've worked with has had something to contribute. Perhaps the biggest differentiator I've seen as I've done a lot of mentoring between people who are really successful and people who aren't is that the really successful people are deeply curious. \n\nThey don't see asking questions as a sign of weakness but the natural consequence of their insatiable curiosity. [chuckles] They just want to figure things out. And because of that, they're willing to be vulnerable enough to ask, whether it's to ask their peers, ask mentors, ask Google, ask whatever it is they need to ask to figure problems out and experiment and try. None of us are going to quite know the answers. If we all knew the answers, then we could automate this job, and we'd all be out of work. We don't know the answers as the people who are asking the questions who have been very successful. \n\nSo to answer your question, how did I see this and get over it? A lot of it has come from not just my own experience but watching everybody else that I've worked with. I've seen so many people become successful. I've mentored a number of people who have gone on to be quite successful in their careers. And they were a diverse group of people, and they've come from different backgrounds. The number of people coming from customer support or similar roles to that, you know, who felt like, wow, I'm going into development; do I really belong here? They went on to become extremely successful. \n\nAnd seeing that progress of these capable people who maybe doubted themselves at first but allowed that curiosity to blossom allowed that curiosity to lead them to ask those questions and solve the problems. If I'm curious, if I'm solving problems, if I'm helping people out around me, well, I'm adding value. And it doesn't matter if I'm exactly like everybody else around me; I'm helping.\n\nDAMON: I find that kind of interesting because I came from a different background. So I never did customer service or anything like that. I was in the military for a few years. And I had a position where it was, hey; we're going to give you this piece of equipment. You need to figure out how it works. If it breaks, you need to figure out how to fix it. \n\nAnd asking questions wasn't encouraged. It was almost frowned upon. It was like, oh, you can't figure it out? Okay, we'll find somebody who can. And when I came to this role sitting side by side with super smart people like Ramses or learning from somebody else, it was like, am I supposed to be here? Is it okay to ask these questions? I think breaking that habit for me is very challenging. [laughs]\n\nMIKE: That's interesting. Well, I've got a couple of things to say to that. I've seen research that suggests that people who come from the military are more likely to be successful in this field. I don't know all the reasons, and I don't know that researchers know all the reasons. [laughs] But something about that background, maybe about the requirement to be a problem solver, tends to be very helpful. \n\nThe other thing I would point out, though, is what you said, is that idea of it being frowned on that I shouldn't ask questions; you experienced it there. But I think most of us experienced that somewhere. People who've gone to school, well, if you're asking the person next to you for help on your assignment, well, that might be cheating. And we get ingrained in us this idea that you shouldn't ask for help; doing that is doing it wrong. \n\nBut in the industry here, the opposite is true that if you're doing it yourself, you're doing it wrong. And let me explain that a little bit. It's not that we can't go off and solve a problem largely independently. But almost none of us are going to write in machine code. We don't write zeros and ones; we're writing computer languages, which were written by somebody else. And most of what we do is use libraries that were written by somebody else or maintain libraries that are written by a community. \n\nAnd we're just working at the very top of this pyramid that stands on the work of so many women and men who've gone before us. This idea that we would be working alone is, I think, really misguided that we're all deeply dependent on those we're working with now and those who've gone before who've laid the foundation for us. \n\nThere are many different sources that will tell us, \"You shouldn't be asking. You need to be figuring this out on your own.\" I think most people have to overcome that notion from a variety of backgrounds. Well, you got it in your previous career; many of us get it from our previous careers, or from school, or just from our upbringing. And it may not be universal, but it's quite common.\n\nDAMON: Yeah, I think that makes sense for sure. Yeah, like you were saying, just being in this field now and asking so many questions, there are so many people that want to help you. There are so many people that are like, \"If you have a question, ask.\" And you kind of think like, oh, that's just something people say. People are just like, you know, \"If you have a question, ask.\" But if you really ask, they're like, \"Okay, hold on, let me pair with you and break it down exactly how it's supposed to be.\" And you learn so much from that. And that has been super helpful, for sure.\n\nMIKE: I'll ask a follow-up question. Have you had people say things to you like, \"I love pairing?\"\n\nDAMON: Oh yeah, especially like Melissa, Afton. They're always down to pair and like, \"Well, let me show you exactly how to do it,\" you know, it's great. They actually love just teaching.\n\nMIKE: And that love is genuine. It's not, “I'm going to put down this because I'm sympathetic.” They genuinely love it. And I think that those of you listening can probably find a mentor like that because there's a lot of joy in mentoring. It's very enjoyable to go and watch those lights turn on in somebody's eyes and see them get it. It's a wonderful experience, and it's probably my favorite part of the job. \n\nIt's not something that I feel like I'm being burdened to do, but it's something that I feel like I get to do. Like, oh, wow, I can get out of a long meeting and instead go and help somebody find something cool. It's not something you should be shy to do. And if you're not finding mentors that are willing to do that, then maybe you need to look a little farther afield because they're out there. I found that there are many people who want to share when given the opportunity.\n\nEDDY: When I first picked up the Atlas backlog tickets, it was easy for me to feel that I was the only one having a problem and seeing other people pushing dev tickets and stuff, you know. But in reality, with pairing, you get to see really quickly that others are presented with the same problems as well. And the unique part about pairing is you get to see their approach to how they solve a problem. \n\nTo me, the important thing that I've learned thus far is to ensure the problem doesn't become bigger than you do. Use it as a stepping stone, in a sense. So you get comfortable, and you accept it, and it's okay. And accept the fact that it's okay to ask other people for help. You've done a phenomenal job with picking the people that's on the team because everyone that I've reached out to has been more than willing to help and pair. For me, it is basically don't get scared of the uncomfortable situations and instead embrace them, and then eventually, you will find the solution.\n\nDAMON: I think that's just something to piggyback off of here. That's something really interesting that you say because when I did my first ticket, I think it was the day before yesterday. And I was like, \"Hey, can I pair with you? Because I don't know where to start,\" and just seeing how someone will go through the process and they run into the exact same issues that you would run into down the line, it's like, okay, I get it. [laughs] \n\nLike, I wasn't the only one, you know, just not getting it. And then they need your input, or they want your input, and you want their input. So it's just, I don't know, I love it. Like you said, Acima, as a company, picked a fantastic team as a whole.\n\nMIKE: One thing I'd like to maybe add to that is that...let me preface this a little bit. There's a cultural trope of a software developer as being an antisocial recluse who maybe goes down in the basement and bangs away on the keyboard alone for a long time and comes out with some masterpiece. And I'm not going to say that there's nobody who works in the basement. I work in a basement office. [laughs] But that is, in general, a misrepresentation of how software gets built. We work as a community. \n\nMaybe let me give an example perhaps. The most successful software project on Earth is Linux, which is an operating system made by a guy named Linus who did his own take on something similar to the Unix operating system and made a portmanteau of that, of Linus and Unix, and you get Linux. He wrote this simple operating system quite some time ago, more than decades. He just gave it out to the community, formed a community around it. The community worked together to build something amazing. And he started getting industry support, and there are people paid by their companies to work full-time on that operating system. And it grew to become far more than what one person could do. \n\nNow, Linus Torvalds is a very talented person, and he still leads that community. But he's a leader, not the sole developer. In fact, I don't think that somebody in his position should be writing most of the code or trying to because they can't, and they would be spending the time doing things that are more useful, which should be guiding the community. \n\nI give this background to suggest something about how software really gets built. There are people who are capable and working and building things, but they really only become successful when they work together with the community. And as a leader that leader can cultivate an attitude of mentorship and community, or they can breed a toxic environment where everybody is forced to go work on things alone. That's a choice, and sometimes people don't make that choice consciously. I think they usually don't. But there are consequences to that choice that gets made.\n\nWe talked about choosing people well, and honestly, I think that that maybe misrepresents it a little bit in that there are amazing people on the team, but I think there are amazing people all throughout the world. And they're able to be amazing when they're empowered to do so. I'm going to make a passionate entreaty, a call to action to everybody out listening. Within your sphere of influence, try to create that kind of healthy community where people are encouraged and have the opportunity to ask and grow, and if you do, you will build a fertile ground for good software to come out of. \n\nI'd like to share one more thing briefly. I'm an avid gardener. I don't always get as much time to do it as I used to, but I still enjoy it. One thing I've learned is that you don't feed the plants, and maybe if you're doing hydroponic gardening, you do. But if you're out in the soil, you don't feed the plants; you feed the soil. If you try feeding the plants, then you're going to be very focused on the plants, and that tunnel vision you get is going to miss important components. You're going to miss the broader aspect of the ecosystem you're dealing with. \n\nIf instead you pay attention to the soil and create healthy soil, so you're feeding the soil microbes and the invertebrates, and the arthropods, and worms, and whatever else is out there living in your soil and try to grow very healthy soil, then you will have a diverse ecosystem out there that's kind of self-balanced that is not likely to have a lot of diseases, for example. And when you grow your plants in it, they're growing in a healthy environment that will allow them to grow well. \n\nIf you're trying to force your plants to grow, you might be able to make it work sometimes, but it's not going to work very well in the long haul. Rather, if you feed the soil, then the plants will grow on their own naturally. \n\nIn the Midwest, where I live, there's been a change. I don't know exactly the time frame. But it used to be that the debris on the field was always plowed under in the fox. They wanted things to look tidy. They don't do that anymore. They leave the debris from the corn and soybeans on the soil to protect the soil over the winter. It keeps it from blowing away. And it decomposes, and then they turn it in in the spring, where it then feeds the soil. \n\nAnd that change has led to a lot less loss of topsoil and better crops. Just thinking about growing the corn misses something really important. We feed the soil. And as leaders, what we need to do is create an environment for people to thrive, and they will because people are amazing. And they'll bring their different skills to the table and be able to do great things.\n\nDAMON: I think that's a really good analogy.\n\nMIKE: Ramses, we haven't heard a whole lot from you today. You've been working on the team for a while now. \n\nRAMSES: [laughs] Yeah, it's been a while. \n\nMIKE: What has been your experience with impostor syndrome and learning to ask those questions and feel comfortable and like you belong here? \n\nRAMSES: My experience has been really interesting. When I started out in location support, it was very mostly do-it-by-myself kind of approach. I was very community-driven, but I was also self-motivated to find the answer however I could, whether that was just Google or asking a friend or a colleague, who are also my friends. And now it is very...it's kind of the same, but I am definitely a lot more community-driven now and not as self. I mean, I'm still self-motivated, but I try not to spend too much time on a problem by myself. And if I do find myself doing that, then I know it's time to reach out.\n\nMIKE: Do you ever find yourself still questioning, am I sure I belong here?\n\nRAMSES: Yeah, probably all the time. [laughs] I feel like I'm getting a lot more confident. But you do still always have the, you know, is this the right approach, or is this a good approach? Or how can I write my code cleaner or more simpler? But I think the best way to learn is to be uncomfortable, you know, put yourself in uncomfortable situations. That's how you grow.\n\nMIKE: Absolutely. Put yourself in uncomfortable situations. We could probably spend quite a bit of time talking about that one.\n\nRAMSES: Oh yeah.\n\nDAMON: I remember when I was going to therapy for a minute, my therapist would always tell me, \"Lean towards the discomfort. Lean towards the discomfort.\" And I'm like, oh man, [laughter] nobody wants to do that. That's something you just need to do. Because I feel like I have a lot of confidence, but just some days where it's like, man, I know somebody who could figure this out way faster than I could. I'm spending too much time on this. It's just a lot, you know. Yeah, just lean towards that discomfort and make yourself uncomfortable and just do it.\n\nMIKE: Do people go to the gym because they're already, like, totally huge? \n\nRAMSES: Sometimes. \n\nMIKE: Sometimes. [laughter] It's true. [laughs] But they didn't get that; I mean, they didn't start out that way. They go to the gym specifically to do uncomfortable things so that they can grow.\n\nEDDY: I think the biggest point is that when you're first starting in the industry, there's just so much knowledge, and technology, and frameworks that have been established for years before you even heard what programming was that it's really simple to start chipping at the top and you're like, dang, there's just so much I don't know, and it's really simple to feel overwhelmed. That's the problem I had when I first started. The infamous phrase it's just the tip of the iceberg, I think, applies really well here where at the surface, you're just like, yeah, I can do this. But then, if you don't have the right mindset, it's really easy to fall victim to that.\n\nMIKE: It is. I said at the beginning, and I'll say it again, that I recognize every day how little I know after decades in the industry, and I'm an enthusiastic reader. [laughs] I've always loved reading and learning things, and I still feel like I'm just barely scratching the tip of the iceberg. But that doesn't mean that I'm not able to be effective. \n\nI think it's a cognitive bias, some sort of psychological...I don't know if weakness is the right word because we have these biases for a reason, kind of heuristics that guide us but sometimes they lead us astray. And one of them is that we think that we have to do everything to be doing it right. That's just not true. If you've accomplished something, you've accomplished something. Accomplishing everything is nobody's realistic goal. Getting competent enough to do something is a great achievement. \n\nIf you're learning software and you're providing value to the company, then you belong there. You've just done something that company wanted. Well, of course, you belong. You just solved a problem. And you may not understand the full scope of every problem that the organization you're working for is trying to solve or the larger industry here, all the problems of humanity. But you wouldn't expect yourself to do that in other circumstances. You shouldn't have to expect yourself to do that here. \n\nYou do the ticket. You talked about working on a ticket and it seeming intimidating, pairing on it, seeing other people having trouble, and getting through it. But when you get that ticket up and in production, first of all, it's a really great feeling. [chuckles] And secondly, you've accomplished something now. You just provided value. And it doesn't really matter if it was hard. What matters is that you solved the problem.\n\nEDDY: That's super helpful to know, and it makes me feel better about myself in a sense because a lot of the tickets that I will be working on will be beginner tickets, like right now, or cleanup tickets or something like that. So it's like, for me, it's like, oh, somebody just threw it on the side because they didn't really want to do it because, you know, it's simple to me. But it's like, hey, we needed that done. It benefited us in some type of way.\n\nMIKE: We have a pool of work. I used to talk about it with a former product manager. And we said, \"This is important work, but it's not necessarily urgent.\" It's kind of a monster. It applies in software, but I'm thinking it applies in probably many fields of urgency that there's always something that's got to be done in a short time frame. And if you're always paying attention to that monster and fighting it away, then you never take care of some other things that are extremely important. They're just not as urgent. \n\nAnd in the worst case, you can have a situation they call firefighting where you're just running and putting out one fire and then running and putting out another fire because the whole system is just barely holding together, and things are falling apart. And you just solve one disaster after another because you're never taking the time to do the maintenance to prevent those disasters. \n\nAnd you say that you're doing this work that maybe doesn't seem like it's the most urgent. Well, it is true that we tend to have people who are wanting to become developers; we'll give them work that is not the most urgent because we're trying to get it done quickly, but that doesn't mean it's not important. \n\nI'm thinking about that condominium complex in Florida that collapsed a year or two ago. There were problems with the foundation that people had noticed for some years, like parts had been falling into the parking garage. And I think that the pool was not shored up well. And people had seen that for a number of years, seeing that there were problems, but there was always something more important to work on. And I can say important, that's the wrong word. There's always something more urgent to work on. And they didn't take the time to do that work of shoring up the foundation. When it failed, it was catastrophic and tragic. People died.\n\nEDDY: Oh yeah.\n\nMIKE: Had they had somebody go in and do that work to just shore up the foundation, \"Let's fix the foundation here and make sure that important work is done. Even if it's not necessarily urgent, we're going to specifically dedicate some budget to having this important work done,\" then that tragedy could have been averted, and lives could have been saved. \n\nWe're probably not talking about such a life-and-death thing with most of the work that we're doing. Maybe you're in healthcare, and it is life and death. But there is important work to be done, and you shouldn't feel like it's irrelevant just because it's not the most urgent work. We wouldn't have identified that work and created stories for it to be worked on if it wasn't important.\n\nDAMON: I think just hearing that is super reassuring for me personally. It makes me want to learn more and obviously just go and grab tickets and just be like, okay, let me figure it out. Let me learn. Okay, I don't know it. All right, who wants to pair? It's good to hear that, for sure.\n\nMike, let me ask you something point blank here.\n\nMIKE: Yeah, absolutely.\n\nDAMON: When you are in the middle of that transition where you have that milestone that you want to become a full-time developer, is there a general consensus, or is it like perspective for you when you know that you're ready to take that leap? Where do you define that line?\n\nMIKE: That's a great question. Let me try to give you a nuanced answer because I think that a short answer is probably not going to quite cut it. And my nuanced answer is going to be that it probably depends on your situation. Let me elaborate a little bit. You're never going to be ready, and recognizing that, I think, can take a burden off your shoulders because if you're never going to be ready, then you don't have to worry about being perfectly ready. But I think that giving examples is helpful here. \n\nSo let's talk about Olympic athletes. Olympic athletes will spend years, sometimes even decades, of their life training. They're usually younger, so maybe not decades but many years of their lives training for that one moment. And still, only one person is going to win, and sometimes it's a fluke. Somebody has come prepared as well as they possibly can. And then something goes wrong, and it's outside of their control. \n\nWe have human limits that prevent us from really being able to be truly prepared for something completely. That shouldn't be our goal. So I'm going to scale that back to say, well, if you can't be perfectly ready, well, what can you be? And I would say you're ready to jump in if you can consistently provide value in the position that you're going to be given. \n\nSo, for example, let me take an example outside of software. I've worked in construction. And I spent some time as an apprentice carpenter. First, I worked as a laborer. And when they have you work as a laborer, you're not really expected to have any experience at all, and your value comes from being able to haul things around and tear stuff down. You can carry around power cables and plug them in. \n\nAnd I worked at a job once where I tore a whole bunch of wallpaper off walls in a large building. You know what? I didn't have to have a whole lot of skills to do that, just the willingness to spend long sweaty days tearing [laughs] wallpaper off walls. After a while, though, because I actually had had background before that, they had me start with putting on sheetrock because I knew how to do that. And I was providing a little bit more value. \n\nNow I was providing value as a laborer, but I could provide a little more value by actually doing some of the carpentry work. And then I started putting up some of the other parts of the walls, putting in the studs. The job I'm particularly thinking of was indoor construction in the south. So they didn't put in termite-vulnerable things. So we used metal studs, but you screwed them in. I started doing that, so I was providing additional value. Had I stayed at that particular job, I would have become an actual carpenter and become a master of that profession over time. \n\nWell, back in software, nobody's expecting you when you start...if you're getting hired as a senior developer, well, then you should probably have senior developer experience. But when people are hiring you as a junior developer, that's not what they're hiring you to do. They're hiring you to provide value. If what they need is somebody to haul around the wires and the equipment and tear stuff off the walls, well, then you're providing value in that position. \n\nAnd if you're at a company that would be interested in what you have to offer, then you belong, then you're ready. And if you don't have the skills that they need yet, well, then you should build those skills. If you're actively looking to get that career, one of the best ways to do so is to find a position where you can start to work on some of those tasks before you're necessarily full-time. Go and talk to the development team, \"What can I help you with?\" Most people would love to get some help with something. \n\nI gave kind of a long answer to your question because I think that it's important to recognize that you might not be able to find a clear-cut point. You're never going to feel like you're perfectly prepared. But if you can put yourself in a position where you're helping, you're already doing the work. And I think you're ready to go full time when you're able to consistently be providing value all of the time and give more than you get, I guess I would say.\n\nDAMON: Those are fantastic answers. Thank you. Ramses, I kind of want to piggyback off of that question to you as well since it's more recent since you made that transition. When the opportunity presented itself, what was your mindset before and after?\n\nRAMSES: I'm probably a prime example of that question, I think. Before getting into application support in...what was it? October...no August 2020, maybe, time slips by. I had no development experience or very little. And then getting into application support October 5th is, when I picked up my first ticket. And it was a simple add a new selection in this HTML drop-down, super simple. But it kind of really sparked my interest, and from there, just on nights and on weekends, I'd go through Ruby courses and everything else. \n\nBut by the time I made my switch over to full-time development, I had maybe 160 tickets I had merged into production. Through my application support time, I tried to pick up a ticket, a development ticket every week, or a couple every week as much as I could, even if they were just small and simple, and most of them were. But sometimes, I'd work on slightly larger projects, but it was really helpful for my development, I think.\n\nMIKE: I would point out just how closely that mirrors what I was saying, but Ramses provided help, started working on things. He was not full-time yet but grew his skills where he could eventually get to the point where he was basically acting as a developer anyway. So let's hire him on. He's already doing the work. Let's hire that guy already. And he's continued to do a great job, by the way.\n\nDAMON: I can attest that Ramses has been a great asset and a great resource. Coming from someone he trained, he is the best. [laughs]\n\nEDDY: Even though it's bias-ism, I agree, Damon, [laughs] cold-heartedly agree with that statement, yeah.\n\nDAMON: Ramses, did you ever have the imposter syndrome whenever you found out or decided to become a full-time developer?\n\nRAMSES: Yeah, I'm sure I probably did. It was something that I was long waiting for, had plans on moving into development in May 2021 and just had some unexpected events come up, so it just didn't really work out then. But I finally made that transition in...was it February, January? Maybe late January 2022. Sounds about right. Well worth the wait. \n\nMIKE: So we've talked for a while about our individual experiences feeling this imposter syndrome and some ways that we can overcome it: working on building your skills, recognizing some of the psychological biases we have that might mislead us into thinking that we're not ready when we might be, and what we can do to be ready. There is actual value to preparation. Just jumping in completely unprepared isn't a good idea, but recognizing that no amount of preparation is going to fully prepare you. Does anybody have any closing thoughts to tie this up before we conclude our session today?\n\nEDDY: I think it was just comforting to hear that even people who have years in the industry can also relate. And just being able to be vocal and having someone take time to listen to their concerns goes a long way with…\n\nDAMON: The exact same thing. To piggyback off of what he said, hearing people that have had so much time in this industry and have been doing this for a minute they still go through the same things even to this day; as a newbie, it's good to hear that for sure. And it's good to know that we have people all around that want to listen and want to help because they were in that position.\n\nMIKE: Well, let's go ahead and finish up then. Recognize that imposter syndrome is a thing. It's something that strikes most, if not all of us, in making us feel like because we're not perfect, that we don't belong here. We need to do a few things, you know, reach out to mentors, find somebody who can help you as that can make a big difference. Also, recognize that if you are providing value, then you belong. That's what organizations want is somebody who can help. If you're helping, then you're doing the right thing. \n\nAnd finally, if you're wanting to grow your position, reach out and find opportunities to move into that gradually if possible. Find opportunities to help outside the boundaries of where you are. Stretch yourself. If you're not in software development, take a class or reach out. If you're working in a place where they have a development department, ask them if you can help. Can I take some tickets and work on those that you might not have time to do? And hopefully, that'll be well received. And many times, I think it will because people love help. \n\nThere are things we can do to move forward despite our lack of perfect experience that can really help overcome that idea of feeling like you don't belong. Because once you see yourself moving forward and helping people out, you recognize that you do belong there and you're making a difference. \n\nIt's been another great discussion, and I look forward to doing this again next time. Thank you.","content_html":"Impostor Syndrome is definitely a topic that deserves more than one discussion. It's easy to be at a desk and feel like you're not sure; do I belong here? People around me seem to know what they're doing, do I? The answer to both is Yes. We return for Part 2.
\n\nICYMI: Here's Overcoming Impostor Syndrom Part I!
\n\nTranscript:
\n\nMIKE: Welcome to another episode of our Acima Development Podcast. We've got what I think is a good one today. So I think it's something that we struggle with as developers. I think most, if not all of us, hit this occasionally, at least. And we've got a perfect group today to talk about this subject because we've got a wide range of experience.
\n\nThe topic we're going to be addressing today is impostor syndrome. Before we dive into that, let's go ahead and introduce ourselves. I'm Mike. I'm going to be hosting today. Well, let's go around. Eddy, do you want to introduce yourself?
\n\nEDDY: My name is Eddy from the QA team. Happy to be here. Thanks for having me, as always.
\n\nMIKE: Great. Damon.
\n\nDAMON: My name is Damon, and I am on the application support team.
\n\nMIKE: Thank you. And Ramses.
\n\nRAMSES: Hey, everyone. I'm Ramses. I'm on the Atlas development team. Excited to be here.
\n\nMIKE: Thank you. And I'm currently Director of Engineering here at Acima. So we've got a range of experiences, of backgrounds which I think is perfect. We've got somebody who's been doing software development for decades, somebody who's officially on the team who has only been doing it for a short time, somebody from support, and somebody from QA, both of which hope to get into development. It gives us a chance to talk about the different perspectives that we might have on a career in software and how that feels from those different positions. And there are similarities and differences, but I think you'll find that there are more similarities than differences.
\n\nLet me give a little introduction of this idea of imposter syndrome. It doesn't just apply to software; I think it applies in a number of fields but particularly in software where our job is to solve problems. There's no handbook, and there's no clear set of guidelines that this is exactly what you do. Instead, you're sitting in front of a computer with a problem to solve and sort of go ahead, solve it, and that's it.
\n\nAnd you certainly have peers who can help you. But it's easy to be sitting there in that desk and feel like I'm not sure; do I belong here? People around me seem to know what they're doing, do I? [laughs] I have a hard time imagining that there's anybody who doesn't feel that way sometimes. To talk a little bit about my background, I've been, as I mentioned, doing this for over 20 years. I started my full-time software career right after the dot-com bust.
\n\nA lot of those big dot-com companies from the late '90s went belly up in the early 2000s. And the industry was flooded with developers, skilled developers who had just been let go from their jobs. And there was a glut of people to do work, and the jobs hadn't quite caught up yet. And it was very challenging to find work. I eventually found full-time work. My recollection is I was making less at the time than I had been doing working construction previously. [laughs]
\n\nAnd I went and got a degree for this. It was certainly easy to feel like I didn't belong and I had made some wrong choices along the way. That led to some interesting developments. I was working for a startup that went really big and then crashed spectacularly. They actually let go of all the software development team but one, and then he quit. They ended up hiring me back on. So I went from being just a junior developer to running all the software for the company within just a few years. And I wasn't perfect yet, and there was a lot of pressure.
\n\nI learned a lot during that time, trying to run things on my own. I also made some mistakes and had that, you know, I'm swimming in the deep end now. There's nobody here to help me experience lots of mixed feelings. Do I belong here? Do I not belong here? I had some respect in that I was doing the job, but then I wasn't doing it perfectly. And I had all those questions.
\n\nI later moved to another company where I had a somewhat similar experience. We grew tremendously and then slowly tapered off. That company finally shut down operations back in January. And I ended up there at the department for a while and asking myself, am I doing okay? Am I not doing okay? And after a while, after that, I went to contract work.
\n\nAcross all of this time, I had experiences that taught me a lot and had positions where they seemed to show some respect. But all along, all along my entire career, I've wondered, am I really doing okay here? Do I really belong? And now I'm here at Acima. I recently got my title to Director of Engineering, and it sounds kind of respectable. [laughs] But just like everybody else, I'm figuring it out. I can't claim to know everything. There's a lot that I don't know. And I'm always trying to learn just by reading and paying attention to my peers, trying to figure out how to do this the best way.
\n\nI've learned to recognize that I'm never going to know everything. It's a fast-moving field with so much to learn that I couldn't possibly know. And doing well in this industry is not about knowing everything but about having that humility, recognizing you don't and being willing to ask, and further, just trying to solve problems.
\n\nAnd with that, I'd like to, you know, I wanted to give an intro there. Now I'm going to be quiet for a while. And I'm interested in the thoughts of the others here on the call to share what their experience has been and how they perceive things given that background, this idea of imposter syndrome.
\n\nDAMON: Maybe you can add to what you were saying. You mentioned you were in the field for over 20 years. How did you warm up to the idea of imposter syndrome, and how did you get over it?
\n\nMIKE: That's a good question. I don't think I heard the term until much after my career had started. I don't think it's gone into widespread use; I could be wrong; one of those things that I might just not have heard about. But I don't think it's been in widespread use until the last few years. So I think there might be a few answers to that. First of all, when I heard the term, I thought, oh yes, that's what it is.
\n\nAnd I've noticed that as I've mentored a lot of people...and that's something I'll point out that has helped a lot. As I've mentored a lot of people, I've noticed that most developers I've worked with tend to feel that way. They'll express something along the lines of, you know, how am I doing? Do I really belong here? I feel maybe out of place, not because the people around them aren't supportive, but, wow, I'm around a lot of smart, capable people; am I really that? And the answer universally has always been yes. Yes, you are that.
\n\nAnd we have differences in experience. It's not that everybody has exactly the same skill level and exactly the same background. But everyone that I've worked with has had something to contribute. Perhaps the biggest differentiator I've seen as I've done a lot of mentoring between people who are really successful and people who aren't is that the really successful people are deeply curious.
\n\nThey don't see asking questions as a sign of weakness but the natural consequence of their insatiable curiosity. [chuckles] They just want to figure things out. And because of that, they're willing to be vulnerable enough to ask, whether it's to ask their peers, ask mentors, ask Google, ask whatever it is they need to ask to figure problems out and experiment and try. None of us are going to quite know the answers. If we all knew the answers, then we could automate this job, and we'd all be out of work. We don't know the answers as the people who are asking the questions who have been very successful.
\n\nSo to answer your question, how did I see this and get over it? A lot of it has come from not just my own experience but watching everybody else that I've worked with. I've seen so many people become successful. I've mentored a number of people who have gone on to be quite successful in their careers. And they were a diverse group of people, and they've come from different backgrounds. The number of people coming from customer support or similar roles to that, you know, who felt like, wow, I'm going into development; do I really belong here? They went on to become extremely successful.
\n\nAnd seeing that progress of these capable people who maybe doubted themselves at first but allowed that curiosity to blossom allowed that curiosity to lead them to ask those questions and solve the problems. If I'm curious, if I'm solving problems, if I'm helping people out around me, well, I'm adding value. And it doesn't matter if I'm exactly like everybody else around me; I'm helping.
\n\nDAMON: I find that kind of interesting because I came from a different background. So I never did customer service or anything like that. I was in the military for a few years. And I had a position where it was, hey; we're going to give you this piece of equipment. You need to figure out how it works. If it breaks, you need to figure out how to fix it.
\n\nAnd asking questions wasn't encouraged. It was almost frowned upon. It was like, oh, you can't figure it out? Okay, we'll find somebody who can. And when I came to this role sitting side by side with super smart people like Ramses or learning from somebody else, it was like, am I supposed to be here? Is it okay to ask these questions? I think breaking that habit for me is very challenging. [laughs]
\n\nMIKE: That's interesting. Well, I've got a couple of things to say to that. I've seen research that suggests that people who come from the military are more likely to be successful in this field. I don't know all the reasons, and I don't know that researchers know all the reasons. [laughs] But something about that background, maybe about the requirement to be a problem solver, tends to be very helpful.
\n\nThe other thing I would point out, though, is what you said, is that idea of it being frowned on that I shouldn't ask questions; you experienced it there. But I think most of us experienced that somewhere. People who've gone to school, well, if you're asking the person next to you for help on your assignment, well, that might be cheating. And we get ingrained in us this idea that you shouldn't ask for help; doing that is doing it wrong.
\n\nBut in the industry here, the opposite is true that if you're doing it yourself, you're doing it wrong. And let me explain that a little bit. It's not that we can't go off and solve a problem largely independently. But almost none of us are going to write in machine code. We don't write zeros and ones; we're writing computer languages, which were written by somebody else. And most of what we do is use libraries that were written by somebody else or maintain libraries that are written by a community.
\n\nAnd we're just working at the very top of this pyramid that stands on the work of so many women and men who've gone before us. This idea that we would be working alone is, I think, really misguided that we're all deeply dependent on those we're working with now and those who've gone before who've laid the foundation for us.
\n\nThere are many different sources that will tell us, "You shouldn't be asking. You need to be figuring this out on your own." I think most people have to overcome that notion from a variety of backgrounds. Well, you got it in your previous career; many of us get it from our previous careers, or from school, or just from our upbringing. And it may not be universal, but it's quite common.
\n\nDAMON: Yeah, I think that makes sense for sure. Yeah, like you were saying, just being in this field now and asking so many questions, there are so many people that want to help you. There are so many people that are like, "If you have a question, ask." And you kind of think like, oh, that's just something people say. People are just like, you know, "If you have a question, ask." But if you really ask, they're like, "Okay, hold on, let me pair with you and break it down exactly how it's supposed to be." And you learn so much from that. And that has been super helpful, for sure.
\n\nMIKE: I'll ask a follow-up question. Have you had people say things to you like, "I love pairing?"
\n\nDAMON: Oh yeah, especially like Melissa, Afton. They're always down to pair and like, "Well, let me show you exactly how to do it," you know, it's great. They actually love just teaching.
\n\nMIKE: And that love is genuine. It's not, “I'm going to put down this because I'm sympathetic.” They genuinely love it. And I think that those of you listening can probably find a mentor like that because there's a lot of joy in mentoring. It's very enjoyable to go and watch those lights turn on in somebody's eyes and see them get it. It's a wonderful experience, and it's probably my favorite part of the job.
\n\nIt's not something that I feel like I'm being burdened to do, but it's something that I feel like I get to do. Like, oh, wow, I can get out of a long meeting and instead go and help somebody find something cool. It's not something you should be shy to do. And if you're not finding mentors that are willing to do that, then maybe you need to look a little farther afield because they're out there. I found that there are many people who want to share when given the opportunity.
\n\nEDDY: When I first picked up the Atlas backlog tickets, it was easy for me to feel that I was the only one having a problem and seeing other people pushing dev tickets and stuff, you know. But in reality, with pairing, you get to see really quickly that others are presented with the same problems as well. And the unique part about pairing is you get to see their approach to how they solve a problem.
\n\nTo me, the important thing that I've learned thus far is to ensure the problem doesn't become bigger than you do. Use it as a stepping stone, in a sense. So you get comfortable, and you accept it, and it's okay. And accept the fact that it's okay to ask other people for help. You've done a phenomenal job with picking the people that's on the team because everyone that I've reached out to has been more than willing to help and pair. For me, it is basically don't get scared of the uncomfortable situations and instead embrace them, and then eventually, you will find the solution.
\n\nDAMON: I think that's just something to piggyback off of here. That's something really interesting that you say because when I did my first ticket, I think it was the day before yesterday. And I was like, "Hey, can I pair with you? Because I don't know where to start," and just seeing how someone will go through the process and they run into the exact same issues that you would run into down the line, it's like, okay, I get it. [laughs]
\n\nLike, I wasn't the only one, you know, just not getting it. And then they need your input, or they want your input, and you want their input. So it's just, I don't know, I love it. Like you said, Acima, as a company, picked a fantastic team as a whole.
\n\nMIKE: One thing I'd like to maybe add to that is that...let me preface this a little bit. There's a cultural trope of a software developer as being an antisocial recluse who maybe goes down in the basement and bangs away on the keyboard alone for a long time and comes out with some masterpiece. And I'm not going to say that there's nobody who works in the basement. I work in a basement office. [laughs] But that is, in general, a misrepresentation of how software gets built. We work as a community.
\n\nMaybe let me give an example perhaps. The most successful software project on Earth is Linux, which is an operating system made by a guy named Linus who did his own take on something similar to the Unix operating system and made a portmanteau of that, of Linus and Unix, and you get Linux. He wrote this simple operating system quite some time ago, more than decades. He just gave it out to the community, formed a community around it. The community worked together to build something amazing. And he started getting industry support, and there are people paid by their companies to work full-time on that operating system. And it grew to become far more than what one person could do.
\n\nNow, Linus Torvalds is a very talented person, and he still leads that community. But he's a leader, not the sole developer. In fact, I don't think that somebody in his position should be writing most of the code or trying to because they can't, and they would be spending the time doing things that are more useful, which should be guiding the community.
\n\nI give this background to suggest something about how software really gets built. There are people who are capable and working and building things, but they really only become successful when they work together with the community. And as a leader that leader can cultivate an attitude of mentorship and community, or they can breed a toxic environment where everybody is forced to go work on things alone. That's a choice, and sometimes people don't make that choice consciously. I think they usually don't. But there are consequences to that choice that gets made.
\n\nWe talked about choosing people well, and honestly, I think that that maybe misrepresents it a little bit in that there are amazing people on the team, but I think there are amazing people all throughout the world. And they're able to be amazing when they're empowered to do so. I'm going to make a passionate entreaty, a call to action to everybody out listening. Within your sphere of influence, try to create that kind of healthy community where people are encouraged and have the opportunity to ask and grow, and if you do, you will build a fertile ground for good software to come out of.
\n\nI'd like to share one more thing briefly. I'm an avid gardener. I don't always get as much time to do it as I used to, but I still enjoy it. One thing I've learned is that you don't feed the plants, and maybe if you're doing hydroponic gardening, you do. But if you're out in the soil, you don't feed the plants; you feed the soil. If you try feeding the plants, then you're going to be very focused on the plants, and that tunnel vision you get is going to miss important components. You're going to miss the broader aspect of the ecosystem you're dealing with.
\n\nIf instead you pay attention to the soil and create healthy soil, so you're feeding the soil microbes and the invertebrates, and the arthropods, and worms, and whatever else is out there living in your soil and try to grow very healthy soil, then you will have a diverse ecosystem out there that's kind of self-balanced that is not likely to have a lot of diseases, for example. And when you grow your plants in it, they're growing in a healthy environment that will allow them to grow well.
\n\nIf you're trying to force your plants to grow, you might be able to make it work sometimes, but it's not going to work very well in the long haul. Rather, if you feed the soil, then the plants will grow on their own naturally.
\n\nIn the Midwest, where I live, there's been a change. I don't know exactly the time frame. But it used to be that the debris on the field was always plowed under in the fox. They wanted things to look tidy. They don't do that anymore. They leave the debris from the corn and soybeans on the soil to protect the soil over the winter. It keeps it from blowing away. And it decomposes, and then they turn it in in the spring, where it then feeds the soil.
\n\nAnd that change has led to a lot less loss of topsoil and better crops. Just thinking about growing the corn misses something really important. We feed the soil. And as leaders, what we need to do is create an environment for people to thrive, and they will because people are amazing. And they'll bring their different skills to the table and be able to do great things.
\n\nDAMON: I think that's a really good analogy.
\n\nMIKE: Ramses, we haven't heard a whole lot from you today. You've been working on the team for a while now.
\n\nRAMSES: [laughs] Yeah, it's been a while.
\n\nMIKE: What has been your experience with impostor syndrome and learning to ask those questions and feel comfortable and like you belong here?
\n\nRAMSES: My experience has been really interesting. When I started out in location support, it was very mostly do-it-by-myself kind of approach. I was very community-driven, but I was also self-motivated to find the answer however I could, whether that was just Google or asking a friend or a colleague, who are also my friends. And now it is very...it's kind of the same, but I am definitely a lot more community-driven now and not as self. I mean, I'm still self-motivated, but I try not to spend too much time on a problem by myself. And if I do find myself doing that, then I know it's time to reach out.
\n\nMIKE: Do you ever find yourself still questioning, am I sure I belong here?
\n\nRAMSES: Yeah, probably all the time. [laughs] I feel like I'm getting a lot more confident. But you do still always have the, you know, is this the right approach, or is this a good approach? Or how can I write my code cleaner or more simpler? But I think the best way to learn is to be uncomfortable, you know, put yourself in uncomfortable situations. That's how you grow.
\n\nMIKE: Absolutely. Put yourself in uncomfortable situations. We could probably spend quite a bit of time talking about that one.
\n\nRAMSES: Oh yeah.
\n\nDAMON: I remember when I was going to therapy for a minute, my therapist would always tell me, "Lean towards the discomfort. Lean towards the discomfort." And I'm like, oh man, [laughter] nobody wants to do that. That's something you just need to do. Because I feel like I have a lot of confidence, but just some days where it's like, man, I know somebody who could figure this out way faster than I could. I'm spending too much time on this. It's just a lot, you know. Yeah, just lean towards that discomfort and make yourself uncomfortable and just do it.
\n\nMIKE: Do people go to the gym because they're already, like, totally huge?
\n\nRAMSES: Sometimes.
\n\nMIKE: Sometimes. [laughter] It's true. [laughs] But they didn't get that; I mean, they didn't start out that way. They go to the gym specifically to do uncomfortable things so that they can grow.
\n\nEDDY: I think the biggest point is that when you're first starting in the industry, there's just so much knowledge, and technology, and frameworks that have been established for years before you even heard what programming was that it's really simple to start chipping at the top and you're like, dang, there's just so much I don't know, and it's really simple to feel overwhelmed. That's the problem I had when I first started. The infamous phrase it's just the tip of the iceberg, I think, applies really well here where at the surface, you're just like, yeah, I can do this. But then, if you don't have the right mindset, it's really easy to fall victim to that.
\n\nMIKE: It is. I said at the beginning, and I'll say it again, that I recognize every day how little I know after decades in the industry, and I'm an enthusiastic reader. [laughs] I've always loved reading and learning things, and I still feel like I'm just barely scratching the tip of the iceberg. But that doesn't mean that I'm not able to be effective.
\n\nI think it's a cognitive bias, some sort of psychological...I don't know if weakness is the right word because we have these biases for a reason, kind of heuristics that guide us but sometimes they lead us astray. And one of them is that we think that we have to do everything to be doing it right. That's just not true. If you've accomplished something, you've accomplished something. Accomplishing everything is nobody's realistic goal. Getting competent enough to do something is a great achievement.
\n\nIf you're learning software and you're providing value to the company, then you belong there. You've just done something that company wanted. Well, of course, you belong. You just solved a problem. And you may not understand the full scope of every problem that the organization you're working for is trying to solve or the larger industry here, all the problems of humanity. But you wouldn't expect yourself to do that in other circumstances. You shouldn't have to expect yourself to do that here.
\n\nYou do the ticket. You talked about working on a ticket and it seeming intimidating, pairing on it, seeing other people having trouble, and getting through it. But when you get that ticket up and in production, first of all, it's a really great feeling. [chuckles] And secondly, you've accomplished something now. You just provided value. And it doesn't really matter if it was hard. What matters is that you solved the problem.
\n\nEDDY: That's super helpful to know, and it makes me feel better about myself in a sense because a lot of the tickets that I will be working on will be beginner tickets, like right now, or cleanup tickets or something like that. So it's like, for me, it's like, oh, somebody just threw it on the side because they didn't really want to do it because, you know, it's simple to me. But it's like, hey, we needed that done. It benefited us in some type of way.
\n\nMIKE: We have a pool of work. I used to talk about it with a former product manager. And we said, "This is important work, but it's not necessarily urgent." It's kind of a monster. It applies in software, but I'm thinking it applies in probably many fields of urgency that there's always something that's got to be done in a short time frame. And if you're always paying attention to that monster and fighting it away, then you never take care of some other things that are extremely important. They're just not as urgent.
\n\nAnd in the worst case, you can have a situation they call firefighting where you're just running and putting out one fire and then running and putting out another fire because the whole system is just barely holding together, and things are falling apart. And you just solve one disaster after another because you're never taking the time to do the maintenance to prevent those disasters.
\n\nAnd you say that you're doing this work that maybe doesn't seem like it's the most urgent. Well, it is true that we tend to have people who are wanting to become developers; we'll give them work that is not the most urgent because we're trying to get it done quickly, but that doesn't mean it's not important.
\n\nI'm thinking about that condominium complex in Florida that collapsed a year or two ago. There were problems with the foundation that people had noticed for some years, like parts had been falling into the parking garage. And I think that the pool was not shored up well. And people had seen that for a number of years, seeing that there were problems, but there was always something more important to work on. And I can say important, that's the wrong word. There's always something more urgent to work on. And they didn't take the time to do that work of shoring up the foundation. When it failed, it was catastrophic and tragic. People died.
\n\nEDDY: Oh yeah.
\n\nMIKE: Had they had somebody go in and do that work to just shore up the foundation, "Let's fix the foundation here and make sure that important work is done. Even if it's not necessarily urgent, we're going to specifically dedicate some budget to having this important work done," then that tragedy could have been averted, and lives could have been saved.
\n\nWe're probably not talking about such a life-and-death thing with most of the work that we're doing. Maybe you're in healthcare, and it is life and death. But there is important work to be done, and you shouldn't feel like it's irrelevant just because it's not the most urgent work. We wouldn't have identified that work and created stories for it to be worked on if it wasn't important.
\n\nDAMON: I think just hearing that is super reassuring for me personally. It makes me want to learn more and obviously just go and grab tickets and just be like, okay, let me figure it out. Let me learn. Okay, I don't know it. All right, who wants to pair? It's good to hear that, for sure.
\n\nMike, let me ask you something point blank here.
\n\nMIKE: Yeah, absolutely.
\n\nDAMON: When you are in the middle of that transition where you have that milestone that you want to become a full-time developer, is there a general consensus, or is it like perspective for you when you know that you're ready to take that leap? Where do you define that line?
\n\nMIKE: That's a great question. Let me try to give you a nuanced answer because I think that a short answer is probably not going to quite cut it. And my nuanced answer is going to be that it probably depends on your situation. Let me elaborate a little bit. You're never going to be ready, and recognizing that, I think, can take a burden off your shoulders because if you're never going to be ready, then you don't have to worry about being perfectly ready. But I think that giving examples is helpful here.
\n\nSo let's talk about Olympic athletes. Olympic athletes will spend years, sometimes even decades, of their life training. They're usually younger, so maybe not decades but many years of their lives training for that one moment. And still, only one person is going to win, and sometimes it's a fluke. Somebody has come prepared as well as they possibly can. And then something goes wrong, and it's outside of their control.
\n\nWe have human limits that prevent us from really being able to be truly prepared for something completely. That shouldn't be our goal. So I'm going to scale that back to say, well, if you can't be perfectly ready, well, what can you be? And I would say you're ready to jump in if you can consistently provide value in the position that you're going to be given.
\n\nSo, for example, let me take an example outside of software. I've worked in construction. And I spent some time as an apprentice carpenter. First, I worked as a laborer. And when they have you work as a laborer, you're not really expected to have any experience at all, and your value comes from being able to haul things around and tear stuff down. You can carry around power cables and plug them in.
\n\nAnd I worked at a job once where I tore a whole bunch of wallpaper off walls in a large building. You know what? I didn't have to have a whole lot of skills to do that, just the willingness to spend long sweaty days tearing [laughs] wallpaper off walls. After a while, though, because I actually had had background before that, they had me start with putting on sheetrock because I knew how to do that. And I was providing a little bit more value.
\n\nNow I was providing value as a laborer, but I could provide a little more value by actually doing some of the carpentry work. And then I started putting up some of the other parts of the walls, putting in the studs. The job I'm particularly thinking of was indoor construction in the south. So they didn't put in termite-vulnerable things. So we used metal studs, but you screwed them in. I started doing that, so I was providing additional value. Had I stayed at that particular job, I would have become an actual carpenter and become a master of that profession over time.
\n\nWell, back in software, nobody's expecting you when you start...if you're getting hired as a senior developer, well, then you should probably have senior developer experience. But when people are hiring you as a junior developer, that's not what they're hiring you to do. They're hiring you to provide value. If what they need is somebody to haul around the wires and the equipment and tear stuff off the walls, well, then you're providing value in that position.
\n\nAnd if you're at a company that would be interested in what you have to offer, then you belong, then you're ready. And if you don't have the skills that they need yet, well, then you should build those skills. If you're actively looking to get that career, one of the best ways to do so is to find a position where you can start to work on some of those tasks before you're necessarily full-time. Go and talk to the development team, "What can I help you with?" Most people would love to get some help with something.
\n\nI gave kind of a long answer to your question because I think that it's important to recognize that you might not be able to find a clear-cut point. You're never going to feel like you're perfectly prepared. But if you can put yourself in a position where you're helping, you're already doing the work. And I think you're ready to go full time when you're able to consistently be providing value all of the time and give more than you get, I guess I would say.
\n\nDAMON: Those are fantastic answers. Thank you. Ramses, I kind of want to piggyback off of that question to you as well since it's more recent since you made that transition. When the opportunity presented itself, what was your mindset before and after?
\n\nRAMSES: I'm probably a prime example of that question, I think. Before getting into application support in...what was it? October...no August 2020, maybe, time slips by. I had no development experience or very little. And then getting into application support October 5th is, when I picked up my first ticket. And it was a simple add a new selection in this HTML drop-down, super simple. But it kind of really sparked my interest, and from there, just on nights and on weekends, I'd go through Ruby courses and everything else.
\n\nBut by the time I made my switch over to full-time development, I had maybe 160 tickets I had merged into production. Through my application support time, I tried to pick up a ticket, a development ticket every week, or a couple every week as much as I could, even if they were just small and simple, and most of them were. But sometimes, I'd work on slightly larger projects, but it was really helpful for my development, I think.
\n\nMIKE: I would point out just how closely that mirrors what I was saying, but Ramses provided help, started working on things. He was not full-time yet but grew his skills where he could eventually get to the point where he was basically acting as a developer anyway. So let's hire him on. He's already doing the work. Let's hire that guy already. And he's continued to do a great job, by the way.
\n\nDAMON: I can attest that Ramses has been a great asset and a great resource. Coming from someone he trained, he is the best. [laughs]
\n\nEDDY: Even though it's bias-ism, I agree, Damon, [laughs] cold-heartedly agree with that statement, yeah.
\n\nDAMON: Ramses, did you ever have the imposter syndrome whenever you found out or decided to become a full-time developer?
\n\nRAMSES: Yeah, I'm sure I probably did. It was something that I was long waiting for, had plans on moving into development in May 2021 and just had some unexpected events come up, so it just didn't really work out then. But I finally made that transition in...was it February, January? Maybe late January 2022. Sounds about right. Well worth the wait.
\n\nMIKE: So we've talked for a while about our individual experiences feeling this imposter syndrome and some ways that we can overcome it: working on building your skills, recognizing some of the psychological biases we have that might mislead us into thinking that we're not ready when we might be, and what we can do to be ready. There is actual value to preparation. Just jumping in completely unprepared isn't a good idea, but recognizing that no amount of preparation is going to fully prepare you. Does anybody have any closing thoughts to tie this up before we conclude our session today?
\n\nEDDY: I think it was just comforting to hear that even people who have years in the industry can also relate. And just being able to be vocal and having someone take time to listen to their concerns goes a long way with…
\n\nDAMON: The exact same thing. To piggyback off of what he said, hearing people that have had so much time in this industry and have been doing this for a minute they still go through the same things even to this day; as a newbie, it's good to hear that for sure. And it's good to know that we have people all around that want to listen and want to help because they were in that position.
\n\nMIKE: Well, let's go ahead and finish up then. Recognize that imposter syndrome is a thing. It's something that strikes most, if not all of us, in making us feel like because we're not perfect, that we don't belong here. We need to do a few things, you know, reach out to mentors, find somebody who can help you as that can make a big difference. Also, recognize that if you are providing value, then you belong. That's what organizations want is somebody who can help. If you're helping, then you're doing the right thing.
\n\nAnd finally, if you're wanting to grow your position, reach out and find opportunities to move into that gradually if possible. Find opportunities to help outside the boundaries of where you are. Stretch yourself. If you're not in software development, take a class or reach out. If you're working in a place where they have a development department, ask them if you can help. Can I take some tickets and work on those that you might not have time to do? And hopefully, that'll be well received. And many times, I think it will because people love help.
\n\nThere are things we can do to move forward despite our lack of perfect experience that can really help overcome that idea of feeling like you don't belong. Because once you see yourself moving forward and helping people out, you recognize that you do belong there and you're making a difference.
\n\nIt's been another great discussion, and I look forward to doing this again next time. Thank you.
","summary":"Impostor Syndrome is definitely a topic that deserves more than one discussion. It's easy to be at a desk and feel like you're not sure; do I belong here? People around me seem to know what they're doing, do I? The answer to both is YES. We return for Part 2. ","date_published":"2022-12-07T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/d8d5df6e-e0b4-4ae7-9d7e-7fb65455a914.mp3","mime_type":"audio/mpeg","size_in_bytes":40919407,"duration_in_seconds":2268}]},{"id":"805bff88-ff28-4a19-99fe-52b3124ba3e5","title":"Episode 5: Questions Rails Doesn't Answer","url":"https://acima-development.fireside.fm/5","content_text":"The topic is the Rails framework. What architectural questions does Rails answer? What architectural questions does Rails not answer? Great topic, whether you're a Rubyist or not!\n\nTranscript:\n\nMIKE: Welcome to our podcast. I think we have a name now. I think we're going to call this The Acima Development Podcast. Nice. So welcome to The Acima Development Podcast. I'm Mike. I'll be hosting today. And let's go through and talk with some of the people who are here today. Eddy, do you want to introduce yourself?\n\nEDDY: Like Mike said, I'm Eddy. I'm an employee here at Acima. I've been here a couple of times, and I'm in the QA department. So I'm super happy to be here. \n\nMIKE: Great. Dave.\n\nDAVE: Hello from the software minds. My name is Dave. I've been goofing around in Ruby for, gosh, about 15 years now, holy crap, no, 16, anyway, a long time. And I'm happy to be here. \n\nMIKE: Ramses.\n\nRAMSES: Hi, everyone. It's been a couple of weeks since I've been on. I'm Ramses. I've been dabbling with Ruby for a little over a year now. \n\nMIKE: And Damon.\n\nDAMON: Hey, everybody. I'm Damon. It's good to be here again for the ADP Podcast. I've been here for about a year and a couple of months now, sort of a freshman in Ruby, so excited to learn everything.\n\nMIKE: Great. Today we're going to be talking about an interesting topic. This one's been interesting to me for a long time. And the topic is in the Rails framework. This applies not just to Rails. It kind of is a universal topic. Well, we'll be focusing on Rails; it's more universal. \n\nWhat architectural questions does Rails not answer? What architectural questions does Rails not answer? It does answer some. That's part of why people are very quick at using it and get things up quickly because they don't have to answer so many questions that are kind of obvious. But there's a lot that it doesn't answer. This is universal across frameworks. So I think this is a really good topic, whether you're Rubyist or not. \n\nAnd I wanted to start today by reading a quote from Robert C. Martin, who goes by Uncle Bob. If you're not familiar with him, change that. He's an icon in the community and talks about architecture on his Clean Code Blog. There's a post from...it looks like September 30th of 2011. And I want to read a couple of paragraphs (Looks like four paragraphs.) right from the beginning of this blog post. \n\nHe says, \"Imagine that you are looking at the blueprints of a building. This document, prepared by an architect, tells you the plans for the building. What do these plans tell you?\n\nIf the plans you are looking at are for a single-family residence, then you’ll probably see a front entrance, a foyer leading to the living room, and perhaps a dining room. There’ll likely be a kitchen a short distance away, close to the dining room. Perhaps a dinette area next to the kitchen, and probably a family room close to that. As you looked at those plans, there’d be no question that you were looking at a house. The architecture would scream house.\n\nOr, if you were looking at the architecture of a library, you’d likely see a grand entrance, an area for check-in-out clerks, reading areas, small conference rooms, and gallery after gallery capable of holding bookshelves for all the books in the library. That architecture would scream library.\n\nSo what does the architecture of your application scream? When you look at the top-level directory structure and the source files in the highest-level package, do they scream: Health Care System, or Accounting System, or Inventory Management System? Or do they scream: Rails, or Spring/Hibernate, or ASP?\"\n\nDAVE: That's a very dangerous question because, to my mind, Rails isn't an architecture; it's a style. It's kind of like going to the Parthenon. And I'm going to get my Greek architecture wrong here. But it's basically looking at this and saying, \"Ah, the architecture here is Dorian, or it's Ionian because of the columns with the flutes and the substances and the scallops.\" To my mind, Rails should be that, when you look at a project, you should go, oh, this is a library that's built in Rails, or oh, this is a house that's built in Rails. But you're absolutely right. Too often, we look at a house, or we look at the architecture and go, yes, this is bricks.\n\nMIKE: [laughs] Yeah, well said. These are bricks. That's absolutely what this is. And if you're a new developer coming into that project or an experienced developer in that project and you want to think about what's there, looking at a big pile of bricks is probably not very helpful to you. \n\nDAMON: Definitely not. \n\nMIKE: I think that's a great introduction to this discussion because we're talking about...and he mentioned three frameworks there deliberately. We're mostly going to be talking about Rails because we're a Rails shop, but this is universal. And frameworks tend to converge. There's converge and evolution where they tend to look like each other after a while. They tend to answer similar architectural questions, and then there are other questions they don't answer. \n\nAnd the questions they do tend to answer are, in some ways, the easier ones. We'll say, \"Oh yeah, we want to have a tiered structure, a layer that talks to the database, a layer that has our business logic, and then a layer that presents things.\" And we'll call that a model layer, a controller layer, and a view layer, model talking to the data, controller is dealing with your business logic, and then a view layer that's going to present things. \n\nRails calls itself MVC, and it sort of is, but it blurs those boundaries a little bit, I would argue. I would say that in Rails, what they call the controller and view are really both mostly a presentation layer. And the business logic layer, that actual controller layer, is largely not specified. And I think that that is the big unanswered question that we usually have to answer when we're building a Rails app. \n\nI'm kind of drawing a line there in the sand. [laughs] This is where I'm going to make a proposal that that's where the boundaries of the framework are. They're a little bit misleading, and they have become kind of the starting point. In a big app, most of your code is probably not going to be in those three buckets; it's going to be in the actual business logic layer, which makes up most of your app. Are those consistent? \n\nSo, Dave, you've had deep experience with software development, and then all of us have had some experience. I'm particularly interested in what you have to say, Dave, if you've got thoughts about my suggestion there.\n\nDAVE: I kind of like it. Actually, I think you said something casually revolutionary, which is that most of a large business application doesn't fit into those three boxes; I really, really like that. Rails will give you tiny architectural, I mean, there's a bunch of big architectures, but it'll give you some tiny, you know, like ionic columns are the ones that...sorry for the stupid Greek architecture reference. But the little flutes on the columns are not part of Doric architecture; those are part of Ionian architecture, which meant they came from a different group of people. \n\nRails will give you a thing, and it's not new to Rails, but they took on this coat and wore it boldly. They'll give you a thing that if you want to talk to an object that came from the database, you go find the class that maps to that table. And you ask the class to find you instances of rows in that table, and you get those rows back. And then, if you want to manipulate a row in the table, you talk to the objects of that class, the instances of that class. \n\nAnd it's so easy to soak in Rails so deeply that you just think everything works that way, but a lot of projects don't. A lot of projects say, yeah, the objects in this system, the back office stuff, the database, housekeeping is secondary, tertiary. It's like, the most important thing we can do with this is have this object communicate to other objects and produce a viable business result. The database is just a parking lot where we put them and get them. \n\nRails brings this front end to the fore with that ActiveRecord architecture. And if you try to make all of your models fit into the model directory or even into the model bucket, you're going to have this problem where (And I've actually had this happen.) your application will end up looking like a database. You can actually make a map of your business model by just dumping the database tables, the ERD, the entity relationship diagram, the ERD. \n\nI've had gigs where I literally walked in and all I did was dump the database structure and print it out on paper in a four-point font and made a poster that was like five feet wide and four feet tall. And people come in and go, \"Holy crap, what is that?\" And I say, \"That's what you've built. And the entire point of this poster was to make you go holy crap.\" So, you know, this poster has served...I'm getting off on a tangent, as I am one to do. \n\nBut the point being is that if you take the architecture blindly without thinking about it, you will start laying down these defaults, put the objects in the model directory, that means they map to the database table, that means you find them by searching from the class. And that means you interact with them by interacting with the instances. Those initial default steps are in a particular direction. It just feels like you're just taking a step, but you are taking a step in a specific direction. And if you look far enough ahead, you can see the corner that you're going to wind up painted into.\n\nMIKE: And I would argue that we do, we get into that corner. We have a hard time conceiving that there might be resources that don't map to a database table. For example, let's say you have a subscription, and you're going to cancel that subscription. And in your database, cancellation is just a single date. So you think, oh, I'm canceling my subscription. Well, that's something that I do on my subscription. And as soon as you've thought that, you've taken a step too far because you're not thinking about resources anymore. You're thinking about your database table.\n\nDAVE: Right, because it's the user who cancels their subscription. \n\nMIKE: The user cancels a subscription. Those are three things: there's a user thing, there's a cancellation thing, and there's a subscription thing. So presumably, you have a subscription object, but you might not have a...well, we call them objects. Why not treat that cancellation as a thing, even if it's not a first-class thing? If it doesn't have its own table in the database, so? That doesn't mean that it's not a resource that somebody is interacting with. \n\nYou're interacting with that cancellation thing. And if you structure your code around this cancellation thing, now you've followed best practices for a RESTful, you know, the REST being the representational state transfer. That's the attempt to use HTTP the way it was designed, hypertext transport protocol the way it was designed, which is to think about resources that you interact with. \n\nWell, if you think about well, I've got this cancellation resource, and I'm just going to create a cancellation. In Rails, you create a cancellations controller with a create method. It maps directly to that REST idea, and everything just works perfectly. The only thing that's going to veer a little bit from the way you normally think about it is instead of creating a cancellation in the database, well, you probably should have one. A lot of times, there's a sign there that maybe there's an object missing, but you just write that date to your subscriptions table and done. You didn't have to have an ActiveRecord cancellation object in order to have that resource.\n\nDAVE: So there are some people listening to this right now who are going, \"But...but...but...you can do this in Rails. It doesn't prevent you.\" Yeah, it doesn't. It doesn't. But there are things that are uphill, and then there are things that are very steeply downhill that it's just easy to fall into them. I remember 15 years ago when web sessions were stored in a column on the user record, like, you had your session ID. And there might be a sessions table, or there might just be a cookie ID that you store on a user record, and we can look at that user. And it's a terrible security practice, don't do it that way. \n\nI remember when the world shifted to RESTful sessions. So when you go to log in, it actually takes you to the session's controller new action. I'm like, no, I don't want to make a new session. I want to log in; logging in is what I'm doing. I don't want to create a new session. And I remember when sessions went to RESTful, and it makes sense in my brain now for sessions to be RESTful. When you log in, you create a session; when you log out, you delete your session. And oftentimes, now those are in a separate sessions table. \n\nBut when we first got into these, the thing that we got led very strongly to by the hand almost was login is going to be a thing that a user can do, and it will change the nature of that user record. That user record in the database goes from just being a user in the system to a user who is currently logged in, and we can find them, or they can be found by a cookie identifier in a browser. And that was a huge leap. Like, somebody had to come in and think really hard about what Rails wasn't doing for us with this user column and then step back and say, \"Oh, we need RESTful sessions.\" \n\nAnd I think what you've just described, Mike, this cancellations idea it's the same thing. Like if you just look at the things that are in front of you, you might be tempted to say add column to the subscriptions table, canceled at is a date time, and we're done. We just add a timestamp for when that subscription was canceled. Then there's this whole separate idea of, like, well, let's create a cancellation. Let's edit a cancellation, let's delete a cancellation, let's search for cancellations.\nAnd to the people that are saying Rails doesn't stop you from doing that, I want to say I agree with you 100%. But Rails doesn't tell you to go that way. Rails doesn't give you any hint that that direction even exists. You have to know it's on the other side of that wall; let's punch straight through and grab it. Does that make sense? Like, that idea is kind of hidden because of the way Rails is very much built around verbs and controller actions and transactions. \n\nAnd you can build RESTful things out of Rails. Rails makes it very easy to do resources add and that sort of thing. But out of the box, its route get canceled on the subscription. Cancel becomes the verb, and that's not REST which, I mean, might be okay, but it's a decision. \n\nMIKE: You look at the documentation, and Rails will actually encourage you to build a resource. But until you made that mental leap, it's very easy to fall into that, oh, I'm just going to pack more stuff into this thing. Ramses, I believe you've recently been disentangling one of these with a significant refactoring project. \n\nRAMSES: Yeah, it's complete now. But it was four or five weeks' worth of refactoring custom REST methods into more resourceful actions.\n\nMIKE: What was it like when you had that realization? Like, wait, these are all just things.\n\nRAMSES: Yeah, it's really eye-opening. It's easy to get into the mindset of oh, I can just add a custom REST method into this controller, but it doesn't quite make sense. I think it makes a lot of sense when you get out of the mindset of thinking about the object that you're interacting with has to be in the database, or it has to be a model or something. When you realize it doesn't, it makes it a lot easier to work with, I think.\n\nMIKE: Once the code had been refactored and you saw it as a bunch of resources rather than a bunch of stuff crammed into one file, how did the code feel to you? What's your vibe? [laughs] How does it feel to you now?\n\nRAMSES: It's a lot less cluttered rather than everything cram packed into two controllers. I think there are like eight total controllers now, but it's namespaced really greatly, I think, and abstracted out into separate concepts. So it's really easy to digest what's going on.\n\nMIKE: I love a couple of things you said there. You said easy. [chuckles] Easy is a good thing. If you go into a project and it's hard, that's a sign that something's wrong because it means that somebody has to think about it. It means they'll likely think about a problem. It means we haven't structured it in a way that's easy for people to understand. \n\nYou also said another word for what it was like before, which is cluttered, which is another word suggesting complexity. When you see a bunch of stuff that's disorganized, chaos, or entropy, disorder, it's hard to wrap your mind around it because there's not a pattern. And if you can get away from that and put things into a consistent pattern, they're easier to think about. \n\nAnd we've solved a major problem which is allowing ourselves to think about the problem, which is maybe, arguably, that's the most important thing that we solve in code is breaking up the problem into pieces that we can think about so that we can then have them do stuff. That resourceful idea is there. Rails provides it for you. But you got to take advantage of it. So that's an excellent example of something that you might not get without thinking about it. \n\nAnd this applies not just to a web controller, and we're referring to controllers here in the Rails sense. But like I was saying before, it's a little bit of a stretch on that controller idea, and there's not much business logic there. But it's handling the requests that are coming in from the web and delegating that to where they need to go. Organizing those into resources, I think is hugely useful. But that applies (Dave was talking about a fractal before.) that applies I think throughout the architecture that you want to have this idea of resources so that you can think about a thing. \n\nLike, I'm going to go interact with my subscriptions, for example. That's a resource. And within those subscriptions, I want to interact with cancellations. So there's a sub thing. It's related things. Maybe you think of it as sort of a tree, and you go through the subscriptions and get over to these cancellations, and cancellations are a thing. Once I've done that, I can think about that cancellation resource. And I might create one. I might delete one, undo the cancellation, or I might update one, and so on. Thinking about things in terms of things that are resources allows you to organize your mind into those patterns and make order out of chaos. \n\nI've got a pivot here into another huge question that Rails doesn't answer. But I want to make sure everybody here has a chance to speak. Any other thoughts on this particular topic? We've talked a lot about this, organizing, and resources.\n\nDAVE: This notion of creating order out of chaos, I can't express how revolutionary that idea that you gave of if you just put things in these three bins, you're going to be in trouble. There are certain things, like, Rails, makes it very, very easy to map your application domain, the high-level thing that users interact with all the way to a database. I mean, you can create one route, which creates...scaffolding up the models for it. You can fill in the forms, and you can save database records. \n\nAnd if your end users are prepared to think in terms of selecting from sets of things from the database, you're going to be able to write an entire Rails app in 15 minutes, and it's the ancient build a blog in 15 minutes concept. If the idea that you have for your application does not fit well into a database, Rails won't stop you from doing it, but it also doesn't pave the way and gild the curbs, and puts nice, safe street lighting in that direction. \n\nA good example of something that's kind of in both camps...it's like it's painful to get there but also kind of...I don't know. A good example of this is nested sets. They are really, really awkward to build in a database. There's a really clever algorithm for storing just Google nested set lgt rgt, that notion...or lft, rgt, sorry. These are database columns that you store for left and right, and they're the bounds of a subset inside a set. I realize I'm speaking gibberish. \n\nMy point is that this is a data structure. It lets you build a graph. It's like, Mike runs a team, and on that team, there are these people. And each of these people have people that they can contact that are their friends. So let's find the friends. I've got somebody who's a friend who's on this team who's under a manager, and that manager has another person; let's find their friends. That up to down to relationship is something you can do really well if you have this notion of nested sets in your database. \n\nBut reducing a nested set from object-oriented space to a database graph is very awkward, very painful, and very difficult, and when you translate that to Rails space, all of that awkward transformation in the database remains. It's really hard to make that go away. And you really hit on this, that if you try to make a database model out of this, you're going to suffer. \n\nBut if you can find a way to express it in a primary way, it's like, what is the native way to express these collections? Well, I want to do some things. I want to add a person. I want to find people based on this. Can we do this without mapping it all the way into the database? If we can, we're going to have an easy time of it. And Rails doesn't make that easy. It doesn't prevent you from doing it, but it doesn't make it easy. \n\nAnd there's part of me that says, so what's my point? But that is my point is that when you make a bunch of things very, very easy, you make the things that you don't make easy, the things that you leave undescribed, but they're still possible, by default, and by comparison, those end up looking really hard. It's not something Rails is bad at; it's just something Rails doesn't do for you.\n\nMIKE: Nor could it, and that's not Rails-specific either. As I was saying before, there's no framework that's going to answer all of your questions that's going to build your app for you. If you did, then you probably would use a no-code solution. And those exist, and they have actual value in the places that people use them. But if you're building something novel, the whole reason that you're building software is to solve a problem that wasn't solvable in another way. And the framework is probably not going to give you everything you need, and that's not a diss on the framework.\n\nDAVE: Yeah. The architectural blueprint is meant to convey a certain idea about the thing that you are building, and you're supposed to have a look at it and see the salient points. It's not going to tell you where the library should be built. It's not going to tell you what language the book should be in. It's not going to tell you should this library be a public or a private resource. It's not going to give you any of that. It's just going to give you this is what the building is going to look like. And you can put it anywhere, and you can build it how you want. And that's good. \n\nOoh, now that's a dangerous question. What questions should architecture leave unanswered? It's a subtle difference from what we're doing today. What we're doing today is what architectural things does Rails leave unanswered, which is a kind of a 90-degree question.\n\nMIKE: Well, I'm going to propose that there's another one that Rails doesn't answer that basically every Rails app is going to need to...every Rails developer is going to have to deal with. And it goes back to something I hinted at before, which is that in Rails, when they say model-view-controller, the models and controllers together, they call them Action Pack. It's really they interact with the web part. What happens if you start having background services? Those don't interact with the web. Now we don't have three buckets anymore. What do I do? [laughs]\n\nAnd what if you have some logic? In our theoretical example here, we've got subscriptions with cancellations. What if when that cancellation happens, you need to do a few things? Maybe you need to contact the printer, and you need to...this is all theoretical. This is probably not how the print industry works. Maybe you need to contact the printer to tell them not to print as many. Maybe you need to send an email to the user who had a subscription to let them know that things were canceled. Maybe you also need to notify the marketing team and so on. There could be a whole series of things that need to happen. \n\nAnd maybe you need to tear down some things. For example, you might need to remove access of that user to the web version. There are a lot of things that might happen there. And there's a lot of logic there. And if you put it in your web controller that handles that incoming web request, well, now it's not reusable. If you want to put it in a background job, well, you can't without tearing it out of there and putting it someplace else. Well, that's a problem. But if I put it in the background job, well, now it's only in the background job. And now I can't use it on the web. Well, that's not so good. What can I do?\n\nDAVE: It's almost like the web code, and the background job code are means of accessing the business logic, which should be somewhere else. \n\nMIKE: That's called --\n\nDAVE: Sorry, I didn't mean to run straight ahead in the direction you were pointing so hard, but that's what just happened. [laughs]\n\nMIKE: As Dave put it brilliantly, you're going to have to have a place to put your business logic and that, I think, is a key item. It's what I took from Robert Martin; again, he goes by Uncle Bob. I'm not trying to diminish him. Sometimes uncle is used as a disparaging term to diminish somebody; he calls himself that. [chuckles] But then he says here that maybe your logic ought to be structured, and that ought to be what your application looks like. What does it do? \n\nIn all of the Rails applications, I think I've seen that have scaled in a sane way, they've built...they've figured this out. They've figured out a place to put the business logic. And there's not just one way to do it. There's more than one way to solve this problem. So I'm not going to say that there's a single way. Although I do think that the industry has kind of gone one way versus another. \n\nOne way that has been done by the folks who kind of originated Rails, the Basecamp folks, is they used a lot of concerns which are...if you're not a Rubyist, you can think about it as multiple inheritance. They also call it mixins. It's not quite an interface like you'd see in Java. It's executable code that you can add. They structure those around your database models.\n\nBut then it goes down to the problem that Dave is describing. If your application doesn't really center around database tables, then that doesn't fix your problem, but it is a solution. It is a totally solid solution if you have a very database table-centric application, which is not disparaging of that application either. You can think about what you're doing has a lot of related ideas. Everything you have might want to have comments on it, for example. Then you make every one of your database access classes have the ability to add comments. And you structure it that way where it's oriented around those. \n\nBut in a lot of our applications, it isn't like that. Maybe there are a lot of third-party integrations that really don't have anything to do with your database tables, and in that case, it really needs to be somewhere else. So what if you build a whole system? And so you look, and you say Rails, okay, that's your foyer. That's your entryway. It's your spinning doors. And maybe it's fancy. Maybe it's a really cool entryway with really nice doors. But that's not your building. Your building is what comes beyond that entryway. And that is all of your business logic structure. \n\nThat is a set of reusable classes that can be called from your background jobs, or from your web servers, or from your API that you may have built separately, or from thing X that I'm not thinking of at the moment, can all call into these service objects that provide you a service which is performing that business logic that you can call from any of those places. \n\nSo now your Rails controller calls into those service objects. Your background job calls into those same service objects. And those service objects are put into a beautiful structure that hopefully, you've thought about beforehand, which, of course, none of us do [laughter], and split up into nice, neat business domain, so it's easily understood. So I'm making another proposal here; thoughts? \n\nDamon, Eddy, Ramses, you've seen our code. And as you came into that, you probably maybe having some familiarity with Rails before saw, wow, I've got all of this code that's not in my models, views, or controllers. What is this? Did you have that moment where you saw that, like, wait, what's all this?\n\nEDDY: For me, it was understanding that not everything fits into the app directory neatly, and there are times where you store some of that in the lib directory. And I'm like, wait, that doesn't go through convention. What is this? And then understanding that it was more in-depth than just the traditional or convention of MVC was eye-awakening for me.\n\nMIKE: Yeah. Like, oh, I might have a library of things that are shared, that are part of this standard structure. There are different ways to structure that lib thing. People have different opinions on that, and they can have those opinions. [laughs] But your key idea is fantastic. Ramses or Damon, do you have any thoughts on this?\n\nDAMON: I don't really have any thoughts on it per se. I just think coming into it for the first time, learning it, and looking at it, it can be super overwhelming. But when you start to actually understand this does this, this does that; it makes a lot more sense on where things go and why they should go in the place that they do.\n\nMIKE: Thank you. And hopefully, the people who have gone before you built something...to go back to that blueprint idea if they're building a house, they made it look like a house; it's not a converted church. \n\nDAMON: [laughs]\n\nMIKE: I knew a guy who bought an old church and lived there for a while, [laughs] and it made kind of a weird house. It didn't fit very well. Hopefully, we've built it in such a way that you can look at that and say, oh yeah, this is what this does. I get it. \n\nDAMON: Oh yeah, for sure.\n\nEDDY: Until you run into legacy code. \n\nMIKE: Yeah, and that's a huge point here is that no codebase is perfect. It's built by humans who are figuring things out as we go. And sometimes, we're going to pivot and make different changes, and the code doesn't instantaneously evolve as we do. So we're talking about what things could, in this perfect vision, look like, which means you got to take some time to get it there. [laughs]\n\nAnd maybe you're going to find some things that are awkward. Going back to the refactoring that Ramses did, he found some code that wasn't very resourceful, and he fixed that. But that's the thing, he took some time, and he fixed that. And now it does follow these patterns that we can wrap our minds around. And there's always got to be part of that. We should do a whole podcast on that or two about the importance of refactoring and how you make that work when you also got to deliver things. \n\nI think it works really well to take some fixed portion of your time that is just budgeted. You've got to budget for that and keep that as part of your budget. They call it tech debt for reasons because that financial metaphor works really well. If you don't pay it down, then you're going to pay more in the long term. You got to pay with debt. And if you always have part of that budgeted to take care of those problems, then it doesn't get out of hand.\n\nEDDY: I personally love dabbling into tech debt from Atlas. It works both ways, right? The company or the group, rather, or the team gives the option or the opportunity for someone else who wants to take up the mantle. And it's a win-win. So truly grateful for that.\n\nMIKE: Listen to Eddy's plug here. If you're out there listening, have some people who are not on your development team help with some of your tech debt. There are going to be some hairy problems that you probably won't hand to them, but there are going to be some things that they can do. And it's great because it's not urgent, but it's really important. There's really important work that people can work on that doesn't have to be delivered tomorrow. And it's a great opportunity for people to get familiar with the system and grow their skills without having to be under a strict timeframe, strict deadline. \n\nDave, we've gone around to others. What are your thoughts about this idea of a structure of service objects that ends up becoming the main part of your application? And that's the building rather than just the entryway.\n\nDAVE: I think it's another architecture, and I think it leaves certain questions unanswered. [laughter] For me, the big notion that a centralized service that other things can talk to, the thing I like about it is that it says the presentation layer is kind of immaterial to me, the way you are accessing this business logic entity processing thing. Processing is a strong word and takes us in a certain direction. That's a poor choice. \n\nThe thing that's going to create cash flow for the business, this bit of software, being able to detangle it from the database layer, being able to detangle it from the web presentation and consumption layer, being able to...detangle is the wrong word, detach, decouple. Decouple, there we go; that's the fun word that we like. Being able to decouple it from the service processing queues coming in from the various asynchronous communication. So we've got, for our service-oriented architecture, we've got a distributed network of servers. \n\nA lot of businesses are going to this distributed network because you just can't deal with a quarter million customers on a single server, so you need to distribute it in some way. I think it's a good solution, and I'm not sure I understand yet everywhere that...like a decoupled service from Rails, I'm not sure what questions that architecture leaves unanswered. But my instincts tell me that there are some and that there are probably some parts of that that are painful corners to get into. \n\nYou mentioned this notion of sharing these objects between systems. To just kind of throw Conway's law into the mix, if you're sharing that object with another team, so you have a whole different reporting structure, then those objects are going to be fairly defensive. And one way you might want to do this...so to be clear, what I'm talking about is like a database table or some objects or some document that you have to shuffle around the company. \n\nAnd you got two separate teams writing software to interact with that document, which means you have two bits of interface code. And if one changes, the other one must change, or the change must be compatible. And you certainly can't...well, you might be able to in an emergency, but in general, you can't coordinate a simultaneous deploy to update the versions. \n\nSo that's an architectural decision that you've now kind of taken on. You now, when you change this object, you have to do it in a way that's compatible to the other team until they get around to adapting to it. You can...in Ruby; the obvious solution is, let's put this in a gem. And I think we have this in one of our projects, a couple of our projects. We have these shared models internal, in-house. And the immediate headaches that this buys us if you want to change a model, you have to publish a gem now. And that's a lot more of a pain than just migrating a database table. \n\nBut Conway's law demands it. Conway's wall, yeah, Conway's wall is the right word. So yeah, there's this extra headache that you pick up by doing that. But it does solve a problem. It makes it so that two teams can now interact with this document and make the business go forward the way we want. I'm speaking in very, very abstract terms; I apologize. \n\nThe upshot is, like, yeah, if you separate all this logic off into a service center that is agnostic to the web or to an asynchronous queuing process background job kind of thing, that's just another architectural decision. You've now got a plan that says library instead of civic center or art museum, which can be very similar architectures. But they're going to service specific needs in different ways. The art museum isn't going to have hyper-reinforced subfloors the way the library is going to because books turn out to be surprisingly heavy. They will bend your building if you don't account for that. That's a weird, random example, but yeah.\n\nMIKE: You mentioned this idea of bigger, you know, maybe you need more than one application. Your service can actually be extracted. That's a beautiful thing that happens when you decouple. Like, well, maybe they don't even have to live in the same application, but early on, they probably do. Your services likely live in the same place. But I think you touched on a really important question that doesn't get answered. \n\nSo do I have a few hundred service objects of some kind that my business logic kind of call out, all without any hierarchy, just in one big directory? And you probably say, well, no, there's no organization there. Now I'm making things even worse, well, maybe not worse, but certainly not good. We have to figure out how to organize that stuff.\n\nDAVE: There's a great thing that this architecture leaves. This notion of moving things into a centralized service area, a question that that leaves unanswered is how much of the business problem that our application is solving should not be solved by our team? How much of this should go off to a risk management team? Or how much of this should go off to the accounting team or to a finance team? Or how much of this should go off to...you got to think of the man who manages personnel. \n\nMaybe part of this should actually be managed by a couple of engineers working in the human resources department, and it shouldn't be in our repo, and the data shouldn't be visible to the engineers. These are questions that are completely unanswered, but it's not until you throw it into a problem domain that you realize that, oh, this is unanswered, which is great. It doesn't mean you're forced into one way or another. It just means that the proposed solution doesn't have an answer ready.\n\nMIKE: I think you brought up something profound there, actually. You said all these parts...you put it there, and now you have all these unanswered questions. Well, now you have questions you couldn't ask before. \n\nDAVE: Yes. Ooh, I love that. You've actually upgraded from unasked questions to unanswered questions. I like that. I really, really like that. That's great, thank you.\n\nMIKE: And being able to have those questions is...I would argue that questions are often more important than answers. If somebody has given you all the answers, that is a bad life. I want a life full of interesting questions, [laughter], and the ability to be able to ask those questions and have those questions and have different questions than somebody else has. Being given the opportunity to have questions is a great gift. I'm thinking of Hitchhiker's Guide to the Galaxy. They built a tremendous machine to find the answer to life, the universe, and everything. And the answer they got was totally useless. What was more important was the right question. \n\nDAVE: What was the question? Mm-hmm.\n\nMIKE: That, I think, is what you imply without saying it directly. You did say, \"Well, now you can ask all these questions.\" Yeah, now you can ask all these questions. Once you have decoupled your business logic from your presentation, now you have a bunch of questions as to how you're going to organize this and where should it go, which means that you can answer those questions. You can start asking them and think, well, how do I do this? And that is powerful. Suddenly, you've been given this great gift that you didn't have before because you couldn't, and so your hands were tied. \n\nDAVE: Yeah. I like that. There's a phrase that I got from working as a contractor for years and years, which is, you want to deliver something really, really early because the customer doesn't know what they want until you don't give it to them. \n\nMIKE: [laughs]\n\nDAVE: And that's that same notion of, like, there are all these questions you don't even know to ask until you actually produce something that lets somebody go, \"Oh, that's, yeah, no, that's not what I wanted.\" And the importance is this notion going from an unknown and unasked question to knowing what the questions are is a huge upgrade, is a huge step in the right direction. That was my whole point. That's why I was going wow, a few minutes ago. I was realizing that it seems like a problem, but you've actually been handed a ton of solutions in portentous that you can then track down.\n\nMIKE: Great. So we've talked at some length about typical questions that Rails architecture doesn't answer for you. It doesn't force you to divide your code into resources and divide your things into resources that you think about that way. It encourages it. They'll tell you to do that, but you have to solve that problem yourself. And secondly, it doesn't tell you where your business logic got to go or how you ought to organize that.\n\nThose are some pretty big questions that go unanswered, and this is largely platform agnostic. You're going to have to answer these questions no matter what framework you're in. It's worth thinking about. And if you're not in a position where you can ask those questions, it's probably time to take a look and think, well, what are my problems here? How can I decouple things so that I can maybe start asking some different questions and doing things differently? Maybe in ways that I can't conceive of yet because I can't even see that there might be a question there.\n\nDAVE: This was a lot of fun. Normally, when we get into what does Rails not do, it's usually a chance to get why I hate Rails off my chest. [laughs] And I wanted to go into this one with, no, I don't want to hate on Rails. I want to say what is Rails good at? What is Rails blind to? And this was definitely that. Rails gives you some architectural things. It gives you a solution to the problem of how are we going to make money on the web using a database? It will tie all of that together for you. \n\nIt's not until much later that you can turn around and go, wait a minute, what are the parts that hurt on every Rails project because of the same blind spot getting papered over? That's not a moral failing of Rails; that's just a natural consequence of some of the...it goes back to what I said earlier, the default direction you take two or three steps into will determine which corner of the room you're going to paint yourself into. There are going to be consequences of those early decisions that you make and especially if you keep heading in that direction with every default decision, kind of neat. \n\nMIKE: Any other final words from others on the call?\n\nDAMON: Only that you guys explained this really well, and it's super helpful. So I appreciate it.\n\nMIKE: Fantastic. I'm glad we accomplished something. [laughs] Thank you, Damon. Thank you for joining us this morning. I think we had a great discussion. And hopefully, you've got some nice ideas to chew on and think about how you can better architect your application. See you next time.","content_html":"The topic is the Rails framework. What architectural questions does Rails answer? What architectural questions does Rails not answer? Great topic, whether you're a Rubyist or not!
\n\nTranscript:
\n\nMIKE: Welcome to our podcast. I think we have a name now. I think we're going to call this The Acima Development Podcast. Nice. So welcome to The Acima Development Podcast. I'm Mike. I'll be hosting today. And let's go through and talk with some of the people who are here today. Eddy, do you want to introduce yourself?
\n\nEDDY: Like Mike said, I'm Eddy. I'm an employee here at Acima. I've been here a couple of times, and I'm in the QA department. So I'm super happy to be here.
\n\nMIKE: Great. Dave.
\n\nDAVE: Hello from the software minds. My name is Dave. I've been goofing around in Ruby for, gosh, about 15 years now, holy crap, no, 16, anyway, a long time. And I'm happy to be here.
\n\nMIKE: Ramses.
\n\nRAMSES: Hi, everyone. It's been a couple of weeks since I've been on. I'm Ramses. I've been dabbling with Ruby for a little over a year now.
\n\nMIKE: And Damon.
\n\nDAMON: Hey, everybody. I'm Damon. It's good to be here again for the ADP Podcast. I've been here for about a year and a couple of months now, sort of a freshman in Ruby, so excited to learn everything.
\n\nMIKE: Great. Today we're going to be talking about an interesting topic. This one's been interesting to me for a long time. And the topic is in the Rails framework. This applies not just to Rails. It kind of is a universal topic. Well, we'll be focusing on Rails; it's more universal.
\n\nWhat architectural questions does Rails not answer? What architectural questions does Rails not answer? It does answer some. That's part of why people are very quick at using it and get things up quickly because they don't have to answer so many questions that are kind of obvious. But there's a lot that it doesn't answer. This is universal across frameworks. So I think this is a really good topic, whether you're Rubyist or not.
\n\nAnd I wanted to start today by reading a quote from Robert C. Martin, who goes by Uncle Bob. If you're not familiar with him, change that. He's an icon in the community and talks about architecture on his Clean Code Blog. There's a post from...it looks like September 30th of 2011. And I want to read a couple of paragraphs (Looks like four paragraphs.) right from the beginning of this blog post.
\n\nHe says, "Imagine that you are looking at the blueprints of a building. This document, prepared by an architect, tells you the plans for the building. What do these plans tell you?
\n\nIf the plans you are looking at are for a single-family residence, then you’ll probably see a front entrance, a foyer leading to the living room, and perhaps a dining room. There’ll likely be a kitchen a short distance away, close to the dining room. Perhaps a dinette area next to the kitchen, and probably a family room close to that. As you looked at those plans, there’d be no question that you were looking at a house. The architecture would scream house.
\n\nOr, if you were looking at the architecture of a library, you’d likely see a grand entrance, an area for check-in-out clerks, reading areas, small conference rooms, and gallery after gallery capable of holding bookshelves for all the books in the library. That architecture would scream library.
\n\nSo what does the architecture of your application scream? When you look at the top-level directory structure and the source files in the highest-level package, do they scream: Health Care System, or Accounting System, or Inventory Management System? Or do they scream: Rails, or Spring/Hibernate, or ASP?"
\n\nDAVE: That's a very dangerous question because, to my mind, Rails isn't an architecture; it's a style. It's kind of like going to the Parthenon. And I'm going to get my Greek architecture wrong here. But it's basically looking at this and saying, "Ah, the architecture here is Dorian, or it's Ionian because of the columns with the flutes and the substances and the scallops." To my mind, Rails should be that, when you look at a project, you should go, oh, this is a library that's built in Rails, or oh, this is a house that's built in Rails. But you're absolutely right. Too often, we look at a house, or we look at the architecture and go, yes, this is bricks.
\n\nMIKE: [laughs] Yeah, well said. These are bricks. That's absolutely what this is. And if you're a new developer coming into that project or an experienced developer in that project and you want to think about what's there, looking at a big pile of bricks is probably not very helpful to you.
\n\nDAMON: Definitely not.
\n\nMIKE: I think that's a great introduction to this discussion because we're talking about...and he mentioned three frameworks there deliberately. We're mostly going to be talking about Rails because we're a Rails shop, but this is universal. And frameworks tend to converge. There's converge and evolution where they tend to look like each other after a while. They tend to answer similar architectural questions, and then there are other questions they don't answer.
\n\nAnd the questions they do tend to answer are, in some ways, the easier ones. We'll say, "Oh yeah, we want to have a tiered structure, a layer that talks to the database, a layer that has our business logic, and then a layer that presents things." And we'll call that a model layer, a controller layer, and a view layer, model talking to the data, controller is dealing with your business logic, and then a view layer that's going to present things.
\n\nRails calls itself MVC, and it sort of is, but it blurs those boundaries a little bit, I would argue. I would say that in Rails, what they call the controller and view are really both mostly a presentation layer. And the business logic layer, that actual controller layer, is largely not specified. And I think that that is the big unanswered question that we usually have to answer when we're building a Rails app.
\n\nI'm kind of drawing a line there in the sand. [laughs] This is where I'm going to make a proposal that that's where the boundaries of the framework are. They're a little bit misleading, and they have become kind of the starting point. In a big app, most of your code is probably not going to be in those three buckets; it's going to be in the actual business logic layer, which makes up most of your app. Are those consistent?
\n\nSo, Dave, you've had deep experience with software development, and then all of us have had some experience. I'm particularly interested in what you have to say, Dave, if you've got thoughts about my suggestion there.
\n\nDAVE: I kind of like it. Actually, I think you said something casually revolutionary, which is that most of a large business application doesn't fit into those three boxes; I really, really like that. Rails will give you tiny architectural, I mean, there's a bunch of big architectures, but it'll give you some tiny, you know, like ionic columns are the ones that...sorry for the stupid Greek architecture reference. But the little flutes on the columns are not part of Doric architecture; those are part of Ionian architecture, which meant they came from a different group of people.
\n\nRails will give you a thing, and it's not new to Rails, but they took on this coat and wore it boldly. They'll give you a thing that if you want to talk to an object that came from the database, you go find the class that maps to that table. And you ask the class to find you instances of rows in that table, and you get those rows back. And then, if you want to manipulate a row in the table, you talk to the objects of that class, the instances of that class.
\n\nAnd it's so easy to soak in Rails so deeply that you just think everything works that way, but a lot of projects don't. A lot of projects say, yeah, the objects in this system, the back office stuff, the database, housekeeping is secondary, tertiary. It's like, the most important thing we can do with this is have this object communicate to other objects and produce a viable business result. The database is just a parking lot where we put them and get them.
\n\nRails brings this front end to the fore with that ActiveRecord architecture. And if you try to make all of your models fit into the model directory or even into the model bucket, you're going to have this problem where (And I've actually had this happen.) your application will end up looking like a database. You can actually make a map of your business model by just dumping the database tables, the ERD, the entity relationship diagram, the ERD.
\n\nI've had gigs where I literally walked in and all I did was dump the database structure and print it out on paper in a four-point font and made a poster that was like five feet wide and four feet tall. And people come in and go, "Holy crap, what is that?" And I say, "That's what you've built. And the entire point of this poster was to make you go holy crap." So, you know, this poster has served...I'm getting off on a tangent, as I am one to do.
\n\nBut the point being is that if you take the architecture blindly without thinking about it, you will start laying down these defaults, put the objects in the model directory, that means they map to the database table, that means you find them by searching from the class. And that means you interact with them by interacting with the instances. Those initial default steps are in a particular direction. It just feels like you're just taking a step, but you are taking a step in a specific direction. And if you look far enough ahead, you can see the corner that you're going to wind up painted into.
\n\nMIKE: And I would argue that we do, we get into that corner. We have a hard time conceiving that there might be resources that don't map to a database table. For example, let's say you have a subscription, and you're going to cancel that subscription. And in your database, cancellation is just a single date. So you think, oh, I'm canceling my subscription. Well, that's something that I do on my subscription. And as soon as you've thought that, you've taken a step too far because you're not thinking about resources anymore. You're thinking about your database table.
\n\nDAVE: Right, because it's the user who cancels their subscription.
\n\nMIKE: The user cancels a subscription. Those are three things: there's a user thing, there's a cancellation thing, and there's a subscription thing. So presumably, you have a subscription object, but you might not have a...well, we call them objects. Why not treat that cancellation as a thing, even if it's not a first-class thing? If it doesn't have its own table in the database, so? That doesn't mean that it's not a resource that somebody is interacting with.
\n\nYou're interacting with that cancellation thing. And if you structure your code around this cancellation thing, now you've followed best practices for a RESTful, you know, the REST being the representational state transfer. That's the attempt to use HTTP the way it was designed, hypertext transport protocol the way it was designed, which is to think about resources that you interact with.
\n\nWell, if you think about well, I've got this cancellation resource, and I'm just going to create a cancellation. In Rails, you create a cancellations controller with a create method. It maps directly to that REST idea, and everything just works perfectly. The only thing that's going to veer a little bit from the way you normally think about it is instead of creating a cancellation in the database, well, you probably should have one. A lot of times, there's a sign there that maybe there's an object missing, but you just write that date to your subscriptions table and done. You didn't have to have an ActiveRecord cancellation object in order to have that resource.
\n\nDAVE: So there are some people listening to this right now who are going, "But...but...but...you can do this in Rails. It doesn't prevent you." Yeah, it doesn't. It doesn't. But there are things that are uphill, and then there are things that are very steeply downhill that it's just easy to fall into them. I remember 15 years ago when web sessions were stored in a column on the user record, like, you had your session ID. And there might be a sessions table, or there might just be a cookie ID that you store on a user record, and we can look at that user. And it's a terrible security practice, don't do it that way.
\n\nI remember when the world shifted to RESTful sessions. So when you go to log in, it actually takes you to the session's controller new action. I'm like, no, I don't want to make a new session. I want to log in; logging in is what I'm doing. I don't want to create a new session. And I remember when sessions went to RESTful, and it makes sense in my brain now for sessions to be RESTful. When you log in, you create a session; when you log out, you delete your session. And oftentimes, now those are in a separate sessions table.
\n\nBut when we first got into these, the thing that we got led very strongly to by the hand almost was login is going to be a thing that a user can do, and it will change the nature of that user record. That user record in the database goes from just being a user in the system to a user who is currently logged in, and we can find them, or they can be found by a cookie identifier in a browser. And that was a huge leap. Like, somebody had to come in and think really hard about what Rails wasn't doing for us with this user column and then step back and say, "Oh, we need RESTful sessions."
\n\nAnd I think what you've just described, Mike, this cancellations idea it's the same thing. Like if you just look at the things that are in front of you, you might be tempted to say add column to the subscriptions table, canceled at is a date time, and we're done. We just add a timestamp for when that subscription was canceled. Then there's this whole separate idea of, like, well, let's create a cancellation. Let's edit a cancellation, let's delete a cancellation, let's search for cancellations.
\nAnd to the people that are saying Rails doesn't stop you from doing that, I want to say I agree with you 100%. But Rails doesn't tell you to go that way. Rails doesn't give you any hint that that direction even exists. You have to know it's on the other side of that wall; let's punch straight through and grab it. Does that make sense? Like, that idea is kind of hidden because of the way Rails is very much built around verbs and controller actions and transactions.
And you can build RESTful things out of Rails. Rails makes it very easy to do resources add and that sort of thing. But out of the box, its route get canceled on the subscription. Cancel becomes the verb, and that's not REST which, I mean, might be okay, but it's a decision.
\n\nMIKE: You look at the documentation, and Rails will actually encourage you to build a resource. But until you made that mental leap, it's very easy to fall into that, oh, I'm just going to pack more stuff into this thing. Ramses, I believe you've recently been disentangling one of these with a significant refactoring project.
\n\nRAMSES: Yeah, it's complete now. But it was four or five weeks' worth of refactoring custom REST methods into more resourceful actions.
\n\nMIKE: What was it like when you had that realization? Like, wait, these are all just things.
\n\nRAMSES: Yeah, it's really eye-opening. It's easy to get into the mindset of oh, I can just add a custom REST method into this controller, but it doesn't quite make sense. I think it makes a lot of sense when you get out of the mindset of thinking about the object that you're interacting with has to be in the database, or it has to be a model or something. When you realize it doesn't, it makes it a lot easier to work with, I think.
\n\nMIKE: Once the code had been refactored and you saw it as a bunch of resources rather than a bunch of stuff crammed into one file, how did the code feel to you? What's your vibe? [laughs] How does it feel to you now?
\n\nRAMSES: It's a lot less cluttered rather than everything cram packed into two controllers. I think there are like eight total controllers now, but it's namespaced really greatly, I think, and abstracted out into separate concepts. So it's really easy to digest what's going on.
\n\nMIKE: I love a couple of things you said there. You said easy. [chuckles] Easy is a good thing. If you go into a project and it's hard, that's a sign that something's wrong because it means that somebody has to think about it. It means they'll likely think about a problem. It means we haven't structured it in a way that's easy for people to understand.
\n\nYou also said another word for what it was like before, which is cluttered, which is another word suggesting complexity. When you see a bunch of stuff that's disorganized, chaos, or entropy, disorder, it's hard to wrap your mind around it because there's not a pattern. And if you can get away from that and put things into a consistent pattern, they're easier to think about.
\n\nAnd we've solved a major problem which is allowing ourselves to think about the problem, which is maybe, arguably, that's the most important thing that we solve in code is breaking up the problem into pieces that we can think about so that we can then have them do stuff. That resourceful idea is there. Rails provides it for you. But you got to take advantage of it. So that's an excellent example of something that you might not get without thinking about it.
\n\nAnd this applies not just to a web controller, and we're referring to controllers here in the Rails sense. But like I was saying before, it's a little bit of a stretch on that controller idea, and there's not much business logic there. But it's handling the requests that are coming in from the web and delegating that to where they need to go. Organizing those into resources, I think is hugely useful. But that applies (Dave was talking about a fractal before.) that applies I think throughout the architecture that you want to have this idea of resources so that you can think about a thing.
\n\nLike, I'm going to go interact with my subscriptions, for example. That's a resource. And within those subscriptions, I want to interact with cancellations. So there's a sub thing. It's related things. Maybe you think of it as sort of a tree, and you go through the subscriptions and get over to these cancellations, and cancellations are a thing. Once I've done that, I can think about that cancellation resource. And I might create one. I might delete one, undo the cancellation, or I might update one, and so on. Thinking about things in terms of things that are resources allows you to organize your mind into those patterns and make order out of chaos.
\n\nI've got a pivot here into another huge question that Rails doesn't answer. But I want to make sure everybody here has a chance to speak. Any other thoughts on this particular topic? We've talked a lot about this, organizing, and resources.
\n\nDAVE: This notion of creating order out of chaos, I can't express how revolutionary that idea that you gave of if you just put things in these three bins, you're going to be in trouble. There are certain things, like, Rails, makes it very, very easy to map your application domain, the high-level thing that users interact with all the way to a database. I mean, you can create one route, which creates...scaffolding up the models for it. You can fill in the forms, and you can save database records.
\n\nAnd if your end users are prepared to think in terms of selecting from sets of things from the database, you're going to be able to write an entire Rails app in 15 minutes, and it's the ancient build a blog in 15 minutes concept. If the idea that you have for your application does not fit well into a database, Rails won't stop you from doing it, but it also doesn't pave the way and gild the curbs, and puts nice, safe street lighting in that direction.
\n\nA good example of something that's kind of in both camps...it's like it's painful to get there but also kind of...I don't know. A good example of this is nested sets. They are really, really awkward to build in a database. There's a really clever algorithm for storing just Google nested set lgt rgt, that notion...or lft, rgt, sorry. These are database columns that you store for left and right, and they're the bounds of a subset inside a set. I realize I'm speaking gibberish.
\n\nMy point is that this is a data structure. It lets you build a graph. It's like, Mike runs a team, and on that team, there are these people. And each of these people have people that they can contact that are their friends. So let's find the friends. I've got somebody who's a friend who's on this team who's under a manager, and that manager has another person; let's find their friends. That up to down to relationship is something you can do really well if you have this notion of nested sets in your database.
\n\nBut reducing a nested set from object-oriented space to a database graph is very awkward, very painful, and very difficult, and when you translate that to Rails space, all of that awkward transformation in the database remains. It's really hard to make that go away. And you really hit on this, that if you try to make a database model out of this, you're going to suffer.
\n\nBut if you can find a way to express it in a primary way, it's like, what is the native way to express these collections? Well, I want to do some things. I want to add a person. I want to find people based on this. Can we do this without mapping it all the way into the database? If we can, we're going to have an easy time of it. And Rails doesn't make that easy. It doesn't prevent you from doing it, but it doesn't make it easy.
\n\nAnd there's part of me that says, so what's my point? But that is my point is that when you make a bunch of things very, very easy, you make the things that you don't make easy, the things that you leave undescribed, but they're still possible, by default, and by comparison, those end up looking really hard. It's not something Rails is bad at; it's just something Rails doesn't do for you.
\n\nMIKE: Nor could it, and that's not Rails-specific either. As I was saying before, there's no framework that's going to answer all of your questions that's going to build your app for you. If you did, then you probably would use a no-code solution. And those exist, and they have actual value in the places that people use them. But if you're building something novel, the whole reason that you're building software is to solve a problem that wasn't solvable in another way. And the framework is probably not going to give you everything you need, and that's not a diss on the framework.
\n\nDAVE: Yeah. The architectural blueprint is meant to convey a certain idea about the thing that you are building, and you're supposed to have a look at it and see the salient points. It's not going to tell you where the library should be built. It's not going to tell you what language the book should be in. It's not going to tell you should this library be a public or a private resource. It's not going to give you any of that. It's just going to give you this is what the building is going to look like. And you can put it anywhere, and you can build it how you want. And that's good.
\n\nOoh, now that's a dangerous question. What questions should architecture leave unanswered? It's a subtle difference from what we're doing today. What we're doing today is what architectural things does Rails leave unanswered, which is a kind of a 90-degree question.
\n\nMIKE: Well, I'm going to propose that there's another one that Rails doesn't answer that basically every Rails app is going to need to...every Rails developer is going to have to deal with. And it goes back to something I hinted at before, which is that in Rails, when they say model-view-controller, the models and controllers together, they call them Action Pack. It's really they interact with the web part. What happens if you start having background services? Those don't interact with the web. Now we don't have three buckets anymore. What do I do? [laughs]
\n\nAnd what if you have some logic? In our theoretical example here, we've got subscriptions with cancellations. What if when that cancellation happens, you need to do a few things? Maybe you need to contact the printer, and you need to...this is all theoretical. This is probably not how the print industry works. Maybe you need to contact the printer to tell them not to print as many. Maybe you need to send an email to the user who had a subscription to let them know that things were canceled. Maybe you also need to notify the marketing team and so on. There could be a whole series of things that need to happen.
\n\nAnd maybe you need to tear down some things. For example, you might need to remove access of that user to the web version. There are a lot of things that might happen there. And there's a lot of logic there. And if you put it in your web controller that handles that incoming web request, well, now it's not reusable. If you want to put it in a background job, well, you can't without tearing it out of there and putting it someplace else. Well, that's a problem. But if I put it in the background job, well, now it's only in the background job. And now I can't use it on the web. Well, that's not so good. What can I do?
\n\nDAVE: It's almost like the web code, and the background job code are means of accessing the business logic, which should be somewhere else.
\n\nMIKE: That's called --
\n\nDAVE: Sorry, I didn't mean to run straight ahead in the direction you were pointing so hard, but that's what just happened. [laughs]
\n\nMIKE: As Dave put it brilliantly, you're going to have to have a place to put your business logic and that, I think, is a key item. It's what I took from Robert Martin; again, he goes by Uncle Bob. I'm not trying to diminish him. Sometimes uncle is used as a disparaging term to diminish somebody; he calls himself that. [chuckles] But then he says here that maybe your logic ought to be structured, and that ought to be what your application looks like. What does it do?
\n\nIn all of the Rails applications, I think I've seen that have scaled in a sane way, they've built...they've figured this out. They've figured out a place to put the business logic. And there's not just one way to do it. There's more than one way to solve this problem. So I'm not going to say that there's a single way. Although I do think that the industry has kind of gone one way versus another.
\n\nOne way that has been done by the folks who kind of originated Rails, the Basecamp folks, is they used a lot of concerns which are...if you're not a Rubyist, you can think about it as multiple inheritance. They also call it mixins. It's not quite an interface like you'd see in Java. It's executable code that you can add. They structure those around your database models.
\n\nBut then it goes down to the problem that Dave is describing. If your application doesn't really center around database tables, then that doesn't fix your problem, but it is a solution. It is a totally solid solution if you have a very database table-centric application, which is not disparaging of that application either. You can think about what you're doing has a lot of related ideas. Everything you have might want to have comments on it, for example. Then you make every one of your database access classes have the ability to add comments. And you structure it that way where it's oriented around those.
\n\nBut in a lot of our applications, it isn't like that. Maybe there are a lot of third-party integrations that really don't have anything to do with your database tables, and in that case, it really needs to be somewhere else. So what if you build a whole system? And so you look, and you say Rails, okay, that's your foyer. That's your entryway. It's your spinning doors. And maybe it's fancy. Maybe it's a really cool entryway with really nice doors. But that's not your building. Your building is what comes beyond that entryway. And that is all of your business logic structure.
\n\nThat is a set of reusable classes that can be called from your background jobs, or from your web servers, or from your API that you may have built separately, or from thing X that I'm not thinking of at the moment, can all call into these service objects that provide you a service which is performing that business logic that you can call from any of those places.
\n\nSo now your Rails controller calls into those service objects. Your background job calls into those same service objects. And those service objects are put into a beautiful structure that hopefully, you've thought about beforehand, which, of course, none of us do [laughter], and split up into nice, neat business domain, so it's easily understood. So I'm making another proposal here; thoughts?
\n\nDamon, Eddy, Ramses, you've seen our code. And as you came into that, you probably maybe having some familiarity with Rails before saw, wow, I've got all of this code that's not in my models, views, or controllers. What is this? Did you have that moment where you saw that, like, wait, what's all this?
\n\nEDDY: For me, it was understanding that not everything fits into the app directory neatly, and there are times where you store some of that in the lib directory. And I'm like, wait, that doesn't go through convention. What is this? And then understanding that it was more in-depth than just the traditional or convention of MVC was eye-awakening for me.
\n\nMIKE: Yeah. Like, oh, I might have a library of things that are shared, that are part of this standard structure. There are different ways to structure that lib thing. People have different opinions on that, and they can have those opinions. [laughs] But your key idea is fantastic. Ramses or Damon, do you have any thoughts on this?
\n\nDAMON: I don't really have any thoughts on it per se. I just think coming into it for the first time, learning it, and looking at it, it can be super overwhelming. But when you start to actually understand this does this, this does that; it makes a lot more sense on where things go and why they should go in the place that they do.
\n\nMIKE: Thank you. And hopefully, the people who have gone before you built something...to go back to that blueprint idea if they're building a house, they made it look like a house; it's not a converted church.
\n\nDAMON: [laughs]
\n\nMIKE: I knew a guy who bought an old church and lived there for a while, [laughs] and it made kind of a weird house. It didn't fit very well. Hopefully, we've built it in such a way that you can look at that and say, oh yeah, this is what this does. I get it.
\n\nDAMON: Oh yeah, for sure.
\n\nEDDY: Until you run into legacy code.
\n\nMIKE: Yeah, and that's a huge point here is that no codebase is perfect. It's built by humans who are figuring things out as we go. And sometimes, we're going to pivot and make different changes, and the code doesn't instantaneously evolve as we do. So we're talking about what things could, in this perfect vision, look like, which means you got to take some time to get it there. [laughs]
\n\nAnd maybe you're going to find some things that are awkward. Going back to the refactoring that Ramses did, he found some code that wasn't very resourceful, and he fixed that. But that's the thing, he took some time, and he fixed that. And now it does follow these patterns that we can wrap our minds around. And there's always got to be part of that. We should do a whole podcast on that or two about the importance of refactoring and how you make that work when you also got to deliver things.
\n\nI think it works really well to take some fixed portion of your time that is just budgeted. You've got to budget for that and keep that as part of your budget. They call it tech debt for reasons because that financial metaphor works really well. If you don't pay it down, then you're going to pay more in the long term. You got to pay with debt. And if you always have part of that budgeted to take care of those problems, then it doesn't get out of hand.
\n\nEDDY: I personally love dabbling into tech debt from Atlas. It works both ways, right? The company or the group, rather, or the team gives the option or the opportunity for someone else who wants to take up the mantle. And it's a win-win. So truly grateful for that.
\n\nMIKE: Listen to Eddy's plug here. If you're out there listening, have some people who are not on your development team help with some of your tech debt. There are going to be some hairy problems that you probably won't hand to them, but there are going to be some things that they can do. And it's great because it's not urgent, but it's really important. There's really important work that people can work on that doesn't have to be delivered tomorrow. And it's a great opportunity for people to get familiar with the system and grow their skills without having to be under a strict timeframe, strict deadline.
\n\nDave, we've gone around to others. What are your thoughts about this idea of a structure of service objects that ends up becoming the main part of your application? And that's the building rather than just the entryway.
\n\nDAVE: I think it's another architecture, and I think it leaves certain questions unanswered. [laughter] For me, the big notion that a centralized service that other things can talk to, the thing I like about it is that it says the presentation layer is kind of immaterial to me, the way you are accessing this business logic entity processing thing. Processing is a strong word and takes us in a certain direction. That's a poor choice.
\n\nThe thing that's going to create cash flow for the business, this bit of software, being able to detangle it from the database layer, being able to detangle it from the web presentation and consumption layer, being able to...detangle is the wrong word, detach, decouple. Decouple, there we go; that's the fun word that we like. Being able to decouple it from the service processing queues coming in from the various asynchronous communication. So we've got, for our service-oriented architecture, we've got a distributed network of servers.
\n\nA lot of businesses are going to this distributed network because you just can't deal with a quarter million customers on a single server, so you need to distribute it in some way. I think it's a good solution, and I'm not sure I understand yet everywhere that...like a decoupled service from Rails, I'm not sure what questions that architecture leaves unanswered. But my instincts tell me that there are some and that there are probably some parts of that that are painful corners to get into.
\n\nYou mentioned this notion of sharing these objects between systems. To just kind of throw Conway's law into the mix, if you're sharing that object with another team, so you have a whole different reporting structure, then those objects are going to be fairly defensive. And one way you might want to do this...so to be clear, what I'm talking about is like a database table or some objects or some document that you have to shuffle around the company.
\n\nAnd you got two separate teams writing software to interact with that document, which means you have two bits of interface code. And if one changes, the other one must change, or the change must be compatible. And you certainly can't...well, you might be able to in an emergency, but in general, you can't coordinate a simultaneous deploy to update the versions.
\n\nSo that's an architectural decision that you've now kind of taken on. You now, when you change this object, you have to do it in a way that's compatible to the other team until they get around to adapting to it. You can...in Ruby; the obvious solution is, let's put this in a gem. And I think we have this in one of our projects, a couple of our projects. We have these shared models internal, in-house. And the immediate headaches that this buys us if you want to change a model, you have to publish a gem now. And that's a lot more of a pain than just migrating a database table.
\n\nBut Conway's law demands it. Conway's wall, yeah, Conway's wall is the right word. So yeah, there's this extra headache that you pick up by doing that. But it does solve a problem. It makes it so that two teams can now interact with this document and make the business go forward the way we want. I'm speaking in very, very abstract terms; I apologize.
\n\nThe upshot is, like, yeah, if you separate all this logic off into a service center that is agnostic to the web or to an asynchronous queuing process background job kind of thing, that's just another architectural decision. You've now got a plan that says library instead of civic center or art museum, which can be very similar architectures. But they're going to service specific needs in different ways. The art museum isn't going to have hyper-reinforced subfloors the way the library is going to because books turn out to be surprisingly heavy. They will bend your building if you don't account for that. That's a weird, random example, but yeah.
\n\nMIKE: You mentioned this idea of bigger, you know, maybe you need more than one application. Your service can actually be extracted. That's a beautiful thing that happens when you decouple. Like, well, maybe they don't even have to live in the same application, but early on, they probably do. Your services likely live in the same place. But I think you touched on a really important question that doesn't get answered.
\n\nSo do I have a few hundred service objects of some kind that my business logic kind of call out, all without any hierarchy, just in one big directory? And you probably say, well, no, there's no organization there. Now I'm making things even worse, well, maybe not worse, but certainly not good. We have to figure out how to organize that stuff.
\n\nDAVE: There's a great thing that this architecture leaves. This notion of moving things into a centralized service area, a question that that leaves unanswered is how much of the business problem that our application is solving should not be solved by our team? How much of this should go off to a risk management team? Or how much of this should go off to the accounting team or to a finance team? Or how much of this should go off to...you got to think of the man who manages personnel.
\n\nMaybe part of this should actually be managed by a couple of engineers working in the human resources department, and it shouldn't be in our repo, and the data shouldn't be visible to the engineers. These are questions that are completely unanswered, but it's not until you throw it into a problem domain that you realize that, oh, this is unanswered, which is great. It doesn't mean you're forced into one way or another. It just means that the proposed solution doesn't have an answer ready.
\n\nMIKE: I think you brought up something profound there, actually. You said all these parts...you put it there, and now you have all these unanswered questions. Well, now you have questions you couldn't ask before.
\n\nDAVE: Yes. Ooh, I love that. You've actually upgraded from unasked questions to unanswered questions. I like that. I really, really like that. That's great, thank you.
\n\nMIKE: And being able to have those questions is...I would argue that questions are often more important than answers. If somebody has given you all the answers, that is a bad life. I want a life full of interesting questions, [laughter], and the ability to be able to ask those questions and have those questions and have different questions than somebody else has. Being given the opportunity to have questions is a great gift. I'm thinking of Hitchhiker's Guide to the Galaxy. They built a tremendous machine to find the answer to life, the universe, and everything. And the answer they got was totally useless. What was more important was the right question.
\n\nDAVE: What was the question? Mm-hmm.
\n\nMIKE: That, I think, is what you imply without saying it directly. You did say, "Well, now you can ask all these questions." Yeah, now you can ask all these questions. Once you have decoupled your business logic from your presentation, now you have a bunch of questions as to how you're going to organize this and where should it go, which means that you can answer those questions. You can start asking them and think, well, how do I do this? And that is powerful. Suddenly, you've been given this great gift that you didn't have before because you couldn't, and so your hands were tied.
\n\nDAVE: Yeah. I like that. There's a phrase that I got from working as a contractor for years and years, which is, you want to deliver something really, really early because the customer doesn't know what they want until you don't give it to them.
\n\nMIKE: [laughs]
\n\nDAVE: And that's that same notion of, like, there are all these questions you don't even know to ask until you actually produce something that lets somebody go, "Oh, that's, yeah, no, that's not what I wanted." And the importance is this notion going from an unknown and unasked question to knowing what the questions are is a huge upgrade, is a huge step in the right direction. That was my whole point. That's why I was going wow, a few minutes ago. I was realizing that it seems like a problem, but you've actually been handed a ton of solutions in portentous that you can then track down.
\n\nMIKE: Great. So we've talked at some length about typical questions that Rails architecture doesn't answer for you. It doesn't force you to divide your code into resources and divide your things into resources that you think about that way. It encourages it. They'll tell you to do that, but you have to solve that problem yourself. And secondly, it doesn't tell you where your business logic got to go or how you ought to organize that.
\n\nThose are some pretty big questions that go unanswered, and this is largely platform agnostic. You're going to have to answer these questions no matter what framework you're in. It's worth thinking about. And if you're not in a position where you can ask those questions, it's probably time to take a look and think, well, what are my problems here? How can I decouple things so that I can maybe start asking some different questions and doing things differently? Maybe in ways that I can't conceive of yet because I can't even see that there might be a question there.
\n\nDAVE: This was a lot of fun. Normally, when we get into what does Rails not do, it's usually a chance to get why I hate Rails off my chest. [laughs] And I wanted to go into this one with, no, I don't want to hate on Rails. I want to say what is Rails good at? What is Rails blind to? And this was definitely that. Rails gives you some architectural things. It gives you a solution to the problem of how are we going to make money on the web using a database? It will tie all of that together for you.
\n\nIt's not until much later that you can turn around and go, wait a minute, what are the parts that hurt on every Rails project because of the same blind spot getting papered over? That's not a moral failing of Rails; that's just a natural consequence of some of the...it goes back to what I said earlier, the default direction you take two or three steps into will determine which corner of the room you're going to paint yourself into. There are going to be consequences of those early decisions that you make and especially if you keep heading in that direction with every default decision, kind of neat.
\n\nMIKE: Any other final words from others on the call?
\n\nDAMON: Only that you guys explained this really well, and it's super helpful. So I appreciate it.
\n\nMIKE: Fantastic. I'm glad we accomplished something. [laughs] Thank you, Damon. Thank you for joining us this morning. I think we had a great discussion. And hopefully, you've got some nice ideas to chew on and think about how you can better architect your application. See you next time.
","summary":"The topic is the Rails framework. What architectural questions does Rails answer? What architectural questions does Rails not answer? Great topic, whether you're a Rubyist or not!","date_published":"2022-11-23T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/805bff88-ff28-4a19-99fe-52b3124ba3e5.mp3","mime_type":"audio/mpeg","size_in_bytes":44619045,"duration_in_seconds":2589}]},{"id":"0230198f-f517-4abd-ba34-58d5feb9bd56","title":"Episode 4: What Does a Software Developer Do?","url":"https://acima-development.fireside.fm/4","content_text":"A discussion about what software developers actually do and the skills required to be successful.\n\nTranscript:\n\nMIKE: Welcome to another episode of our podcast that we will hopefully soon have a name for. We're a number of episodes in; you'd think we'd get that covered. But I guess we're focusing on the material. Today we have what I think is a great topic. We're going to be talking about what software developers actually do and what skills are required to be successful as a software developer. I think this is an interesting one. We've got several of us here this morning. Sam, do you want to introduce yourself?\n\nSAM: Yeah. My name is Sam. I've been with Acima for five years, moved into application support about six months ago. Basically, my role is to just identify any issues in production and relay it over to our engineers.\n\nMIKE: This is a good topic to have you on, and Damon, who I'll introduce in a moment because you're wanting to maybe move into engineering, so this is a good topic where to put your focus. Damon, do you want to introduce yourself?\n\nDAMON: Yeah. So my name is Damon. I've been with Acima for about a year and a half, also been in the application support role for about seven months now. And just like Sam said, we basically identify issues, troubleshoot, and then report over to the engineers to try to get those resolved as soon as possible.\n\nMIKE: Right. Thank you. Dave, do you want to introduce yourself?\n\nDAMON: Howdy, howdy. My name is Dave. I'm in the development team over on Atlas. And my job as a software developer and my role on this podcast is to serve as an example of what not to aspire to probably, perhaps, serve as a warning maybe to others when possible.\n\nMIKE: Noted. [laughter] And I'm Mike. I'm also an engineer here at Acima. I've been here for some years. And I've been a software developer for quite a bit longer than that. And I'm excited to talk today. I'll lead into this conversation. \n\nI think that through media, people sometimes get a misleading impression of what a software developer does. They might get an impression we spend all of our days at blackboards writing obscure Greek symbols or perhaps coming up over and over again with the great, new idea that's going to change the world. Maybe they think that we are alone at a computer all of the time with a great deal of caffeine and trying to bang out that next great thing. \n\nAnd there may be a little bit of truth to all of those things. But all of them are, I think, fairly misleading. They don't really capture most of what we spend our time doing. And I also think they don't necessarily capture what are the most important skills that make a person successful as a software developer. And I might start this conversation with some suggestions about what software development actually is. \n\nIf I were to say one thing, and this is something that's fairly different from what happens in school and also from what happens in media, is that software development is, in most cases, a fundamentally social activity. We build software together as a group. That may seem surprising, like, you know, how do you write code together? Well, there are actually a lot of ways you can write code together. There's a common practice in the industry of pair programming where you literally have two people sitting at the same desk. \n\nThere are a lot of other ways to collaborate as well. People plan together. They remotely pair together so somebody who's just kind of watching your screen and chatting with you as you go. There are code reviews. There are discussions that come up about the code. There are probably a number of other collaboration channels that I'm not even thinking of. I do want to point out that software development, software engineering is very much a social phenomenon. And the people who tend to be quite successful are people who work together with other people. \n\nThe second thing I think is important to understand about software development that sometimes people don't understand going in is that nobody knows how to do it. I'm overstating a little bit, but -- [laughter] \n\nSAM: Only a little. \n\nMIKE: Yeah, exactly. [laughs] You're talking about a field that is so vast, that is changing so quickly, day to day.\n\nDAVE: And so young.\n\nMIKE: And so young. \n\nDAVE: There’s a whole group of people in the software development community who vehemently react to people claiming the title software engineer because the next youngest field of engineering study is chemical engineering, and that's 700 years old. \n\nMIKE: [laughs]\n\nDAVE: And they're like, yeah, go learn all the best practices, and then bake on them for half a millennium and then come back and talk to us.\n\nMIKE: And to that point, we're not very good at it yet. I am maybe talking a little bit tongue in cheek but not as much as you might think. There are a lot of things we just haven't figured out very well. The best practices in the industry are still evolving. And none of us really know in great depth what we're doing. There's no set of standards. So we're figuring it out as we go. \n\nI know Google is a verb now referring to a specific brand, but search engine of your choice, which is usually Google, is a primary tool for developers. We spend a lot of time just searching, figuring out how to do something, or we ask somebody, or we read up on how to accomplish something because we don't know how to do it. And that is not a sign that we're doing something wrong. \n\nAcknowledgment that we don't know what we're doing is actually one of the most important things I think it takes to be successful as a software engineer because once you are aware of what your limitations are, you know where to put your effort. You know that developing search skills and the ability to work with ambiguity to be able to operate even though you don't know everything, which is uncomfortable, is a big deal. \n\nI would say there's one other thing that I think is fundamental for software development. And I've said this a number of times over my career to people who are aspiring software developers. And this doesn't just apply to software, but it very much does apply is that writing software is largely an exercise in frustration management. If that sounds scary, it shouldn't. \n\nMy kids...my daughter is learning to play piano, and she tends to be a bit of a perfectionist. And when she makes a mistake, she just has a really hard time with it, and she wants to shut down and cry and say, \"Oh, I made a mistake.\" And I tell her...well, there's a phrase that we say all the time; mistakes are proof that you're trying. And learning to recognize that, learning to know that you're going to be frustrated a lot of the time because that's what it takes to accomplish something new that you don't know how to do. \n\nAnd being okay with that, being able to live with that frustration, knowing that yeah, this is hard; it is beating me down, and I don't know how to solve it, and I'm going to keep banging at it anyway until I figure it out, is a fundamental skill and perhaps the most important skill in being a software developer because we're here to solve problems. Sometimes we think we're here to solve code, but that's really not the answer. We're here to solve problems. \n\nI started out with quite a bit of material there for us to chew on for a bit and discuss. Hopefully, that sparks some discussion. I have other thoughts as well.\n\nDAVE: Oh yeah. I've got five pages of rebuttal, and if I may take the first topic. No, you're bang on, bang bang on. I can't remember the show. It's a meme now. But I want to say the show was Adventure Time, and there's like a dog with glasses. I'm not sure if it's Adventure Time. But the character is this dog who wears glasses, and he's a meme now. If you just search for being bad at something, you will come up with pages, and pages, and pages of this. And it's just him. \n\nIt's a cartoon. And this is like serious life advice. And he says, \"Look, sucking at something is the first step to being sort of good at something.\" And that is absolutely true with software development. You're going to sit down, and you're going to have people on one side of you that are saying, \"Oh, there's a right way to do this. We're going to get this nailed down.\" There are going to be people on the other side of the spectrum that will be like, \"Oh, there are 17 different ways to skin a cat, and you need to know all of them.\" And they're both right; there's usually a best way to do something. \n\nAnd sometimes, the best way to be a great software developer is to spend ten years forgetting stuff so that when somebody shows you a problem, you have forgotten seven ways to solve that. And so you have instincts. You're just like, oh yeah, this is just that, we'll just go do that thing. But when you're starting out, yeah, you're like, okay, if I add this to that, I'm going to get this value. I can make a computer do math. Let's make the computer do math, and then we solve the problem. And that is essential. \n\nI have individual tips and ideas. But I would say the most important thing I think you've said, Mike, is that software development is a social endeavor. It's almost a bait and switch because I definitely got into computers because they were the only rational human beings in my childhood. [laughs] I grew up in a crazy part of the world. And it's like, computers didn't bully me. And if you've ever worked with a computer, you know they're absolutely tyrannical, and they refuse to work. The computer always did what it was told, and I loved that about computers. \n\nAnd it was much, much, much later in life that I realized that wait a minute, having a career in this great big raft of monkeys called humankind, boy, yeah, everything is a social endeavor. If you want to go off and solve a math problem, you can do that in your own time. But if you want to have a career, people are more important. They're always going to be more important. I learned that way late in my career, and it definitely influenced the trajectory of my career.\n\nMIKE: If I could add on to a little bit of what you said there, you talked about going and solving math problems. I read an article I don't remember exactly where it was sometime in the last week talking about Albert Einstein, who is the kind of the canonical icon of the myth the lone genius that went off in a corner and came out with modern physics. He was working at a university with other physicists, and he wasn't even the first one to derive some of his equations. The math he used was based on what other people were working on around him. \n\nBasically, nothing that he came up with was as radical as he's often credited for but was largely a group effort. Now, that's not to diminish the fact that he did have novel ideas, and he was able to make a leap that others, his peers, didn't make. But, and this is vitally important, he could never have made those leaps if he wasn't surrounded by that network of peers who brought him to that point where he could make the leap, brought him to that precipice where you can jump across the other side.\n\nDAVE: Yeah. You can't integrate five different people's ideas if you don't go hang out with five other people.\n\nMIKE: Absolutely. Absolutely.\n\nDAMON: I think that makes a lot of sense. For you guys personally, do you feel like you guys have evolved a lot more whenever you started working with a team and became more team-involved?\n\nMIKE: Myself? Absolutely. I was somebody who did coding by myself as a kid back in junior...well, actually, elementary school, I did a little bit. I didn't have a computer at the time. That was in the days before everybody had a computer before they had a computer in their pockets. But I did a little bit when I was quite young, and then in junior high, we had a computer, and I wrote BASIC programs in the BASIC computer language. And it was fun. I loved it. I was all alone. I had a manual that I'd pull out examples from and then try to tinker with them. \n\nAnd then, in school, I largely worked alone as well. And then, in a career, suddenly, it was all with other people all day. And the amount of progress I was able to make while collaborating with other people was remarkable. And it also changed the character of my work. One thing that you do when you're learning typically is you start from scratch. You build everything from scratch because they want you to learn the fundamentals. But professionally, it'd be really foolish to build everything from scratch. \n\nThere are many decades of computing that have happened, and people have built code that is open source or has a dedicated library within the company you're working on. There is other code that's been written that you can use. And if you're doing everything yourself, you're doing it wrong in many, many ways. That's another very important thing that we should learn about software development is that it's mostly about plugging together components that other people have written because the community together builds things that are really good, and then we use those. \n\nThe novel things that we do is we take those pieces, those components, and put them together to make something happen that we want to happen. But most of the work has already been done. For example, most of us work in high-level languages, and we don't write assembly code for device drivers; there are people who do. But most of us are writing in higher level languages that are resting on interpreters and compilers all the way down that other people have written, and we probably will never modify. So it's using other people's work that we use all the time, and learning that was an important thing to me. \n\nDAVE: Along the same lines, I remember my first full-time programming job; they left me alone in the corner of a basement. And I just cranked out code, and it was exactly like you would think, you know, just had the lights turned out and had my monitor in dark mode and all that stuff. \n\nMIKE: [laughs]\n\nDAVE: Yeah, I would write software the way I had always done it as a kid. I would spend hours, and hours, and hours typing code before I ever hit the compile button. And I left that job after a year and a half. And I went to a video game company, which I thought was my dream job. It turned out to be a nightmare job, but for a while, it was a dream job. \n\nAnd I remember sitting down with another programmer who was a senior at the time, and I said, \"Hey, can you help me with this problem?\" He said, \"Sure.\" And I'd been working on it all morning. And he came over, and he sat down, and he was looking over this. And there were obvious typos in my code. And he's like, \"Have you compiled this?\" And I'm like, \"Oh, no, I'm not ready yet.\" And he's like, \"Dude, yeah, no, stop. Make this compile right now. Stop what you're doing and make this compile.\" \n\nAnd so we spent two minutes fixing typos, and we got it to compile, and it didn't work. We were ready to make the next piece of it work. But I was ready to dive into another two hours of writing stuff, grinding stuff out by hand. The point was that I had been writing all this stuff just out of my head [inaudible 14:33] And this guy was just like, no, we need to make this work, and then make the next thing work, and make the next thing work. And that was something that I did not get until I sat down with another human being who was a programmer who was familiar with the craft. \n\nAnd I remember my compiler when it failed, I had tied in this little sound, this little funny, you know, oh, [vocalization] kind of thing, and it played this long sound. And we hit compile, and it didn't work. And my computer made this big, long noise, and the guy that was sitting next to me in a blink of an eye, he figured out the only way you're playing that long of a song on a failed compile is because you're only hearing the sound twice a day because you're only compiling your code twice a day. \n\nHe heard that sound, and he's like, \"Oh yeah, yeah, that's got to go.\" Just immediately, \"That's got to go.\" And I'm like, \"Oh, really?\" And he just says, \"Yeah, you need to be having failed compiles 20 times an hour.\" And I'm like, oooh, I mean, like, I was genuinely shocked at that, something I couldn't learn from a book. I had to learn that from another human. I mean, I could have if somebody had written down compile your code five times in a row. But I'm like, but why? I had to be next to this person to see that.\n\nMIKE: Reminds me. My son was modding Minecraft. And he'd written a tremendously large function to do something, and he went on to say, \"Can you help me with this? It's not working. It's not compiling.\" And I looked at it. And all the indentation was mismatched. And it was just formatting. The formatting was really bad. And usually, that sounds like a nitpicky thing, but I said, \"Honestly, I can't help you with this because the formatting is so inconsistent that I can't tell what's going on just by looking at it,\" because he'd been writing a lot and writing inconsistently. \n\nAnd I said, \"Please fix the formatting. I'm not trying to be nitpicky. I'm not picking on you. I literally can't help you because I can't understand this because it is visually so distracting.\" So he went away for an hour or two and worked on it. And he came back to me with kind of his tail between his legs and said, \"Yeah, it works now.\"\n\nDAVE: [laughs] I cleaned it up, and I made it work while I was doing it.\n\nMIKE: Just fixing the formatting made him aware that there were some mismatched curly braces somewhere. And he hadn't even deliberately fixed something. But just in the act of making it look good, the code started working. That kind of thing happens in a social environment.\n\nDAVE: Absolutely. There's this magic aha moment as well that plays right into what we're talking about being a social activity and what you just said about cleaning up the indentation. A lot of us get the impression that source code is how you talk to a computer, and it's not. Computers don't speak source code; they speak ones and zeros. They speak binary operators. And the compiler takes your source code and turns it into these ones and zeros, which means we don't talk to computers with source code. Well, then, who are we talking to with source code? Other people. \n\nWe write our programs in a language that other people, other humans, can understand. There's an ancient quote from the early days of agile back when it was called XP before Windows XP existed and took that trademark. Martin Fowler said, \"Any idiot can write code a computer can understand, but good programmers write code that other humans can understand.\" There's a profound epiphany that I love getting into that somebody said. When you are writing software, you are writing for other humans. \n\nSo if you write something and you start moving it around, and you line things up because it's funny to make the letters line up and da-da-da, and you make a picture in the code...and you're doodling a picture, but you're not explaining what you're trying to do with your program. You might think that's cool. You might think that's cute. Somebody comes along and goes, \"I can't read this.\" And you suddenly realize that, or maybe you don't realize this, but hopefully, you realize that, oh, I failed at source code. The whole point of the source code was for another human to be able to read it. \n\nReal early advice that I love to give people is that writing readable source code is a bit like being a jerk. You don't get to decide it. You're like, \"Well, I'm not a jerk.\" No, you don't get to decide that; we're all going to decide that about you. And readable code is the same way. If you take your code and you break it up perfectly and you split the modules up, and you dry it up...DRY is don't repeat yourself. \n\nSo everything goes into one specific place, and it's all perfectly correct according to this scheme in your head that nobody else knows but you. And it's beautiful, and it's perfect. And then somebody comes along and says, \"Wow, this is really hard to read.\" Guess what? Your code is hard to read. You don't get to decide. It might have been fun to write. It might have been satisfying to write. But it's not actually readable, and you should change it.\n\nMIKE: And that person probably has some important lessons for you to learn. Sometimes we get caught up in some technique that we think is cool. To your point, that isn't what makes code legible or useful. A lot of times...there's some instinct that you were talking about before and learning, well, what's easy to understand? Which may be different than what's the popular technique at the moment or that you read about last week in some blog somewhere.\n\nDAMON: It's very interesting, actually, for someone in application support trying to go over into a software developer or engineer role just to know that not everybody knows everything, even though they might think everything is all perfect. Someone can come over and just be like, \"Hey, I don't really understand what you're doing here.\" And they can just change it and teach you something. There's always something to learn.\n¬\nSAM: Yeah, it sounds like being a team player greatly benefits. But my question is, are there people that prefer to work alone? And if so, does that benefit anything at all?\n\nDAVE: I have a pretty strong opinion about this. The short answer is yes and yes. As much as I strongly agree that software is a social thing, there are times in this industry when...let me back up and let me throw one wrinkle into this, a tiny little detail that I'm keeping in my head. Telepathy doesn't work, so let me use my words here. I have said this in the past multiple times, the best programmers I've ever worked with have almost universally been people who have degrees in a science field other than computers, so like math majors, not necessarily science majors, linguists, people with degrees in biology. \n\nAnd the best programmer I ever worked with had a Ph.D. in geology, and specifically, he studied earthquakes. Not surprisingly, he and I worked at a company that dealt with vibration control. We were all about analyzing shock waves, and ripples, and sine waves, and standing waves, and reflections, and that sort of thing. And he knew that stuff cold. And every once in a while...I remember there was a meeting we had where he was struggling with a problem. And he said, \"Yeah, there's this ticking sound coming out of the machine because every 256 cycles, we reset this thing.\" \n\nAnd I drew a graph on his whiteboard, and I said, \"So you're saying this.\" And then, I drew a joint in the graph where the thing reset. He's like, \"Yes, that's exactly what it's doing.\" And I said, \"Cool. Could you make it do this?\" And I redrew the graph, but I drew a smooth curve so that it wasn't resetting at the zero point. It was starting off of zero and at the slope that it came out of the previous batch. And his jaw hit his chest, and he's like, \"Holy crap, that would work. Get out of my office. I need to think about something.\" That was literally what he told me was \"Go away.\" \n\nAnd I didn't hear from him for three days. I worked like 12 feet away, like, two doors down from him, in a tiny, little office. I didn't see him for three days. Three days later, he comes in, and he's got this yellow legal pad. And all the pages are like standing up and frayed because they've all been written on in pen, like, this whole legal pad was used, and he's waving it like a madman. And he's like, \"This, this, check this out. Dave, you got to check this out, this.\" And I'm like, \"What is this?\" And he says, \"This is the mathematical proof of the drawing that you drew on my whiteboard. It will work.\" \n\nHe had spent three days in his office in complete silence, trying to work out the mathematical proof before he committed six months of his life to writing the software. Because the thing that I had drawn was very simple to say but much harder to do, and he needed to prove that it could be done. And he needed absolute silence and unbroken concentration to get into the state of flow that he needed for that deep, deep level of work. So yes, absolutely, to your question. \n\nThere are times when software engineering is this highly...it's a very wide social subject. We want five people in the room. We want to do mob programming. We want everybody talking. We want all the ideas coming out loud of our mouths. It's a noisy room. And we all want to collectively make the best decision that we can. And that's a fun way to program, and it's great for certain types of problems. \n\nBut there are also times when yeah, I just want to sneak off to a conference room, and I want to get rid of all the external sounds because I want those parts of my brain that are listening and talking to other people I want them to spin down and release their CPU cycles to the part of my brain that solves problems so that I can get into really, really deep work. So the answer is yes, you do both. And sometimes you don't get to do the one you want to do. But sometimes you get to pick, and that's a good day when you get to do the one that you really want to do that day.\n\nMIKE: We often organize our time so that the socializing is in a certain part of the day, and then the focus time is in another part of the day so that we have a long uninterrupted stretch to think deeply about something. Tricky problems require deep concentration. And then, once you come out of that, you might go back to the socializing part again. They're both necessary. You could have somebody who's just always doing the deep thinking and working on it. And what you'll end up with is very idiosyncratic code. You'll end up with something that really reflects that person. \n\nAnd we all have our idiosyncrasies, but we're not generally looking for a piece of unusual artwork to come from our work. Again, we're here to solve problems. And, in general, you want your solution to be boring. I don't know if that sounds harsh or dull; it's not. Because a boring thing can be a thing of great beauty. You want a bridge to be something you don't think about at all and 200 years later to still be something you're not thinking about at all because it just works. \n\nAnd it may have aspects of that bridge that you find quite beautiful, structural members that by their nature are just beautiful things. And software does have those things of great beauty. You don't want it to be too quirky, generally. Those quirky things might not hold up the way a very boring, predictable, hey, that just works solution would do. \n\nDAVE: There's a fun thing...and you can do this in earlier Ruby. Something has changed. I know you can't do this in Ruby 3. I think it doesn't work in Ruby 2.7. As of 2.3 or 2.4, it still worked, as I recall. But this still works in C++ and languages that are all about bitwise stuff. But it is possible to swap two integers in three operations with no temporary variable. \n\nIf you know a little bit of programming, you know that the way you swap two numbers is you copy one to a little temporary buffer then you take the other number and put it where the first one was. Now you've lost the first number; that's why you had to put it in a temporary buffer. And then you put the temporary number into the other number's place, and you've now swapped their place. You can take A XOR equals B XOR equals A XOR equals B, and that will swap A and B in place. \n\nIf you go learn the rules for how XOR works, about how like if one bit is set, the other one is off, then it turns the bit on. If both bits are on or both bits are off, it turns the bit off. There's this whole algebra for how XOR works that you end up with one number holding itself plus the inverse shadow XOR of the other number, and you can get it back. And it works. It works. And it's super clever. And I carried it around for years, and years, and years, and years. And I would use that. \n\nAnytime I wrote the swap function, I would use this method because it would make people think I was so clever. And I liked getting patted on the head and told that I was such a brilliant boy. And then somebody who really knew how XOR worked...and I had worked it out, like, I could explain to you how this algorithm works. Of course, if I'm going to be clever, I want to prove that I'm clever. \n\nAnd just a very senior hacker walked in, and he said, \"What happens if you tried to swap a number with itself?\" And if you XOR any number with itself, it shorts out. You get zero, all zeros, and the number is lost. So if you try to swap a number with itself, it sets it to zero, and my algorithm is now stupid. And the whole point of doing this swap thing is so that you can only do it in three operations, so you don't have to...well, now I have to do an if test to see if they're the same number. \n\nAnd if you try to swap two different copies of the same number, it will work. It's when you try to swap a number with like you say, swap X with X, and they're pointing at the same location in memory, then what you were using for storage was the sideband XOR data in the number itself. You lose that, and it zeros out. And that was the day that I really finally learned that don't do clever stuff in production; do the boring thing. It wasn't 1988. We weren't paying $20 for that extra byte of RAM to put the number in that we were swapping. We could afford it. And that's even more true today. Well, it isn't. \n\nEverything old is new again because as soon as you say, oh, every computer has four gigabytes of clock or gigahertz of clock and 32 gigs of RAM, as soon as you say that, somebody will come along and say, \"Hey, can you help me with this Arduino project?\" Five years ago, ten years ago, Arduinos didn't have very much RAM on them. PIC chips back then you could get in...15 years ago, you could buy them with 64 bytes of RAM on them. And so we had to pull out the old books from the 1970s of how do I make this run on a program with no memory or on hardware with no memory? And that's coming around now. \n\nLike, the big push in Ruby is to make mruby work, which is mobile Ruby, and they're trying to make it so that it will fit in an Arduino or on a Raspberry Pi. And the full Ruby will fit on a full-sized Raspberry Pi. But if you've looked at the latest round of Raspberry Pis, it's a four-gigahertz machine with gigabytes of RAM. It's a full computer now. The Ruby didn't shrink down to meet it. The computer swelled up to be able to lift it. The point is, don't be clever. [laughs]\n\nIf you're going to make a trade-off, ooh, I just realized there's a better way to phrase this trade-off that everything is a trade-off. Never ever trade off something in exchange...never trade off something good...never give away something good in your code in exchange for getting to think you're clever or getting to show people that you're clever. Because they're going to come along, and they're going to see your code, and they're going to say, \"How much did we pay for you to show me this? Because that holds no value to me.\" \n\nSo I've got a question for Damon and Sam. So you guys are working in a software development adjacent field which, by the way, is a fantastic career path. There's a great book by Cal Newport called So Good They Can't Ignore You. And he basically tells people, if you want to go somewhere and you can't get there, like, you know, it's the age-old thing, right? How do you get five years of experience at a job where every job requires five years of experience? And how do you break into that? And the short answer is you get a job adjacent to the job you want. You go into customer support. A lot of people got into programming through customer support.\n\nI went in and worked at a QA department. And I worked there for one week, and I submitted a bug report where I told the person that wrote the thing, \"Looking at your Windows program, I strongly suspect you're using the Borland C++ compiler because...\" I didn't say why. But basically, there was a tiny little graphical flourish on every Windows window that was a little bit different than the standard Windows thing. And that meant that it was this brand of compiler. And I used that compiler, which is why I recognized that flourish. And there's a really common bug because there was a default setting on the compiler that was dumb. \n\nAnd so when I submitted the report, I was able to say the software is doing this. \"At a guess, I'm guessing you're using the Borland C++ compiler. Go into your settings and change this, and that will fix the problem.\" And I got a phone call the next day saying, \"Why don't you come over and talk to the programming department?\" Literally, whoever that report got to, they were like, \"Yes, I am using Borland. And holy crap, I do have that setting set.\" How did he know this? Bring him in here. I want to talk to him. So you work on your chops, work on your development, and then go into something adjacent. \n\nI just screwed up because I was going to ask you a question then I ended up starting telling a story again; I apologize. [laughter] I'll try to do better. My question for you two, and then I'm going to shut up and actually listen and let you answer, is, from where you sit, what does a software development career look like? And that might be from here to starting at your software development; what does that look like? \n\nHow are you getting ready for this? Are you getting ready for this? Is this something you want to dip a toe in? Or are you locked in and like, no, this is my life, you know, this is my destiny; I'm going to get there? How are you guys looking at software development from where you're at?\n\nDAMON: I'm ready to just dive into it. It's been something that I've been interested in, but I never took the initiative to learn until...I didn't feel like I was ever going to be capable of doing it, honestly just because it looks a little bit more challenging than maybe it actually is. I don't know; my brain works kind of weird. But, like you were just saying, I was in basically a customer service role. I was in processing for, I'm going to say like, five months, maybe. \n\nAnd then I decided I didn't want to be in processing anymore because I had a little bit more to offer, not really sure what it was. But I applied for the operations role, and I got hired basically after a week and a half of interviews and stuff like that. I worked in ops for one day, and basically, they were like, \"Hey, we looked at your resume. And talking to you, we feel like you're going to be really bored here.\" I think this was when Ryan, before he left and then he came and got me with Alicia, and they were like, \"Hey, we have better opportunities for you.\" \n\nWith that being said, it looks promising for me. I just feel like it's something that I've always wanted to do. But like I said, I just never had the opportunity, the chance, never been given a shot until now.\n\nMIKE: Imposter Syndrome biting you. It's a plague.\n\nDAVE: And it never goes away. It never goes away. I blew an estimate...Mike can confirm this. We had an integration where there was a wrinkle to it. It was a two-week integration. And I estimated, oh yeah, this will take about two weeks. And then they said, \"Oh, but you can only test it in production.\" And I'm like, \"Oh, okay, make it four weeks.\" It took me what? Seven months, six months? I'm terrified to count up the actual total. And that was this year. \n\nI started this last fall and finished in March. Like last month, we put the final bow on this. And I was hanging my head thinking, man, they're going to fire me because I do not know how to program. And that impostor syndrome will haunt you. It never...well, hang on. Let me rephrase. It will try to haunt you for your entire career, and it will sell you a lie. And here's the lie; keep quiet, keep your head down. Don't try for the opportunity right now. Just go learn something more, and eventually, you'll be good enough to get it. That is a lie. You will feel like that your whole life. \n\nI feel like that today. I came out of blowing that estimate thinking, oh my gosh, I'm a terrible programmer. I'm never going to be a good developer. And meanwhile, I'm jumping into skills clinic with new people and mentoring and teaching, and everyone's telling me, \"This is great. This is a lot of fun. I love working with you.\" And I'm like, yeah, but I'm so bad at estimates. I had no idea this was going to bite us in the butt this hard. \n\nIronically, once we sat down with the customer and said, \"This is not going to work; you have to make this work for us,\" we finished up in about three more weeks. So, you know, we got that thing fixed. By the way, that's literally my imposter syndrome saying I need to speak in my defense here. I'm blowing that estimate because I feel so guilty about it. And that will haunt you. So get comfortable now with reaching for the golden ring when you have the chance for it. \n\nThe best use of surplus privilege is finding invisible doors and opening them for other people. But never ever forget that the use of your existing amount of privilege is if you see the golden ring, reach for it. If you see a whole bunch of golden rings around the carousel, get on the carousel. If they'll let you on, get on. Because you're going to tell yourself, oh, I don't deserve to be. And there'll be gatekeepers who will say, \"You don't deserve.\" And if you can sneak onto the carousel, do it. And if you can grab for that ring, grab for it. \n\nAnd there will be times when you're going to be like, oh man, I got this great opportunity, and I so do not deserve this. I better grow up fast if I'm going to fill these boots. And it will make for very, very happy memories when you look back and realize I did fill those boots. It turns out this entire time, I absolutely was good enough to get on that carousel and grab that ring. Never negotiate against yourself. I guess that's the summary on that.\n\nMIKE: Well put. Sam, how do you see software development?\n\nSAM: Well, I'm pretty much in the same boat as Damon. I was pretty much in a customer service role for about three years, and I told myself that I wanted to do something else. I actually told myself two years into the company working customer support was just hard; I think what you guys were saying imposter syndrome. And then, finally, I just reached a point where like, I got to do this. I got to get out of my comfort zone. So I ended up taking up a position with operations. I did that for about seven months. \n\nAnd then, like Damon, I was approached by Alicia. And they said, \"Hey, we think you'd be a good role for this position in application support.\" So I decided to take it. And right when I got into this role, this is where I was opened to seeing operations on a different...and engineering, I haven't really looked a lot into it, but yeah, I would definitely want to learn more about it. \n\nMIKE: I'm going to agree with Dave here that, you know, take the opportunity. If you got that opportunity, take advantage of it. And to those of you who are listening, there are a lot of opportunities in software development. And it may be that you keep running into walls, and you feel like, man, I can't do this. And I think Dave gave fantastic advice. Get close to it. Get close to that role and keep doing work and take every opportunity that you can to do some of that software development work. \n\nAnd this applies outside of software development too. If you want to be an astronomer, go get a janitorial job at the observatory, [laughs] whatever it is, get close to it. And there will be opportunities. And if you keep working at it, you'll get better. And you'll be surprised at how much everybody else around you is just figuring out as they go too.\n\nDAMON: Yeah, that's awesome. Thanks, guys.\n\nMIKE: We've talked a lot about what software development is actually made of and what skills are involved, and the importance of recognizing our fallibility that we all have, allowing us to grow and change. I think we hit on some really great points. We're reaching the end of the time that I think we had scheduled for this. So I'm going to ask, are there any final thoughts, things that have been on your mind you just want to say as we've been talking?\n\nSAM: No. I think I came here just expecting to listen, and I've learned a lot here. So, yeah, thank you for having me. This is definitely empowering.\n\nDAMON: I think for me, personally, this was a really good one because we do plan on transitioning here into an engineering role soon. So I was like, oh, this is perfect. I need to listen here to learn about the struggles that you might go through or you will go through and how to go about those. And teamwork is very essential. This was helpful.\n\nDAVE: Sam and Damon, Acima is the best company I've ever worked at for having a pipeline and an investment in new programmers and turning them into experienced programmers. Hang out, come join a podcast, get close to the programming. That actually was a genius move you guys pulled here today. You absolutely have every right to be here. You're not imposters on the show today. \n\nAlso, come hit up the Atlas team, where we're working on the website that the merchants log into. There are people on that team that will say, \"Oh, you've got an hour free? Come sit with me, and we'll write some code together.\" And you'll probably just watch and learn for most of the time. \n\nThere are skill clinics. And this is less valuable for people listening to the podcast, except I want other companies and the people at other companies to know that this exists, and you can do this at your shop as well. Put on a skills clinic every day if you can afford to, and if you can't afford it, make the affordance for it. And have tickets in your backlog that are marked as starter that you can have...we cut this food up nice and tiny so that somebody with a small appetite can tuck into it and close it out safely without having to touch the guts of the whole machine. So yeah, get close to it.\n\nSam and Damon, the next steps for you go find developers on other teams and say, \"Hey, can I come sit with you and learn and just watch you type and point out your typos?\" And that's a much more valuable pair programming offer than you think it might be. It's not a complete one-way street; it is you actually providing value. Yeah, find the value you can provide and provide it, and that will be your next step forward.\n\nMIKE: I would add on to what you're saying there, Dave, to those people at companies that could be doing this that just say, \"Well, we can't afford this. We can't afford to invest in the growth of our employees.\" I would flip that. I would say you can't afford not to. There is so much --\n\nDAVE: What's the saying? What if we train them and they leave? And then the counterargument is, what if we don't train them and they stay?\n\nMIKE: It's wildly expensive to be in that situation, so is not training them, and they leave. There's no good scenario where you don't help people out that just stays that way because, really, it's not going to stay that way. You're not going to have the culture, and the end product, the software that you really want unless you've built an environment that is conducive to building good software. The cost is going to be paid whether or not you see it. \n\nIf you have under-experienced developers who have not had a lot of opportunity to grow their skills, then you're paying the cost of that software that isn't what it could be and paying the tremendous cost of losing good people. Take the time. And if you're out there, take the opportunities that are there. Make them at your company. It can make a tremendous difference, not just to you personally but to the organization you're working. \n\nThank you, everybody. This was a great session. I look forward to talking to you next time.","content_html":"A discussion about what software developers actually do and the skills required to be successful.
\n\nTranscript:
\n\nMIKE: Welcome to another episode of our podcast that we will hopefully soon have a name for. We're a number of episodes in; you'd think we'd get that covered. But I guess we're focusing on the material. Today we have what I think is a great topic. We're going to be talking about what software developers actually do and what skills are required to be successful as a software developer. I think this is an interesting one. We've got several of us here this morning. Sam, do you want to introduce yourself?
\n\nSAM: Yeah. My name is Sam. I've been with Acima for five years, moved into application support about six months ago. Basically, my role is to just identify any issues in production and relay it over to our engineers.
\n\nMIKE: This is a good topic to have you on, and Damon, who I'll introduce in a moment because you're wanting to maybe move into engineering, so this is a good topic where to put your focus. Damon, do you want to introduce yourself?
\n\nDAMON: Yeah. So my name is Damon. I've been with Acima for about a year and a half, also been in the application support role for about seven months now. And just like Sam said, we basically identify issues, troubleshoot, and then report over to the engineers to try to get those resolved as soon as possible.
\n\nMIKE: Right. Thank you. Dave, do you want to introduce yourself?
\n\nDAMON: Howdy, howdy. My name is Dave. I'm in the development team over on Atlas. And my job as a software developer and my role on this podcast is to serve as an example of what not to aspire to probably, perhaps, serve as a warning maybe to others when possible.
\n\nMIKE: Noted. [laughter] And I'm Mike. I'm also an engineer here at Acima. I've been here for some years. And I've been a software developer for quite a bit longer than that. And I'm excited to talk today. I'll lead into this conversation.
\n\nI think that through media, people sometimes get a misleading impression of what a software developer does. They might get an impression we spend all of our days at blackboards writing obscure Greek symbols or perhaps coming up over and over again with the great, new idea that's going to change the world. Maybe they think that we are alone at a computer all of the time with a great deal of caffeine and trying to bang out that next great thing.
\n\nAnd there may be a little bit of truth to all of those things. But all of them are, I think, fairly misleading. They don't really capture most of what we spend our time doing. And I also think they don't necessarily capture what are the most important skills that make a person successful as a software developer. And I might start this conversation with some suggestions about what software development actually is.
\n\nIf I were to say one thing, and this is something that's fairly different from what happens in school and also from what happens in media, is that software development is, in most cases, a fundamentally social activity. We build software together as a group. That may seem surprising, like, you know, how do you write code together? Well, there are actually a lot of ways you can write code together. There's a common practice in the industry of pair programming where you literally have two people sitting at the same desk.
\n\nThere are a lot of other ways to collaborate as well. People plan together. They remotely pair together so somebody who's just kind of watching your screen and chatting with you as you go. There are code reviews. There are discussions that come up about the code. There are probably a number of other collaboration channels that I'm not even thinking of. I do want to point out that software development, software engineering is very much a social phenomenon. And the people who tend to be quite successful are people who work together with other people.
\n\nThe second thing I think is important to understand about software development that sometimes people don't understand going in is that nobody knows how to do it. I'm overstating a little bit, but -- [laughter]
\n\nSAM: Only a little.
\n\nMIKE: Yeah, exactly. [laughs] You're talking about a field that is so vast, that is changing so quickly, day to day.
\n\nDAVE: And so young.
\n\nMIKE: And so young.
\n\nDAVE: There’s a whole group of people in the software development community who vehemently react to people claiming the title software engineer because the next youngest field of engineering study is chemical engineering, and that's 700 years old.
\n\nMIKE: [laughs]
\n\nDAVE: And they're like, yeah, go learn all the best practices, and then bake on them for half a millennium and then come back and talk to us.
\n\nMIKE: And to that point, we're not very good at it yet. I am maybe talking a little bit tongue in cheek but not as much as you might think. There are a lot of things we just haven't figured out very well. The best practices in the industry are still evolving. And none of us really know in great depth what we're doing. There's no set of standards. So we're figuring it out as we go.
\n\nI know Google is a verb now referring to a specific brand, but search engine of your choice, which is usually Google, is a primary tool for developers. We spend a lot of time just searching, figuring out how to do something, or we ask somebody, or we read up on how to accomplish something because we don't know how to do it. And that is not a sign that we're doing something wrong.
\n\nAcknowledgment that we don't know what we're doing is actually one of the most important things I think it takes to be successful as a software engineer because once you are aware of what your limitations are, you know where to put your effort. You know that developing search skills and the ability to work with ambiguity to be able to operate even though you don't know everything, which is uncomfortable, is a big deal.
\n\nI would say there's one other thing that I think is fundamental for software development. And I've said this a number of times over my career to people who are aspiring software developers. And this doesn't just apply to software, but it very much does apply is that writing software is largely an exercise in frustration management. If that sounds scary, it shouldn't.
\n\nMy kids...my daughter is learning to play piano, and she tends to be a bit of a perfectionist. And when she makes a mistake, she just has a really hard time with it, and she wants to shut down and cry and say, "Oh, I made a mistake." And I tell her...well, there's a phrase that we say all the time; mistakes are proof that you're trying. And learning to recognize that, learning to know that you're going to be frustrated a lot of the time because that's what it takes to accomplish something new that you don't know how to do.
\n\nAnd being okay with that, being able to live with that frustration, knowing that yeah, this is hard; it is beating me down, and I don't know how to solve it, and I'm going to keep banging at it anyway until I figure it out, is a fundamental skill and perhaps the most important skill in being a software developer because we're here to solve problems. Sometimes we think we're here to solve code, but that's really not the answer. We're here to solve problems.
\n\nI started out with quite a bit of material there for us to chew on for a bit and discuss. Hopefully, that sparks some discussion. I have other thoughts as well.
\n\nDAVE: Oh yeah. I've got five pages of rebuttal, and if I may take the first topic. No, you're bang on, bang bang on. I can't remember the show. It's a meme now. But I want to say the show was Adventure Time, and there's like a dog with glasses. I'm not sure if it's Adventure Time. But the character is this dog who wears glasses, and he's a meme now. If you just search for being bad at something, you will come up with pages, and pages, and pages of this. And it's just him.
\n\nIt's a cartoon. And this is like serious life advice. And he says, "Look, sucking at something is the first step to being sort of good at something." And that is absolutely true with software development. You're going to sit down, and you're going to have people on one side of you that are saying, "Oh, there's a right way to do this. We're going to get this nailed down." There are going to be people on the other side of the spectrum that will be like, "Oh, there are 17 different ways to skin a cat, and you need to know all of them." And they're both right; there's usually a best way to do something.
\n\nAnd sometimes, the best way to be a great software developer is to spend ten years forgetting stuff so that when somebody shows you a problem, you have forgotten seven ways to solve that. And so you have instincts. You're just like, oh yeah, this is just that, we'll just go do that thing. But when you're starting out, yeah, you're like, okay, if I add this to that, I'm going to get this value. I can make a computer do math. Let's make the computer do math, and then we solve the problem. And that is essential.
\n\nI have individual tips and ideas. But I would say the most important thing I think you've said, Mike, is that software development is a social endeavor. It's almost a bait and switch because I definitely got into computers because they were the only rational human beings in my childhood. [laughs] I grew up in a crazy part of the world. And it's like, computers didn't bully me. And if you've ever worked with a computer, you know they're absolutely tyrannical, and they refuse to work. The computer always did what it was told, and I loved that about computers.
\n\nAnd it was much, much, much later in life that I realized that wait a minute, having a career in this great big raft of monkeys called humankind, boy, yeah, everything is a social endeavor. If you want to go off and solve a math problem, you can do that in your own time. But if you want to have a career, people are more important. They're always going to be more important. I learned that way late in my career, and it definitely influenced the trajectory of my career.
\n\nMIKE: If I could add on to a little bit of what you said there, you talked about going and solving math problems. I read an article I don't remember exactly where it was sometime in the last week talking about Albert Einstein, who is the kind of the canonical icon of the myth the lone genius that went off in a corner and came out with modern physics. He was working at a university with other physicists, and he wasn't even the first one to derive some of his equations. The math he used was based on what other people were working on around him.
\n\nBasically, nothing that he came up with was as radical as he's often credited for but was largely a group effort. Now, that's not to diminish the fact that he did have novel ideas, and he was able to make a leap that others, his peers, didn't make. But, and this is vitally important, he could never have made those leaps if he wasn't surrounded by that network of peers who brought him to that point where he could make the leap, brought him to that precipice where you can jump across the other side.
\n\nDAVE: Yeah. You can't integrate five different people's ideas if you don't go hang out with five other people.
\n\nMIKE: Absolutely. Absolutely.
\n\nDAMON: I think that makes a lot of sense. For you guys personally, do you feel like you guys have evolved a lot more whenever you started working with a team and became more team-involved?
\n\nMIKE: Myself? Absolutely. I was somebody who did coding by myself as a kid back in junior...well, actually, elementary school, I did a little bit. I didn't have a computer at the time. That was in the days before everybody had a computer before they had a computer in their pockets. But I did a little bit when I was quite young, and then in junior high, we had a computer, and I wrote BASIC programs in the BASIC computer language. And it was fun. I loved it. I was all alone. I had a manual that I'd pull out examples from and then try to tinker with them.
\n\nAnd then, in school, I largely worked alone as well. And then, in a career, suddenly, it was all with other people all day. And the amount of progress I was able to make while collaborating with other people was remarkable. And it also changed the character of my work. One thing that you do when you're learning typically is you start from scratch. You build everything from scratch because they want you to learn the fundamentals. But professionally, it'd be really foolish to build everything from scratch.
\n\nThere are many decades of computing that have happened, and people have built code that is open source or has a dedicated library within the company you're working on. There is other code that's been written that you can use. And if you're doing everything yourself, you're doing it wrong in many, many ways. That's another very important thing that we should learn about software development is that it's mostly about plugging together components that other people have written because the community together builds things that are really good, and then we use those.
\n\nThe novel things that we do is we take those pieces, those components, and put them together to make something happen that we want to happen. But most of the work has already been done. For example, most of us work in high-level languages, and we don't write assembly code for device drivers; there are people who do. But most of us are writing in higher level languages that are resting on interpreters and compilers all the way down that other people have written, and we probably will never modify. So it's using other people's work that we use all the time, and learning that was an important thing to me.
\n\nDAVE: Along the same lines, I remember my first full-time programming job; they left me alone in the corner of a basement. And I just cranked out code, and it was exactly like you would think, you know, just had the lights turned out and had my monitor in dark mode and all that stuff.
\n\nMIKE: [laughs]
\n\nDAVE: Yeah, I would write software the way I had always done it as a kid. I would spend hours, and hours, and hours typing code before I ever hit the compile button. And I left that job after a year and a half. And I went to a video game company, which I thought was my dream job. It turned out to be a nightmare job, but for a while, it was a dream job.
\n\nAnd I remember sitting down with another programmer who was a senior at the time, and I said, "Hey, can you help me with this problem?" He said, "Sure." And I'd been working on it all morning. And he came over, and he sat down, and he was looking over this. And there were obvious typos in my code. And he's like, "Have you compiled this?" And I'm like, "Oh, no, I'm not ready yet." And he's like, "Dude, yeah, no, stop. Make this compile right now. Stop what you're doing and make this compile."
\n\nAnd so we spent two minutes fixing typos, and we got it to compile, and it didn't work. We were ready to make the next piece of it work. But I was ready to dive into another two hours of writing stuff, grinding stuff out by hand. The point was that I had been writing all this stuff just out of my head [inaudible 14:33] And this guy was just like, no, we need to make this work, and then make the next thing work, and make the next thing work. And that was something that I did not get until I sat down with another human being who was a programmer who was familiar with the craft.
\n\nAnd I remember my compiler when it failed, I had tied in this little sound, this little funny, you know, oh, [vocalization] kind of thing, and it played this long sound. And we hit compile, and it didn't work. And my computer made this big, long noise, and the guy that was sitting next to me in a blink of an eye, he figured out the only way you're playing that long of a song on a failed compile is because you're only hearing the sound twice a day because you're only compiling your code twice a day.
\n\nHe heard that sound, and he's like, "Oh yeah, yeah, that's got to go." Just immediately, "That's got to go." And I'm like, "Oh, really?" And he just says, "Yeah, you need to be having failed compiles 20 times an hour." And I'm like, oooh, I mean, like, I was genuinely shocked at that, something I couldn't learn from a book. I had to learn that from another human. I mean, I could have if somebody had written down compile your code five times in a row. But I'm like, but why? I had to be next to this person to see that.
\n\nMIKE: Reminds me. My son was modding Minecraft. And he'd written a tremendously large function to do something, and he went on to say, "Can you help me with this? It's not working. It's not compiling." And I looked at it. And all the indentation was mismatched. And it was just formatting. The formatting was really bad. And usually, that sounds like a nitpicky thing, but I said, "Honestly, I can't help you with this because the formatting is so inconsistent that I can't tell what's going on just by looking at it," because he'd been writing a lot and writing inconsistently.
\n\nAnd I said, "Please fix the formatting. I'm not trying to be nitpicky. I'm not picking on you. I literally can't help you because I can't understand this because it is visually so distracting." So he went away for an hour or two and worked on it. And he came back to me with kind of his tail between his legs and said, "Yeah, it works now."
\n\nDAVE: [laughs] I cleaned it up, and I made it work while I was doing it.
\n\nMIKE: Just fixing the formatting made him aware that there were some mismatched curly braces somewhere. And he hadn't even deliberately fixed something. But just in the act of making it look good, the code started working. That kind of thing happens in a social environment.
\n\nDAVE: Absolutely. There's this magic aha moment as well that plays right into what we're talking about being a social activity and what you just said about cleaning up the indentation. A lot of us get the impression that source code is how you talk to a computer, and it's not. Computers don't speak source code; they speak ones and zeros. They speak binary operators. And the compiler takes your source code and turns it into these ones and zeros, which means we don't talk to computers with source code. Well, then, who are we talking to with source code? Other people.
\n\nWe write our programs in a language that other people, other humans, can understand. There's an ancient quote from the early days of agile back when it was called XP before Windows XP existed and took that trademark. Martin Fowler said, "Any idiot can write code a computer can understand, but good programmers write code that other humans can understand." There's a profound epiphany that I love getting into that somebody said. When you are writing software, you are writing for other humans.
\n\nSo if you write something and you start moving it around, and you line things up because it's funny to make the letters line up and da-da-da, and you make a picture in the code...and you're doodling a picture, but you're not explaining what you're trying to do with your program. You might think that's cool. You might think that's cute. Somebody comes along and goes, "I can't read this." And you suddenly realize that, or maybe you don't realize this, but hopefully, you realize that, oh, I failed at source code. The whole point of the source code was for another human to be able to read it.
\n\nReal early advice that I love to give people is that writing readable source code is a bit like being a jerk. You don't get to decide it. You're like, "Well, I'm not a jerk." No, you don't get to decide that; we're all going to decide that about you. And readable code is the same way. If you take your code and you break it up perfectly and you split the modules up, and you dry it up...DRY is don't repeat yourself.
\n\nSo everything goes into one specific place, and it's all perfectly correct according to this scheme in your head that nobody else knows but you. And it's beautiful, and it's perfect. And then somebody comes along and says, "Wow, this is really hard to read." Guess what? Your code is hard to read. You don't get to decide. It might have been fun to write. It might have been satisfying to write. But it's not actually readable, and you should change it.
\n\nMIKE: And that person probably has some important lessons for you to learn. Sometimes we get caught up in some technique that we think is cool. To your point, that isn't what makes code legible or useful. A lot of times...there's some instinct that you were talking about before and learning, well, what's easy to understand? Which may be different than what's the popular technique at the moment or that you read about last week in some blog somewhere.
\n\nDAMON: It's very interesting, actually, for someone in application support trying to go over into a software developer or engineer role just to know that not everybody knows everything, even though they might think everything is all perfect. Someone can come over and just be like, "Hey, I don't really understand what you're doing here." And they can just change it and teach you something. There's always something to learn.
\n¬
\nSAM: Yeah, it sounds like being a team player greatly benefits. But my question is, are there people that prefer to work alone? And if so, does that benefit anything at all?
DAVE: I have a pretty strong opinion about this. The short answer is yes and yes. As much as I strongly agree that software is a social thing, there are times in this industry when...let me back up and let me throw one wrinkle into this, a tiny little detail that I'm keeping in my head. Telepathy doesn't work, so let me use my words here. I have said this in the past multiple times, the best programmers I've ever worked with have almost universally been people who have degrees in a science field other than computers, so like math majors, not necessarily science majors, linguists, people with degrees in biology.
\n\nAnd the best programmer I ever worked with had a Ph.D. in geology, and specifically, he studied earthquakes. Not surprisingly, he and I worked at a company that dealt with vibration control. We were all about analyzing shock waves, and ripples, and sine waves, and standing waves, and reflections, and that sort of thing. And he knew that stuff cold. And every once in a while...I remember there was a meeting we had where he was struggling with a problem. And he said, "Yeah, there's this ticking sound coming out of the machine because every 256 cycles, we reset this thing."
\n\nAnd I drew a graph on his whiteboard, and I said, "So you're saying this." And then, I drew a joint in the graph where the thing reset. He's like, "Yes, that's exactly what it's doing." And I said, "Cool. Could you make it do this?" And I redrew the graph, but I drew a smooth curve so that it wasn't resetting at the zero point. It was starting off of zero and at the slope that it came out of the previous batch. And his jaw hit his chest, and he's like, "Holy crap, that would work. Get out of my office. I need to think about something." That was literally what he told me was "Go away."
\n\nAnd I didn't hear from him for three days. I worked like 12 feet away, like, two doors down from him, in a tiny, little office. I didn't see him for three days. Three days later, he comes in, and he's got this yellow legal pad. And all the pages are like standing up and frayed because they've all been written on in pen, like, this whole legal pad was used, and he's waving it like a madman. And he's like, "This, this, check this out. Dave, you got to check this out, this." And I'm like, "What is this?" And he says, "This is the mathematical proof of the drawing that you drew on my whiteboard. It will work."
\n\nHe had spent three days in his office in complete silence, trying to work out the mathematical proof before he committed six months of his life to writing the software. Because the thing that I had drawn was very simple to say but much harder to do, and he needed to prove that it could be done. And he needed absolute silence and unbroken concentration to get into the state of flow that he needed for that deep, deep level of work. So yes, absolutely, to your question.
\n\nThere are times when software engineering is this highly...it's a very wide social subject. We want five people in the room. We want to do mob programming. We want everybody talking. We want all the ideas coming out loud of our mouths. It's a noisy room. And we all want to collectively make the best decision that we can. And that's a fun way to program, and it's great for certain types of problems.
\n\nBut there are also times when yeah, I just want to sneak off to a conference room, and I want to get rid of all the external sounds because I want those parts of my brain that are listening and talking to other people I want them to spin down and release their CPU cycles to the part of my brain that solves problems so that I can get into really, really deep work. So the answer is yes, you do both. And sometimes you don't get to do the one you want to do. But sometimes you get to pick, and that's a good day when you get to do the one that you really want to do that day.
\n\nMIKE: We often organize our time so that the socializing is in a certain part of the day, and then the focus time is in another part of the day so that we have a long uninterrupted stretch to think deeply about something. Tricky problems require deep concentration. And then, once you come out of that, you might go back to the socializing part again. They're both necessary. You could have somebody who's just always doing the deep thinking and working on it. And what you'll end up with is very idiosyncratic code. You'll end up with something that really reflects that person.
\n\nAnd we all have our idiosyncrasies, but we're not generally looking for a piece of unusual artwork to come from our work. Again, we're here to solve problems. And, in general, you want your solution to be boring. I don't know if that sounds harsh or dull; it's not. Because a boring thing can be a thing of great beauty. You want a bridge to be something you don't think about at all and 200 years later to still be something you're not thinking about at all because it just works.
\n\nAnd it may have aspects of that bridge that you find quite beautiful, structural members that by their nature are just beautiful things. And software does have those things of great beauty. You don't want it to be too quirky, generally. Those quirky things might not hold up the way a very boring, predictable, hey, that just works solution would do.
\n\nDAVE: There's a fun thing...and you can do this in earlier Ruby. Something has changed. I know you can't do this in Ruby 3. I think it doesn't work in Ruby 2.7. As of 2.3 or 2.4, it still worked, as I recall. But this still works in C++ and languages that are all about bitwise stuff. But it is possible to swap two integers in three operations with no temporary variable.
\n\nIf you know a little bit of programming, you know that the way you swap two numbers is you copy one to a little temporary buffer then you take the other number and put it where the first one was. Now you've lost the first number; that's why you had to put it in a temporary buffer. And then you put the temporary number into the other number's place, and you've now swapped their place. You can take A XOR equals B XOR equals A XOR equals B, and that will swap A and B in place.
\n\nIf you go learn the rules for how XOR works, about how like if one bit is set, the other one is off, then it turns the bit on. If both bits are on or both bits are off, it turns the bit off. There's this whole algebra for how XOR works that you end up with one number holding itself plus the inverse shadow XOR of the other number, and you can get it back. And it works. It works. And it's super clever. And I carried it around for years, and years, and years, and years. And I would use that.
\n\nAnytime I wrote the swap function, I would use this method because it would make people think I was so clever. And I liked getting patted on the head and told that I was such a brilliant boy. And then somebody who really knew how XOR worked...and I had worked it out, like, I could explain to you how this algorithm works. Of course, if I'm going to be clever, I want to prove that I'm clever.
\n\nAnd just a very senior hacker walked in, and he said, "What happens if you tried to swap a number with itself?" And if you XOR any number with itself, it shorts out. You get zero, all zeros, and the number is lost. So if you try to swap a number with itself, it sets it to zero, and my algorithm is now stupid. And the whole point of doing this swap thing is so that you can only do it in three operations, so you don't have to...well, now I have to do an if test to see if they're the same number.
\n\nAnd if you try to swap two different copies of the same number, it will work. It's when you try to swap a number with like you say, swap X with X, and they're pointing at the same location in memory, then what you were using for storage was the sideband XOR data in the number itself. You lose that, and it zeros out. And that was the day that I really finally learned that don't do clever stuff in production; do the boring thing. It wasn't 1988. We weren't paying $20 for that extra byte of RAM to put the number in that we were swapping. We could afford it. And that's even more true today. Well, it isn't.
\n\nEverything old is new again because as soon as you say, oh, every computer has four gigabytes of clock or gigahertz of clock and 32 gigs of RAM, as soon as you say that, somebody will come along and say, "Hey, can you help me with this Arduino project?" Five years ago, ten years ago, Arduinos didn't have very much RAM on them. PIC chips back then you could get in...15 years ago, you could buy them with 64 bytes of RAM on them. And so we had to pull out the old books from the 1970s of how do I make this run on a program with no memory or on hardware with no memory? And that's coming around now.
\n\nLike, the big push in Ruby is to make mruby work, which is mobile Ruby, and they're trying to make it so that it will fit in an Arduino or on a Raspberry Pi. And the full Ruby will fit on a full-sized Raspberry Pi. But if you've looked at the latest round of Raspberry Pis, it's a four-gigahertz machine with gigabytes of RAM. It's a full computer now. The Ruby didn't shrink down to meet it. The computer swelled up to be able to lift it. The point is, don't be clever. [laughs]
\n\nIf you're going to make a trade-off, ooh, I just realized there's a better way to phrase this trade-off that everything is a trade-off. Never ever trade off something in exchange...never trade off something good...never give away something good in your code in exchange for getting to think you're clever or getting to show people that you're clever. Because they're going to come along, and they're going to see your code, and they're going to say, "How much did we pay for you to show me this? Because that holds no value to me."
\n\nSo I've got a question for Damon and Sam. So you guys are working in a software development adjacent field which, by the way, is a fantastic career path. There's a great book by Cal Newport called So Good They Can't Ignore You. And he basically tells people, if you want to go somewhere and you can't get there, like, you know, it's the age-old thing, right? How do you get five years of experience at a job where every job requires five years of experience? And how do you break into that? And the short answer is you get a job adjacent to the job you want. You go into customer support. A lot of people got into programming through customer support.
\n\nI went in and worked at a QA department. And I worked there for one week, and I submitted a bug report where I told the person that wrote the thing, "Looking at your Windows program, I strongly suspect you're using the Borland C++ compiler because..." I didn't say why. But basically, there was a tiny little graphical flourish on every Windows window that was a little bit different than the standard Windows thing. And that meant that it was this brand of compiler. And I used that compiler, which is why I recognized that flourish. And there's a really common bug because there was a default setting on the compiler that was dumb.
\n\nAnd so when I submitted the report, I was able to say the software is doing this. "At a guess, I'm guessing you're using the Borland C++ compiler. Go into your settings and change this, and that will fix the problem." And I got a phone call the next day saying, "Why don't you come over and talk to the programming department?" Literally, whoever that report got to, they were like, "Yes, I am using Borland. And holy crap, I do have that setting set." How did he know this? Bring him in here. I want to talk to him. So you work on your chops, work on your development, and then go into something adjacent.
\n\nI just screwed up because I was going to ask you a question then I ended up starting telling a story again; I apologize. [laughter] I'll try to do better. My question for you two, and then I'm going to shut up and actually listen and let you answer, is, from where you sit, what does a software development career look like? And that might be from here to starting at your software development; what does that look like?
\n\nHow are you getting ready for this? Are you getting ready for this? Is this something you want to dip a toe in? Or are you locked in and like, no, this is my life, you know, this is my destiny; I'm going to get there? How are you guys looking at software development from where you're at?
\n\nDAMON: I'm ready to just dive into it. It's been something that I've been interested in, but I never took the initiative to learn until...I didn't feel like I was ever going to be capable of doing it, honestly just because it looks a little bit more challenging than maybe it actually is. I don't know; my brain works kind of weird. But, like you were just saying, I was in basically a customer service role. I was in processing for, I'm going to say like, five months, maybe.
\n\nAnd then I decided I didn't want to be in processing anymore because I had a little bit more to offer, not really sure what it was. But I applied for the operations role, and I got hired basically after a week and a half of interviews and stuff like that. I worked in ops for one day, and basically, they were like, "Hey, we looked at your resume. And talking to you, we feel like you're going to be really bored here." I think this was when Ryan, before he left and then he came and got me with Alicia, and they were like, "Hey, we have better opportunities for you."
\n\nWith that being said, it looks promising for me. I just feel like it's something that I've always wanted to do. But like I said, I just never had the opportunity, the chance, never been given a shot until now.
\n\nMIKE: Imposter Syndrome biting you. It's a plague.
\n\nDAVE: And it never goes away. It never goes away. I blew an estimate...Mike can confirm this. We had an integration where there was a wrinkle to it. It was a two-week integration. And I estimated, oh yeah, this will take about two weeks. And then they said, "Oh, but you can only test it in production." And I'm like, "Oh, okay, make it four weeks." It took me what? Seven months, six months? I'm terrified to count up the actual total. And that was this year.
\n\nI started this last fall and finished in March. Like last month, we put the final bow on this. And I was hanging my head thinking, man, they're going to fire me because I do not know how to program. And that impostor syndrome will haunt you. It never...well, hang on. Let me rephrase. It will try to haunt you for your entire career, and it will sell you a lie. And here's the lie; keep quiet, keep your head down. Don't try for the opportunity right now. Just go learn something more, and eventually, you'll be good enough to get it. That is a lie. You will feel like that your whole life.
\n\nI feel like that today. I came out of blowing that estimate thinking, oh my gosh, I'm a terrible programmer. I'm never going to be a good developer. And meanwhile, I'm jumping into skills clinic with new people and mentoring and teaching, and everyone's telling me, "This is great. This is a lot of fun. I love working with you." And I'm like, yeah, but I'm so bad at estimates. I had no idea this was going to bite us in the butt this hard.
\n\nIronically, once we sat down with the customer and said, "This is not going to work; you have to make this work for us," we finished up in about three more weeks. So, you know, we got that thing fixed. By the way, that's literally my imposter syndrome saying I need to speak in my defense here. I'm blowing that estimate because I feel so guilty about it. And that will haunt you. So get comfortable now with reaching for the golden ring when you have the chance for it.
\n\nThe best use of surplus privilege is finding invisible doors and opening them for other people. But never ever forget that the use of your existing amount of privilege is if you see the golden ring, reach for it. If you see a whole bunch of golden rings around the carousel, get on the carousel. If they'll let you on, get on. Because you're going to tell yourself, oh, I don't deserve to be. And there'll be gatekeepers who will say, "You don't deserve." And if you can sneak onto the carousel, do it. And if you can grab for that ring, grab for it.
\n\nAnd there will be times when you're going to be like, oh man, I got this great opportunity, and I so do not deserve this. I better grow up fast if I'm going to fill these boots. And it will make for very, very happy memories when you look back and realize I did fill those boots. It turns out this entire time, I absolutely was good enough to get on that carousel and grab that ring. Never negotiate against yourself. I guess that's the summary on that.
\n\nMIKE: Well put. Sam, how do you see software development?
\n\nSAM: Well, I'm pretty much in the same boat as Damon. I was pretty much in a customer service role for about three years, and I told myself that I wanted to do something else. I actually told myself two years into the company working customer support was just hard; I think what you guys were saying imposter syndrome. And then, finally, I just reached a point where like, I got to do this. I got to get out of my comfort zone. So I ended up taking up a position with operations. I did that for about seven months.
\n\nAnd then, like Damon, I was approached by Alicia. And they said, "Hey, we think you'd be a good role for this position in application support." So I decided to take it. And right when I got into this role, this is where I was opened to seeing operations on a different...and engineering, I haven't really looked a lot into it, but yeah, I would definitely want to learn more about it.
\n\nMIKE: I'm going to agree with Dave here that, you know, take the opportunity. If you got that opportunity, take advantage of it. And to those of you who are listening, there are a lot of opportunities in software development. And it may be that you keep running into walls, and you feel like, man, I can't do this. And I think Dave gave fantastic advice. Get close to it. Get close to that role and keep doing work and take every opportunity that you can to do some of that software development work.
\n\nAnd this applies outside of software development too. If you want to be an astronomer, go get a janitorial job at the observatory, [laughs] whatever it is, get close to it. And there will be opportunities. And if you keep working at it, you'll get better. And you'll be surprised at how much everybody else around you is just figuring out as they go too.
\n\nDAMON: Yeah, that's awesome. Thanks, guys.
\n\nMIKE: We've talked a lot about what software development is actually made of and what skills are involved, and the importance of recognizing our fallibility that we all have, allowing us to grow and change. I think we hit on some really great points. We're reaching the end of the time that I think we had scheduled for this. So I'm going to ask, are there any final thoughts, things that have been on your mind you just want to say as we've been talking?
\n\nSAM: No. I think I came here just expecting to listen, and I've learned a lot here. So, yeah, thank you for having me. This is definitely empowering.
\n\nDAMON: I think for me, personally, this was a really good one because we do plan on transitioning here into an engineering role soon. So I was like, oh, this is perfect. I need to listen here to learn about the struggles that you might go through or you will go through and how to go about those. And teamwork is very essential. This was helpful.
\n\nDAVE: Sam and Damon, Acima is the best company I've ever worked at for having a pipeline and an investment in new programmers and turning them into experienced programmers. Hang out, come join a podcast, get close to the programming. That actually was a genius move you guys pulled here today. You absolutely have every right to be here. You're not imposters on the show today.
\n\nAlso, come hit up the Atlas team, where we're working on the website that the merchants log into. There are people on that team that will say, "Oh, you've got an hour free? Come sit with me, and we'll write some code together." And you'll probably just watch and learn for most of the time.
\n\nThere are skill clinics. And this is less valuable for people listening to the podcast, except I want other companies and the people at other companies to know that this exists, and you can do this at your shop as well. Put on a skills clinic every day if you can afford to, and if you can't afford it, make the affordance for it. And have tickets in your backlog that are marked as starter that you can have...we cut this food up nice and tiny so that somebody with a small appetite can tuck into it and close it out safely without having to touch the guts of the whole machine. So yeah, get close to it.
\n\nSam and Damon, the next steps for you go find developers on other teams and say, "Hey, can I come sit with you and learn and just watch you type and point out your typos?" And that's a much more valuable pair programming offer than you think it might be. It's not a complete one-way street; it is you actually providing value. Yeah, find the value you can provide and provide it, and that will be your next step forward.
\n\nMIKE: I would add on to what you're saying there, Dave, to those people at companies that could be doing this that just say, "Well, we can't afford this. We can't afford to invest in the growth of our employees." I would flip that. I would say you can't afford not to. There is so much --
\n\nDAVE: What's the saying? What if we train them and they leave? And then the counterargument is, what if we don't train them and they stay?
\n\nMIKE: It's wildly expensive to be in that situation, so is not training them, and they leave. There's no good scenario where you don't help people out that just stays that way because, really, it's not going to stay that way. You're not going to have the culture, and the end product, the software that you really want unless you've built an environment that is conducive to building good software. The cost is going to be paid whether or not you see it.
\n\nIf you have under-experienced developers who have not had a lot of opportunity to grow their skills, then you're paying the cost of that software that isn't what it could be and paying the tremendous cost of losing good people. Take the time. And if you're out there, take the opportunities that are there. Make them at your company. It can make a tremendous difference, not just to you personally but to the organization you're working.
\n\nThank you, everybody. This was a great session. I look forward to talking to you next time.
","summary":"A discussion about what software developers actually do and the skills required to be successful.","date_published":"2022-11-09T00:00:00.000-05:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/0230198f-f517-4abd-ba34-58d5feb9bd56.mp3","mime_type":"audio/mpeg","size_in_bytes":47077321,"duration_in_seconds":2575}]},{"id":"094bdb0b-9810-4678-a6dd-2894bd7f785e","title":"Episode 3: What Should The Relationship With QA Look Like?","url":"https://acima-development.fireside.fm/3","content_text":"Today, we have a conversation about what the relationship should be between QA, testing engineers, and development engineers. \n\nTranscript:\n\nMIKE: Once again, we have another session of our podcast that doesn't have a name yet, but we'll choose one soon. [laughs] Today, we're going to have a conversation about what the relationship should be between QA, between the testing engineers, and between the development engineers. I think this is a really interesting topic. \n\nAnd we've got a great group here today. We've got people from the QA side and from the development side, and some people who've been on both. So I think that we can have a really good discussion here and hear about the different perspectives and how people see it. I've got some strong feelings on this one. I'm looking forward to the conversation. \n\nI am Mike Challis. I am a software developer here at Acima. I've been a software developer for a long time, a couple of decades. And I'll be hosting today. We'll go around and introduce the group here so that you know who you're listening to. Guillermo, do you want to introduce yourself?\n\nGUILLERMO: I'm Guillermo. I've been in QA since August of last year, just about eight months. And I didn't have any experience in QA coming into this position, but in this past time, I've gained a lot of knowledge. Before that, I worked with collections in Acima. So I had knowledge with LMS and merchant portal. That's the extent of my knowledge. And now I've gathered a lot of knowledge.\n\nMIKE: Great. And I like that you mentioned the knowledge. I think that'll help lead into some of our discussions later. Well, thank you. Jared, do you want to introduce yourself?\n\nJARED: Yeah. So my name is Jared. I've been with Acima for about ten months now. I'm leading the QA team. And the QA team is, you know, a lot of the team members are working into a development role. And it's been very interesting for me because I've got about four years of QA experience. And I love seeing the growth and learning all the technical aspects here at Acima. So I'm happy to be here.\n\nMIKE: Great. Eddy.\n\nEDDY: Hey, team. As Mike mentioned, I'm Eddy. I've been in QA going on ten months now. The team is great, and I couldn't ask for a better position. So you guys are awesome, and girls.\n\nMIKE: David.\n\nDAVID: Hey, I'm David. I've been a software developer here in Acima for like one year now. And I have been a software developer for more than ten years. I have also been in the QA role years ago for...it's like one month or something like that. And I have helped here also. So it's a great topic, and I'm glad to be here. \n\nMIKE: Great. Thank you. Diane.\n\nDIANE: Hi, my name is Diane. I've been at Acima for two years and have been QA for a year. The first year I was in processing, so I have a lot of experience with merchant portal. And I came on to QA with no experience, and so I've been able to learn a lot and grow a lot in this position. \n\nMIKE: Oh, that's great. Ramses. \n\nRAMSES: Hey, everyone. My name is Ramses. I've been with Acima for three, three, and a half years-ish, almost four years. I've been a developer for just a couple of, I guess, about two months now, I think, full time. I was in a technical support role for a little over a year, and during that time, I did a little bit of QA, but it was just kind of on and off. \n\nMIKE: Great. And you might offer some interesting perspective as well, coming from support, not exactly QA but a similar role. Zsolt, do you want to introduce yourself? \n\nZSOLT: Yes. Hello. I'm Zsolt, and I'm the newest member of the QA team. I've been on the team for about three weeks now. I've really enjoyed working with the team so far.\n\nMIKE: Great, yeah. We love having you on the team. Afton. \n\nAFTON: I'm Afton Call, and I have been in a few of these episodes, so I might be somewhat familiar. I have been a software developer for just shy of four years here at Acima, and that is my entire career. [laughs]\n\nMIKE: Great. Melissa.\n\nMELISSA: Hi, I'm Melissa. I've been at Acima for six years now. I also started on the operation side of things and then moved into QA with little experience. I had been pursuing my computer science degree for maybe a year at that point and had also done the mentorship that Afton led. And now, I'm a software developer, and I've been doing that for the last ten months now. Happy to be here.\n\nMIKE: Great. Josh.\n\nJOSH: I'm Josh, and I've been at Acima for a little over seven months now, I think. But I came to Acima with about ten years of experience in QA in different roles, mostly in Utah. I'm originally from Washington State. So I still think of that as home even though I've lived here for quite some time now. So that's me. \n\nSo I'm right now working with the QA team, and we have a really good team. I'm extraordinarily lucky because I've worked on some that don't communicate as well, work together as well. So yeah, for lots of reasons, it's a really good team. \n\nMIKE: Great. And you probably have some interesting perspective there of seeing things not work so well.\n\nJOSH: I obviously don't focus on those. But yeah, obviously, there's group dynamics and all that. It's very interesting to me.\n\nMIKE: Thank you. James, do you want to introduce yourself? \n\nJAMES: Hey, yeah. I’m James Murphy. I'm on the QA team. I have been with Acima for a little under three years now. Started off in sales, went into account management, did that for about two years. And then, I've been with the QA team for about eight months. Always been interested in technology, development, things like that, and QA was a great opportunity for me to really dive into it headfirst. And it's been a little like drinking out of a firehose, but it's been awesome. I love it so far. Great team. Really have enjoyed my time here with the engineering side of things.\n\nMIKE: Thank you. And finally, Brian, want to introduce yourself?\n\nBRIAN: I've been with the company for three and a half years, I think. I started in QA when it was a two-person department and was there for about two years. And I've been in development about a year and a half.\n\nMIKE: Great. Well, let's start our discussion. We've got a diverse group here, and people from QA, and people in engineering, the development side of engineering, and people who've bridged the divide between the two. So I think we will have a great discussion. I wanted to start by talking about an interesting experience I had quite some years ago. \n\nI had a bus driver when I would ride to work who was an adjunct professor at a local university. We can have another discussion here about how adjunct professors are underpaid, and they have to drive a bus to make their living [laughs] on the side. But we had some fantastic conversations. Previously being a university professor, he had been a QA engineer at a company. And we had some interesting conversations about what a QA engineer should be. And we'd sit on the bus together and chat. Sometimes it was just the two of us, so we had some great conversations. \n\nAnd one thing that he talked about is that companies he had worked for the QA team and the developers were very adversarial. They hated each other. The developers would think that their code was perfect and hand things off to the QA team. And the QA team thought that everything that the developers wrote was trash. They would always send it back and tell them about all the problems with it. \n\nAnd in the end, a lot of times, the developers would just end up ignoring the QA team, or the QA team would try to send ultimatums to say, \"We're not going to let this go out.\" And it was a really toxic environment that he talked to me about. Where I was at the time didn't even have a QA team. \n\nBut sometime later, I worked at a place where we hired some people into QA from out in support and found this familiar story. And one of the developers who became a QA engineer really applied himself, became really good, and ended up asking to become a manager when we had a bad experience with the existing manager, and he had just disappeared one day. And I supported, and he ended up being one of the best managers I've ever had. \n\nWent on to become a software architect and is currently playing a prominent role at another software company. He took that journey from being out in support to being the lead engineer at multiple companies. And seeing that transition, seeing how great it was working with him, gave me a lot of perspective as to what QA could be versus what my bus driver had experienced, which is really awful.\n\nThat opportunity that QA had to work closely with developers ended up not only building better software, I think, but also giving the QA team an opportunity to really bridge that divide between QA and development and sometimes crossover. And I thought that was a great transition for this developer. I'm not going to mention his name since he's not here [laughs]. I don't want to name him without him present. \n\nBut seeing that success, as well as a number of successes here at Acima, in particular, of people who have come over from QA and had a great time in development, I had some strong thoughts about how important it is for the developers and the QA team to work together as peers, as a combined team that is collaborating with different strengths that compare their different strengths in order to produce great software. \n\nWith that introduction, I'd like to have an open-ended discussion here. Hopefully, there are some seeds there for us to keep talking. What do you all think the relationship between QA and developers should be? And you certainly have some context here. And some of you have some context with other companies as well. So I will quit talking and let others speak.\n\nJARED: I really wanted to jump in and say this. Having been in a couple of other companies and now coming into Acima, I think it's incredibly impressive the way that the developers put into unit testing. Every single PR I get has a unit test, and that means the developers are more test-minded. And so I think it's really easy for the QA team here to get along with the developers because everybody has testing in mind. \n\nAnd I've seen places where testing is like the last of people's worries, and then some things get pushed out, production breaks, things happen, and it just doesn't work very well. So I have to say that about Acima. Everybody is test-minded, so it makes the environment really easy.\n\nJOSH: I want to add to what Jared just said. When developers and QA are both test-minded, nobody is the official...or no one is seen company-wide or even department-wide as the gatekeeper for the release of any product, or feature, or code. When it's viewed the other way, I don't want to say toxic, but maybe it's not as balanced. If developers aren't as involved in testing, then it's all on QA. And as a result, if there's something ever wrong, it's easy for that message to spread through the department that QA doesn't want to release something, so it's like we're the bad guys. \n\nWe get all the blame but none of the credit because if it goes out live, developers are like, yay. [laughs] So I like the mix we have here at Acima, and that's when it's like, we're integrated. And we don't necessarily have individual teams within the department, but we all work together all the time on every PR. So we all have equal stake, and I really like that.\n\nMIKE: That's an interesting point you both raised about developers being interested in testing as well. What happens when developers aren't interested in testing? Can QA save that situation?\n\nJOSH: I think short term maybe like from a PR to PR basis, but long term it sees more consequences.\n\nDAVID: I think that's out of mindset or also experience because I've been working for places where developers hate QA. Those developers are...because they don't like to test. They just code, and they just test the happy path. And they just send everything to QA. And then the QA guy starts testing, and they see, oh, there's a bug here, and boom, it rejects the code and rejects the ticket. And then the developer is, no, but it's fine. And they...no. Did you sit with the QA? And they say, \"Oh no, it's right.\" \n\nAnd they start hating the developers just because they were unable to test their codes like they were just in the happy path, and they were unable to see beyond that. So I've been in that place. But I think that's also a matter of experience. Because for example, in my place, I love when QA finds a bug because I know that code is not going live. He just saved me from a real problem. So yeah, [inaudible 12:24]\n\nMIKE: There's a text post here: it works on my machine. [laughs] I think you hit on something critical there, David. Sometimes I think that we misunderstand our job as developers. We think that our job is to write code, and I would argue strongly that that's not our job. Our job is to solve business problems. And if we misunderstand what our job is, then...I wrote all this code. This code is wonderful. Why aren't you thinking that my code is wonderful? [laughs] We start taking it personal. \n\nAnd there are some issues there around psychological safety as well that I think are important to recognize that you need to be able to have feedback without it being a personal attack. But this idea that the code is our output is, I think, really problematic. What we're trying to do is solve the problem. And if we're all trying to solve the problem, then code is part of the solution, but it's a collaborative effort to solve the problem. \n\nAnd as you said, David, if somebody finds a bug, and I feel the same way, like, oh, thank you for saving me because we're working together to solve the problem, not working adversarially to push out code that then somebody's going to criticize. And we just have better outcomes. It means that we're all working for the same goal rather than for different goals. Neither of which goals really is one person's goal is to block the code, and the other person's goal is to get out code. Neither of those are really solving the real problem, which is the business is trying to help people out with their software, provide a feature for customers.\n\nAFTON: This surprises me to hear how many experiences people have had where developers are just kind of, here's the happy path, here you go and then sending it off. And maybe this surprises me because I've grown here at Acima [chuckles], where testing is a big part of our process and our mindset. But when I write code, I want it to be foolproof. I want you to be able to throw anything at it and know it's going to work. Like, this can handle whatever you throw at it. That's a big part of what makes me feel so satisfied to produce it. \n\nIt just surprises me that there seems to be so much where the happy path is all they're thinking about because all the different angles is like, yeah, I feel like I'm here to solve the problem, not to present just a happy path. That's interesting to me.\n\nGUILLERMO: Kind of what Afton said is I think I'm fortunate enough to start QA in Acima versus another company and getting that bad taste of QA somewhere else. I do agree I can reach out to any of the devs tickets that I'm working on and say, \"Hey, I'm finding this.\" And they respond rather quickly, and they'll work on the machine. And we get to the root of the problem and take it out.\n\nJOSH: I think a lot of it in my experience...I've worked at several companies in the last decade here, and it's in QA. So they've all had unique arrangements, both in departments and how teams are set up together. And what you're describing, what Guillermo just touched on from my experience, seems to happen in teams that are divided where there's the QA...oh, you're on the QA team, okay, I'm on the dev team. \n\nThose kinds of teams, you end up finding developers who you work well with and then just avoid the rest of them. And they probably do the same for QA people as well, someone who can test their stuff and get it released as quick as possible, who isn't going to be a pain to work with and find bugs, or however a lot of that is viewed. \n\nThat stuff dies away when you integrate, at least in my experience, when you work like the teams are divided like 60% developers, 40% QA, or 70-30. When you're on the same team, you're in the same meetings. You're planning together. You're grooming stories together. You're understanding what the work is. That animosity, for the most part, dies off. So in a way, the way it's set up here at Acima kind of plays to that same...falls in that same category. Like you said, Mike, we're all trying to produce quality software that solves business problems. We're not trying to get done the fastest. We're trying to get it right. \n\nEDDY: To chime in a little bit here, I feel like there's a stigma in the industry that I've read on, and I've heard from other people's experiences how the relationship between QA and developers can be rocky at times, whether that's communication or not. I can talk from personal experience working at Acima that that's never been the case. \n\nI feel like it's crucial where the communication and the confidence, you know, to be able to provide feedback, whether it's good or bad, whether it's from QA to developers or vice versa, is really important. And I think that speaks for the foundation and the team dynamic that Acima has grown and groomed that all of us...and I guess I can speak for all of us where the communication is great between both parties.\n\nJARED: If I could actually interject on that as well, the communication aspect I think is so important because if you think about developer to QA, oftentimes, there is a huge discrepancy in technical understanding. So the devs do what the devs do, and the QA does what the QA does. And oftentimes, devs will hand QA a ticket, and QA will not know what it's supposed to do, not understand what's going on. \n\nAnd so I think if you look at it from...the communication needs to be polite in a way where the devs can't go and say, \"You're stupid. I wrote this code. I know how it works. This is how it's supposed to work.\" And then the QA, if they find an issue, they shouldn't go to the dev and say, \"You're stupid. This doesn't work. This is not how it's supposed to work.\" \n\nI think wording is very important where the QA shouldn't come and attack. But they should ask, like, \"Hey, I'm seeing this. Is this how it's supposed to function? How am I getting this result?\" And the dev can then also walk him through how it's supposed to work. I've seen a little bit of that in my experience. I think that's what creates the animosity, the toxicity, and the divide between the two. But the way that you word your questions, I think, is very important.\n\nJAMES: This just reminds me of a situation I got myself into. I was fairly new to the QA role. And I was doing a PR where, Melissa, I think you and Brian had collaborated on it. I did something. I did like a database rollback instead of...I don't remember exactly what I did. But I completely threw everything sideways by accident. [laughs] And so I went to Melissa and Brian, and I was like, \"Hey, can you help me understand what I did?\" And they were super nice about it. \n\nAnd they kind of just explained the intended testing was this, but this brings up an interesting point of maybe we should set precautions against this. And I felt like an idiot because I completely messed up the testing and kind of threw a wrench in things. But Brian and Melissa were like, \"No, no, like, it's an interesting way of looking at it,\" and kind of took that perspective. And it almost just gave me the confidence of like, oh, cool, I can talk to these developers. \n\nAnd if they had come to me and been like, \"Hey, stupid head, that's not what we said to do,\" but they were so cool about it and just friendly. And they walked me through the processes, and the differences, and the different styles of testing and stuff like that. And it just kind of created this very friendly environment, even though I had stepped in it. That is something that stood out to me where it's just like, really, it was a great experience for me where it could have just been awkward or embarrassing for me. So just going along those lines.\n\nBRIAN: Yeah. Having a new user who's totally brand new to the whole thing is such a good perspective to get as a developer because we get so nose to the grindstone, so to speak. We're too close to the metal; you know what I mean? And so that's why when you run it...I don't even remember the property there. \n\nBut I love finding those weird things, and it's because someone who's brand new to our tech stack and brand new to the problem we're solving, it's like, they actually have a really good point of view because they're going to do what the most intuitive to them is. And that's why I was like, so interesting for you to find a problem that we're like, yeah, everyone is just so used to migrations working this way. Put it in front of someone brand new, and you're like, oh, well, what did their intuition say about it? \n\nJAMES: Wasn't it like I was supposed to try to do a seed migration then a seed rollback, and I ended up doing a database rollback or something like that? But again, yeah, [laughs] I did --\n\nBRIAN: I don't remember at all. [laughs]\n\nJAMES: I just remember you guys were super cool about it, and you helped me understand what the difference was in that instance. And it helped me grow as a QA rep. And it was a good experience for me just learning.\n\nMELISSA: Yeah. And I think that brings up a good point of investing in your QA. Because if we take the time to actually explain things and help you understand different processes, then that's only going to benefit us in the long run because then you can think of different scenarios to test or how to manipulate data in a certain way. So I think it's really important to take the time to explain things to QA.\n\nJAMES: I can vouch for that. That's something that's helped me out a ton, just taking 15 minutes and saying, \"Well, actually, this is why this is doing this, and this means that.\" And I've always really appreciated that.\n\nBRIAN: Cool. And that's one of the benefits of our pipeline from QA to dev is me and Melissa; I mean, that was like just a year or two ago for the two of us. We kind of understand QA's point of view. We definitely understand being new to the Acima tech stack. And I think that's one benefit of...not saying that people who don't do QA are bad developers, but I think that is one good benefit of being a QA first and then being a developer is your perspective. You kind of have a little bit more empathy, I feel. And you kind of view QA as the goalies for your team. You would never get on the field without your goalie.\n\nEDDY: Mike, I think if I can interject here, you've had skills clinic before where all we did is talk about the fear of sounding stupid, for lack of a better term. And I think a lot of us, when we first get started, you know, get in our heads about like, man; I don't want to sound dumb when I message this developer. Or they must be really busy; I don't want to take time away from them, from work asking something that's really simple to fix. \n\nBut the environment, again, that Acima has groomed, speaking for me at least, is that that's never the case. Every time I've messaged someone about a concern that I've had that has been met with generosity. It's been nothing but great experiences.\n\nMIKE: I'm really happy to hear that. [laughs] That's immensely gratifying, I'll say that. That is exactly what I'd want to cultivate. The technical word that I would use for that...well, it's two words, psychological safety, the technical term, and there's a good body of research. Well, first of all, I just thought on a personal level, I think it's important to treat people nice. That's backed up by research, and you can look this up. \n\nGoogle did some research some years back as to what made their teams most effective. There were a few contributing factors, but by far, the most important factor they found was that psychological safety, when people feel free to express themselves, to be themselves, to ask questions, to ask uncomfortable questions, then the team is much more successful. \n\nBecause all of us, you know, you talked about doing something that made you feel dumb as a QA developer. Well, developers do that, too. We do things that we look back on and think, oh, why did I do that? All the time, because we're human. We make mistakes. Closely connected to creativity, you know, we do stuff that is unusual. And a lot of times, it doesn't work, but sometimes, it's brilliant. And we have to be able to be there for each other in order for those brilliant things to come through. \n\nI also love what Melissa said. She said, \"It's an investment.\" It might take 15 minutes to explain something to the developer that's testing your code, to that engineer who's testing your code, and that is a cost; that's time. But if you pay that, it will be paid back with interest. Making that investment in those relationships and in helping people develop those skills will grow your opportunities in the future. And my experience is that time is almost always worth it. \n\nI mean, there are times when something's on fire, [laughs] and you might have to defer the conversation. But that doesn't mean the conversation shouldn't happen. Once the fire is out, well, okay, the fire is out. Let's go talk. It is worth asking those questions to develop that. It looks like, Diane, you had something to say about that, about asking questions.\n\nDIANE: I get nervous to ask questions all the time. But one thing I do go by is that if I don't ask this question, even though I may feel like it's dumb, I'm not going to get the answer. I'm not going to know how to do these certain tests. So it's really important to, even if you feel like it's dumb to ask the question.\n\nJAMES: And just to kind of piggyback on that as well, I've found personally, if you have a question, chances are there's at least one or two or a lot of other people that are going to have that same question or aren't 100% concrete on the answer. So I've always tried to have that mindset of not even just asking the question for myself but asking that question for other people on the team who might have that same question.\n\nMIKE: I would offer that, in my experience, asking a question does not make you look stupid. It makes you look curious and eager and interested. I want to work with people who are curious, who are interested, who want to know what's going on because then I know that their skills will be growing. Honestly, when I'm interviewing people, and I've talked to many other developers who interview, who have said the same thing: one of the things they're most looking for is people who are curious. We're in an industry where we don't know all the answers; none of us do. But people who are curious will find the answer.\n\nBRIAN: It's a pretty common saying, I guess, but the only stupid questions are the ones you don't ask. And it's important to keep that into perspective because, as Diane was touching on, if you don't ask the question, you're never going to know the answer, and so you'll just be in the dark, and you don't get anywhere with that.\n\nMIKE: And then you're stuck, right? Being stuck is not good for your career. [laughs] I have to say that. It's not good for anybody. It's kind of the definition of a bad position to be stuck. If you're in a company that's interested in getting things done, that's the last thing that they want. And if you ask somebody, they're going to be interested in helping you out. \n\nAgain, there are unhealthy companies. There are unhealthy cultures. But in companies that care, and I think it's probably most, what you'll find is somebody is going to want to work with you because they want to solve the problem. And you're going to do that better together. \n\nMaybe to pivot a little bit, one thing that we've done a lot here at Acima, and as I mentioned before, I've seen this happen in other places, but we've really tried to emphasize it is we try to have a [inaudible 27:10] boundary, an open door, a pipeline so that QA engineers have an opportunity if they're interested to build development skills, to actually start working on code, taking tickets and writing code, getting that experience and building that over time so that they can move into development if that's something that interests them. \n\nI personally think that that has been a fantastic thing because it gives people opportunities. It allows us to work with people that we already trust and know are extremely talented and already know the business. It just seems to be a win all around. I think that that's a fantastic thing that we've done. And again, it's not only here that I've seen it, but I think it's a wonderful thing that we should do, that we have done, and that everybody should do if they have that opportunity.\n\nWhat do other people think about that pipeline idea of there not being a hard boundary between QA and developer but trying to spread that role around so that QA engineers can do some development if they so choose and even move over into development?\n\nJARED: For me personally, I think nothing builds a good company culture better than the possibility of upward mobility. There are a lot of people that go and get a job, and the only thing that they know how to do to change their position is to get a different job. And some people have all that knowledge and that experience with one company, and you're using that software internally. And if you're able to move into a new position and still retain that knowledge and within the company, that makes you not only more valuable to the company but also to everyone else around you. \n\nBecause I think there is a massive turnover cost to losing employees that have this tribal knowledge of your software, and they just go to another company versus retaining them and keeping them and moving them in other positions.\n\nEDDY: I just love the perception that I've gotten for the past ten months that I've gotten here. And it's nothing but good things. And the fact that Acima is willing to invest within goes to show the environment and the company that you work for and the possibilities of happiness, of willingness to stay longer within the company. \n\nI even heard of situations where people leave Acima, and they come back because of the environment that you guys provide, and I think that's really important. And I love the fact that Acima is willing to invest an hour or two a day to work on skills that we're wanting to and pay the debt back to the company.\n\nMELISSA: This pipeline works both ways for dev and QA like; it improves both sides of the process because developers come in with that more test-focused mindset then produce better code because they're trying to think of all the scenarios. And then also it benefits QA because they start to understand the code that they're testing. So they can actually look at the code and see scenarios that maybe the developer didn't think about. So I think it goes both ways. I think it just benefits everyone all around.\n\nEDDY: One thing that I love as well is...this was kind of explained to me when I jumped into the QA position is really that it's on me to learn. Whatever I put into this job, I'm going to get out of this job 100%. Coming from a sales background where I could be the top sales rep or hitting my quota every month, and I just keep doing the same thing every day, it's refreshing because, really, in the development world and in the QA position, I feel like whatever I put into this job I'm going to get out, Mike, like you said, with interest. I'm going to get back everything that I put in with interest. \n\nSo it really is a cool environment where the developers are helping QA, and QA, in some ways, are helping the developers, and there's this collaborative effort. But also, it's kind of on us to be self-taught and to learn what we need to know to be more effective in these positions and to master our craft, if you will.\n\nAFTON: I'm just going to say I have loved watching people move into development from QA, not only because I love being part of the mentoring and helping and teaching because that's something I personally find a lot of joy in, but the quality of developers, like Melissa was saying, who have learned how to ask all the questions, and test all the scenarios, and think very test minded has blown my mind actually to see these developers who were my QA and then they're my peers, and they're reviewing my code. \n\nAnd they come up with great questions that challenge the work I'm producing and help me to become better. And also, having the opportunity to mentor people as they're coming in helps me to improve myself, explaining and thoroughly understanding why I'm doing it the way I'm doing it. It's just good all around.\n\nMIKE: I couldn't agree more. [laughs] Absolutely. I'm interested in this idea that I think, Melissa, you mentioned and others have touched on it. It makes us better developers as well when we are test-minded that not only were we thinking about QA coming over to development but development doing some of the QA role. \n\nAs a company, we have a policy, and it may not be exactly the same across all teams. Certainly, our team has a policy where a developer will test the code first before it goes to QA. We test within development before we send it over to QA. And we also have a process of documenting the tests so that we're thinking through the testing process enough that we can document it well enough for another developer and a QA engineer to test it. \n\nAnd thinking through the problem, like writing up those instructions, is really good for poking holes in your code [laughs] and your thinking as you're going through that like, oh, wait, I missed this. And where our goal is to produce great software, that's a wonderful moment where the light bulb goes on, like, oh, wow, I forgot to do that. Or, oh, look at this thing that broke, or, wait, maybe I haven't tested that. I should check that and add that to the instructions. \n\nJust going through the process of explaining what needs to be tested, I think, goes a long way, as well as doing the testing itself beyond what unit testing can do. Unit testing is fantastic. There is something to be said for manual and integration tests. They catch things in an integration sense that individual unit tests would not. Have other people seen this idea of a testing culture on the engineering side, improving your code?\n\nZSOLT: I've seen that in some of the open-source projects that I've contributed to over the years. You can definitely tell when testing is a big part of the internal culture of the group of contributors because everything just flows way better, and there are a lot less problems most of the time. And when people understand what's important to check when they're writing these tests and when they're thinking through these problems, it does help you catch a lot that you wouldn't otherwise catch.\n\nMIKE: So, we've talked a lot about the value of collaboration. And we've talked some about this idea of a pipeline where QA developers can become developers but also the opposite. And developers working in somewhat of a QA role are able to be better developers as well, and that bi-directional communication is really valuable. \n\nTeam, I want to take that a little bit further. There was a comment that came up near the beginning of our conversation, but I think brought up something really valuable. Somebody mentioned the value of being able to reach out to the developer shortly after, at least get a response, and talk through a problem with them. I think that that's kind of a big deal. It sounds kind of trivial, like, okay, so you can talk to somebody, and they'll talk back to you. But having the mechanisms in place to make that really easy to where it's really easy to reach out and have that conversation, I think, is really meaningful. \n\nWhat experiences have you had using that opportunity to discuss things where you reach out and have that conversation? Has that been universally positive? Do you feel like that is enabling to just ask for some feedback on that?\n\nDAVID: I have a lot of feelings in that situation. [laughs] I have been in the spot where a QA writes to me or just sends me a message. And I've been like, \"Oh my God, what's wrong with my code?\" And then he's, \"Hey, your code is ready for release.\" And I was imagining something completely different, [laughter] and I was scared. \n\nAnd I've also been in the other situation where they just text me and say, \"Hey, I found something strange. Do you have a few minutes to talk about it?\" And we review it, and it's just a nice conversation. Sometimes there is a problem we need to fix. And probably, there is something we didn't see, and we need to communicate with someone who has more knowledge or more business logic and see if there is a new thing that we need to add or if there is a scenario that we didn't consider in that ticket. \n\nSo I think it's just great the way we manage that here in Acima. If there is good communication between, let's call it, both teams, it's going to be great. No matter if there is something to fix or if there is something to talk, it's going to be a great conversation. \n\nMIKE: Thank you. Any other thoughts on that topic, about that open-communication channel?\n\nJOSH: Yeah. I guess that feeds into what we talked about originally; earlier on, I guess, is when it's not an open-communication channel or when there's...you mentioned psychological safety, I believe is what you said earlier.\n\nMIKE: Yes.\n\nJOSH: These all play into each other. There's a lot of significant overlap in a lot of these areas. If there's not an open-communication channel, it's not just a company or a corporate decision that was made; it's just how people trust each other. And lack of trust often leads to shutting down and not communicating. \n\nSo that's why when we say, hey, it's a great team; you guys are all amazing; developers are great; QA is great; well, we are always communicating with each other. And I don't know of anyone who's actively angering people or causing a stir or anything. So it's like either work-related or not work-related; all those things can combine to create an open-channel communication or the opposite of that.\n\nMIKE: I think there's a lot of truth to what you said there. It's hard to detangle all the threads there, right? \n\nJOSH. [laughs] Yeah, for sure. I've experienced several of those in a couple of different places where I've worked where we actually have had meetings. When I worked there, we would have team meetings to discuss why we don't trust each other. [laughs] And I mean, it was like pin drop silence. No one would open up and say anything because it's this big, vicious cycle. You don't trust each other enough to be open and talk about why you don't trust each other. And it's bringing like an office head shrink trying to crack it open, have smaller meetings or something. I don't know. \n\nBut it seems like...I don't think there's really a solution I've ever seen to that problem other than they just reorganize teams. [laughs] They shuffle teams up, like, okay, we're going to break up teams and reassign y'all. And that works for another year or so, and then the problem comes back. \n\nMIKE: I think it has to be supported from the top. You have to have leadership that cares.\n\nJOSH: Yes. You have to have buy-in, yeah, for sure That's a great point.\n\nMIKE: If the company cares to promote good culture...and I say companies, but companies aren't a single atomic entity; they're made of people. And you know that you're at a healthy work environment when you have people that care enough to create that kind of culture. And when you find somebody like that who really cares, you might want to stick around. [laughs] It's a place that you're probably going to really grow your career.\n\nJOSH: And, I mean, career growth for sure. And I'll just say this last thing, but also, I had no concept of how heavy that kind of stress was to carry around when you go into those work environments and not be able to talk to people and know that everything you do for your job is hated. And [laughs] it's a lot of stress, and you don't notice it until you do. So by comparison, when it's not like that, yeah, stay, stay. [laughs] Why would you not?\n\nJAMES: I think Mike, you, and Josh really hit the nail on the head. I've worked for companies where they put up billboards saying how cool their culture is and how great everything is and these catchphrases. But then once you're part of that culture, it's completely synthetic, and they're trying to manufacture this culture. Whereas one thing I've always loved about Acima is it almost seems like a sleeper company, right? I got hired on here, and I was like, why isn't everybody talking about this company? \n\nAnd I come into the dev team, the engineering team, and I'm like, oh my gosh, it gets even better here. And really, there's nothing fake or synthetic about it. It's just this cool, organic culture where everybody, you know what I mean? There's no quota on the success that we can all see together. There's no shortage of success, so why wouldn't we help each other grow? \n\nIt is a very organic and natural culture as opposed to some other companies that I have been where it's kind of just lip service. They say, \"Oh yeah, we're going to have the greatest culture, and here's free snacks and energy drinks.\" But it's actually very toxic with free snacks. Whereas Acima just seems to have just this amazing culture and also free snacks.\n\n[laughter]\n\nJOSH: Can't go wrong with free snacks.\n\nMIKE: I was going to mention that when I'm interviewing people as new hires, prospective hires, I can often tell when they come from a place that had an unhealthy work environment. There's a little pause in what people say. They'll get close to saying something, and then they'll stop, and they'll pull back a little bit. There are some other signs as well. You don't know everything about the background. \n\nBut my point is that it has enough effect that you can talk to somebody who's been there, and you can just see it in the way that they talk. It affects their aspect, their countenance. And seeing that, first of all, is kind of sad. And I often notice that people in that environment have not grown as much as people in other environments because they've just not had those opportunities. They've been surviving, and they haven't seen the possibilities of growth that other people have had.\n\nJOSH: Yeah, it's like duck and cover. You don't want to be the first chicken with its head stretched out. I mean, that's really what it is. You're just like, I know what my role is. I'm going to stay here and look at my monitor and type, type, type. And I'm like, other than that, [laughs] you limit your interactions. \n\nAnd there are probably so many companies like that. That's the thing that is a little terrifying. Because you're like, oh, I'll look around and see what's available in the Valley or whatever. And you're like; you have no idea what's going to be there. [laughs] Not that I'm looking in the Valley, Jared. I'm not looking in the Valley; I'm just saying. \n\nMIKE: Well, and it is important that when you are looking to get hired that you're interviewing the company as well.\n\nJOSH: True.\n\nMIKE: And there's nothing wrong with asking some questions. \"Tell me about your company culture.\" And you'll probably pick up on some things. Right now, if you're looking for work in 2022, you've got a lot of options. If you see something that has a lot of red flags, it's probably worth moving on, taking a different opportunity because you're worth it. Your career's worth it. Your psychological well-being is worth it. \n\nWe've talked quite a bit about this idea, and I think that we've had some great discussion. We're near the end of the time that we had set aside for this. I love working with you. [chuckles] I love working with the developers I work with. I love working with the QA engineers that I've worked with. I love working with people who were QA and now have come to the development side. Working with you is a great pleasure. I hope that you feel appreciated. \n\nAnd those listening who are not within this company, I hope we can leave you with a sense of your potential that there are opportunities out there to grow. And there's real value in engineers on both the QA side and the development side. And we can learn from each other, grow from each other, and make cool things together that we wouldn't be able to otherwise. It's been great having a conversation. I'll see you next time.","content_html":"Today, we have a conversation about what the relationship should be between QA, testing engineers, and development engineers.
\n\nTranscript:
\n\nMIKE: Once again, we have another session of our podcast that doesn't have a name yet, but we'll choose one soon. [laughs] Today, we're going to have a conversation about what the relationship should be between QA, between the testing engineers, and between the development engineers. I think this is a really interesting topic.
\n\nAnd we've got a great group here today. We've got people from the QA side and from the development side, and some people who've been on both. So I think that we can have a really good discussion here and hear about the different perspectives and how people see it. I've got some strong feelings on this one. I'm looking forward to the conversation.
\n\nI am Mike Challis. I am a software developer here at Acima. I've been a software developer for a long time, a couple of decades. And I'll be hosting today. We'll go around and introduce the group here so that you know who you're listening to. Guillermo, do you want to introduce yourself?
\n\nGUILLERMO: I'm Guillermo. I've been in QA since August of last year, just about eight months. And I didn't have any experience in QA coming into this position, but in this past time, I've gained a lot of knowledge. Before that, I worked with collections in Acima. So I had knowledge with LMS and merchant portal. That's the extent of my knowledge. And now I've gathered a lot of knowledge.
\n\nMIKE: Great. And I like that you mentioned the knowledge. I think that'll help lead into some of our discussions later. Well, thank you. Jared, do you want to introduce yourself?
\n\nJARED: Yeah. So my name is Jared. I've been with Acima for about ten months now. I'm leading the QA team. And the QA team is, you know, a lot of the team members are working into a development role. And it's been very interesting for me because I've got about four years of QA experience. And I love seeing the growth and learning all the technical aspects here at Acima. So I'm happy to be here.
\n\nMIKE: Great. Eddy.
\n\nEDDY: Hey, team. As Mike mentioned, I'm Eddy. I've been in QA going on ten months now. The team is great, and I couldn't ask for a better position. So you guys are awesome, and girls.
\n\nMIKE: David.
\n\nDAVID: Hey, I'm David. I've been a software developer here in Acima for like one year now. And I have been a software developer for more than ten years. I have also been in the QA role years ago for...it's like one month or something like that. And I have helped here also. So it's a great topic, and I'm glad to be here.
\n\nMIKE: Great. Thank you. Diane.
\n\nDIANE: Hi, my name is Diane. I've been at Acima for two years and have been QA for a year. The first year I was in processing, so I have a lot of experience with merchant portal. And I came on to QA with no experience, and so I've been able to learn a lot and grow a lot in this position.
\n\nMIKE: Oh, that's great. Ramses.
\n\nRAMSES: Hey, everyone. My name is Ramses. I've been with Acima for three, three, and a half years-ish, almost four years. I've been a developer for just a couple of, I guess, about two months now, I think, full time. I was in a technical support role for a little over a year, and during that time, I did a little bit of QA, but it was just kind of on and off.
\n\nMIKE: Great. And you might offer some interesting perspective as well, coming from support, not exactly QA but a similar role. Zsolt, do you want to introduce yourself?
\n\nZSOLT: Yes. Hello. I'm Zsolt, and I'm the newest member of the QA team. I've been on the team for about three weeks now. I've really enjoyed working with the team so far.
\n\nMIKE: Great, yeah. We love having you on the team. Afton.
\n\nAFTON: I'm Afton Call, and I have been in a few of these episodes, so I might be somewhat familiar. I have been a software developer for just shy of four years here at Acima, and that is my entire career. [laughs]
\n\nMIKE: Great. Melissa.
\n\nMELISSA: Hi, I'm Melissa. I've been at Acima for six years now. I also started on the operation side of things and then moved into QA with little experience. I had been pursuing my computer science degree for maybe a year at that point and had also done the mentorship that Afton led. And now, I'm a software developer, and I've been doing that for the last ten months now. Happy to be here.
\n\nMIKE: Great. Josh.
\n\nJOSH: I'm Josh, and I've been at Acima for a little over seven months now, I think. But I came to Acima with about ten years of experience in QA in different roles, mostly in Utah. I'm originally from Washington State. So I still think of that as home even though I've lived here for quite some time now. So that's me.
\n\nSo I'm right now working with the QA team, and we have a really good team. I'm extraordinarily lucky because I've worked on some that don't communicate as well, work together as well. So yeah, for lots of reasons, it's a really good team.
\n\nMIKE: Great. And you probably have some interesting perspective there of seeing things not work so well.
\n\nJOSH: I obviously don't focus on those. But yeah, obviously, there's group dynamics and all that. It's very interesting to me.
\n\nMIKE: Thank you. James, do you want to introduce yourself?
\n\nJAMES: Hey, yeah. I’m James Murphy. I'm on the QA team. I have been with Acima for a little under three years now. Started off in sales, went into account management, did that for about two years. And then, I've been with the QA team for about eight months. Always been interested in technology, development, things like that, and QA was a great opportunity for me to really dive into it headfirst. And it's been a little like drinking out of a firehose, but it's been awesome. I love it so far. Great team. Really have enjoyed my time here with the engineering side of things.
\n\nMIKE: Thank you. And finally, Brian, want to introduce yourself?
\n\nBRIAN: I've been with the company for three and a half years, I think. I started in QA when it was a two-person department and was there for about two years. And I've been in development about a year and a half.
\n\nMIKE: Great. Well, let's start our discussion. We've got a diverse group here, and people from QA, and people in engineering, the development side of engineering, and people who've bridged the divide between the two. So I think we will have a great discussion. I wanted to start by talking about an interesting experience I had quite some years ago.
\n\nI had a bus driver when I would ride to work who was an adjunct professor at a local university. We can have another discussion here about how adjunct professors are underpaid, and they have to drive a bus to make their living [laughs] on the side. But we had some fantastic conversations. Previously being a university professor, he had been a QA engineer at a company. And we had some interesting conversations about what a QA engineer should be. And we'd sit on the bus together and chat. Sometimes it was just the two of us, so we had some great conversations.
\n\nAnd one thing that he talked about is that companies he had worked for the QA team and the developers were very adversarial. They hated each other. The developers would think that their code was perfect and hand things off to the QA team. And the QA team thought that everything that the developers wrote was trash. They would always send it back and tell them about all the problems with it.
\n\nAnd in the end, a lot of times, the developers would just end up ignoring the QA team, or the QA team would try to send ultimatums to say, "We're not going to let this go out." And it was a really toxic environment that he talked to me about. Where I was at the time didn't even have a QA team.
\n\nBut sometime later, I worked at a place where we hired some people into QA from out in support and found this familiar story. And one of the developers who became a QA engineer really applied himself, became really good, and ended up asking to become a manager when we had a bad experience with the existing manager, and he had just disappeared one day. And I supported, and he ended up being one of the best managers I've ever had.
\n\nWent on to become a software architect and is currently playing a prominent role at another software company. He took that journey from being out in support to being the lead engineer at multiple companies. And seeing that transition, seeing how great it was working with him, gave me a lot of perspective as to what QA could be versus what my bus driver had experienced, which is really awful.
\n\nThat opportunity that QA had to work closely with developers ended up not only building better software, I think, but also giving the QA team an opportunity to really bridge that divide between QA and development and sometimes crossover. And I thought that was a great transition for this developer. I'm not going to mention his name since he's not here [laughs]. I don't want to name him without him present.
\n\nBut seeing that success, as well as a number of successes here at Acima, in particular, of people who have come over from QA and had a great time in development, I had some strong thoughts about how important it is for the developers and the QA team to work together as peers, as a combined team that is collaborating with different strengths that compare their different strengths in order to produce great software.
\n\nWith that introduction, I'd like to have an open-ended discussion here. Hopefully, there are some seeds there for us to keep talking. What do you all think the relationship between QA and developers should be? And you certainly have some context here. And some of you have some context with other companies as well. So I will quit talking and let others speak.
\n\nJARED: I really wanted to jump in and say this. Having been in a couple of other companies and now coming into Acima, I think it's incredibly impressive the way that the developers put into unit testing. Every single PR I get has a unit test, and that means the developers are more test-minded. And so I think it's really easy for the QA team here to get along with the developers because everybody has testing in mind.
\n\nAnd I've seen places where testing is like the last of people's worries, and then some things get pushed out, production breaks, things happen, and it just doesn't work very well. So I have to say that about Acima. Everybody is test-minded, so it makes the environment really easy.
\n\nJOSH: I want to add to what Jared just said. When developers and QA are both test-minded, nobody is the official...or no one is seen company-wide or even department-wide as the gatekeeper for the release of any product, or feature, or code. When it's viewed the other way, I don't want to say toxic, but maybe it's not as balanced. If developers aren't as involved in testing, then it's all on QA. And as a result, if there's something ever wrong, it's easy for that message to spread through the department that QA doesn't want to release something, so it's like we're the bad guys.
\n\nWe get all the blame but none of the credit because if it goes out live, developers are like, yay. [laughs] So I like the mix we have here at Acima, and that's when it's like, we're integrated. And we don't necessarily have individual teams within the department, but we all work together all the time on every PR. So we all have equal stake, and I really like that.
\n\nMIKE: That's an interesting point you both raised about developers being interested in testing as well. What happens when developers aren't interested in testing? Can QA save that situation?
\n\nJOSH: I think short term maybe like from a PR to PR basis, but long term it sees more consequences.
\n\nDAVID: I think that's out of mindset or also experience because I've been working for places where developers hate QA. Those developers are...because they don't like to test. They just code, and they just test the happy path. And they just send everything to QA. And then the QA guy starts testing, and they see, oh, there's a bug here, and boom, it rejects the code and rejects the ticket. And then the developer is, no, but it's fine. And they...no. Did you sit with the QA? And they say, "Oh no, it's right."
\n\nAnd they start hating the developers just because they were unable to test their codes like they were just in the happy path, and they were unable to see beyond that. So I've been in that place. But I think that's also a matter of experience. Because for example, in my place, I love when QA finds a bug because I know that code is not going live. He just saved me from a real problem. So yeah, [inaudible 12:24]
\n\nMIKE: There's a text post here: it works on my machine. [laughs] I think you hit on something critical there, David. Sometimes I think that we misunderstand our job as developers. We think that our job is to write code, and I would argue strongly that that's not our job. Our job is to solve business problems. And if we misunderstand what our job is, then...I wrote all this code. This code is wonderful. Why aren't you thinking that my code is wonderful? [laughs] We start taking it personal.
\n\nAnd there are some issues there around psychological safety as well that I think are important to recognize that you need to be able to have feedback without it being a personal attack. But this idea that the code is our output is, I think, really problematic. What we're trying to do is solve the problem. And if we're all trying to solve the problem, then code is part of the solution, but it's a collaborative effort to solve the problem.
\n\nAnd as you said, David, if somebody finds a bug, and I feel the same way, like, oh, thank you for saving me because we're working together to solve the problem, not working adversarially to push out code that then somebody's going to criticize. And we just have better outcomes. It means that we're all working for the same goal rather than for different goals. Neither of which goals really is one person's goal is to block the code, and the other person's goal is to get out code. Neither of those are really solving the real problem, which is the business is trying to help people out with their software, provide a feature for customers.
\n\nAFTON: This surprises me to hear how many experiences people have had where developers are just kind of, here's the happy path, here you go and then sending it off. And maybe this surprises me because I've grown here at Acima [chuckles], where testing is a big part of our process and our mindset. But when I write code, I want it to be foolproof. I want you to be able to throw anything at it and know it's going to work. Like, this can handle whatever you throw at it. That's a big part of what makes me feel so satisfied to produce it.
\n\nIt just surprises me that there seems to be so much where the happy path is all they're thinking about because all the different angles is like, yeah, I feel like I'm here to solve the problem, not to present just a happy path. That's interesting to me.
\n\nGUILLERMO: Kind of what Afton said is I think I'm fortunate enough to start QA in Acima versus another company and getting that bad taste of QA somewhere else. I do agree I can reach out to any of the devs tickets that I'm working on and say, "Hey, I'm finding this." And they respond rather quickly, and they'll work on the machine. And we get to the root of the problem and take it out.
\n\nJOSH: I think a lot of it in my experience...I've worked at several companies in the last decade here, and it's in QA. So they've all had unique arrangements, both in departments and how teams are set up together. And what you're describing, what Guillermo just touched on from my experience, seems to happen in teams that are divided where there's the QA...oh, you're on the QA team, okay, I'm on the dev team.
\n\nThose kinds of teams, you end up finding developers who you work well with and then just avoid the rest of them. And they probably do the same for QA people as well, someone who can test their stuff and get it released as quick as possible, who isn't going to be a pain to work with and find bugs, or however a lot of that is viewed.
\n\nThat stuff dies away when you integrate, at least in my experience, when you work like the teams are divided like 60% developers, 40% QA, or 70-30. When you're on the same team, you're in the same meetings. You're planning together. You're grooming stories together. You're understanding what the work is. That animosity, for the most part, dies off. So in a way, the way it's set up here at Acima kind of plays to that same...falls in that same category. Like you said, Mike, we're all trying to produce quality software that solves business problems. We're not trying to get done the fastest. We're trying to get it right.
\n\nEDDY: To chime in a little bit here, I feel like there's a stigma in the industry that I've read on, and I've heard from other people's experiences how the relationship between QA and developers can be rocky at times, whether that's communication or not. I can talk from personal experience working at Acima that that's never been the case.
\n\nI feel like it's crucial where the communication and the confidence, you know, to be able to provide feedback, whether it's good or bad, whether it's from QA to developers or vice versa, is really important. And I think that speaks for the foundation and the team dynamic that Acima has grown and groomed that all of us...and I guess I can speak for all of us where the communication is great between both parties.
\n\nJARED: If I could actually interject on that as well, the communication aspect I think is so important because if you think about developer to QA, oftentimes, there is a huge discrepancy in technical understanding. So the devs do what the devs do, and the QA does what the QA does. And oftentimes, devs will hand QA a ticket, and QA will not know what it's supposed to do, not understand what's going on.
\n\nAnd so I think if you look at it from...the communication needs to be polite in a way where the devs can't go and say, "You're stupid. I wrote this code. I know how it works. This is how it's supposed to work." And then the QA, if they find an issue, they shouldn't go to the dev and say, "You're stupid. This doesn't work. This is not how it's supposed to work."
\n\nI think wording is very important where the QA shouldn't come and attack. But they should ask, like, "Hey, I'm seeing this. Is this how it's supposed to function? How am I getting this result?" And the dev can then also walk him through how it's supposed to work. I've seen a little bit of that in my experience. I think that's what creates the animosity, the toxicity, and the divide between the two. But the way that you word your questions, I think, is very important.
\n\nJAMES: This just reminds me of a situation I got myself into. I was fairly new to the QA role. And I was doing a PR where, Melissa, I think you and Brian had collaborated on it. I did something. I did like a database rollback instead of...I don't remember exactly what I did. But I completely threw everything sideways by accident. [laughs] And so I went to Melissa and Brian, and I was like, "Hey, can you help me understand what I did?" And they were super nice about it.
\n\nAnd they kind of just explained the intended testing was this, but this brings up an interesting point of maybe we should set precautions against this. And I felt like an idiot because I completely messed up the testing and kind of threw a wrench in things. But Brian and Melissa were like, "No, no, like, it's an interesting way of looking at it," and kind of took that perspective. And it almost just gave me the confidence of like, oh, cool, I can talk to these developers.
\n\nAnd if they had come to me and been like, "Hey, stupid head, that's not what we said to do," but they were so cool about it and just friendly. And they walked me through the processes, and the differences, and the different styles of testing and stuff like that. And it just kind of created this very friendly environment, even though I had stepped in it. That is something that stood out to me where it's just like, really, it was a great experience for me where it could have just been awkward or embarrassing for me. So just going along those lines.
\n\nBRIAN: Yeah. Having a new user who's totally brand new to the whole thing is such a good perspective to get as a developer because we get so nose to the grindstone, so to speak. We're too close to the metal; you know what I mean? And so that's why when you run it...I don't even remember the property there.
\n\nBut I love finding those weird things, and it's because someone who's brand new to our tech stack and brand new to the problem we're solving, it's like, they actually have a really good point of view because they're going to do what the most intuitive to them is. And that's why I was like, so interesting for you to find a problem that we're like, yeah, everyone is just so used to migrations working this way. Put it in front of someone brand new, and you're like, oh, well, what did their intuition say about it?
\n\nJAMES: Wasn't it like I was supposed to try to do a seed migration then a seed rollback, and I ended up doing a database rollback or something like that? But again, yeah, [laughs] I did --
\n\nBRIAN: I don't remember at all. [laughs]
\n\nJAMES: I just remember you guys were super cool about it, and you helped me understand what the difference was in that instance. And it helped me grow as a QA rep. And it was a good experience for me just learning.
\n\nMELISSA: Yeah. And I think that brings up a good point of investing in your QA. Because if we take the time to actually explain things and help you understand different processes, then that's only going to benefit us in the long run because then you can think of different scenarios to test or how to manipulate data in a certain way. So I think it's really important to take the time to explain things to QA.
\n\nJAMES: I can vouch for that. That's something that's helped me out a ton, just taking 15 minutes and saying, "Well, actually, this is why this is doing this, and this means that." And I've always really appreciated that.
\n\nBRIAN: Cool. And that's one of the benefits of our pipeline from QA to dev is me and Melissa; I mean, that was like just a year or two ago for the two of us. We kind of understand QA's point of view. We definitely understand being new to the Acima tech stack. And I think that's one benefit of...not saying that people who don't do QA are bad developers, but I think that is one good benefit of being a QA first and then being a developer is your perspective. You kind of have a little bit more empathy, I feel. And you kind of view QA as the goalies for your team. You would never get on the field without your goalie.
\n\nEDDY: Mike, I think if I can interject here, you've had skills clinic before where all we did is talk about the fear of sounding stupid, for lack of a better term. And I think a lot of us, when we first get started, you know, get in our heads about like, man; I don't want to sound dumb when I message this developer. Or they must be really busy; I don't want to take time away from them, from work asking something that's really simple to fix.
\n\nBut the environment, again, that Acima has groomed, speaking for me at least, is that that's never the case. Every time I've messaged someone about a concern that I've had that has been met with generosity. It's been nothing but great experiences.
\n\nMIKE: I'm really happy to hear that. [laughs] That's immensely gratifying, I'll say that. That is exactly what I'd want to cultivate. The technical word that I would use for that...well, it's two words, psychological safety, the technical term, and there's a good body of research. Well, first of all, I just thought on a personal level, I think it's important to treat people nice. That's backed up by research, and you can look this up.
\n\nGoogle did some research some years back as to what made their teams most effective. There were a few contributing factors, but by far, the most important factor they found was that psychological safety, when people feel free to express themselves, to be themselves, to ask questions, to ask uncomfortable questions, then the team is much more successful.
\n\nBecause all of us, you know, you talked about doing something that made you feel dumb as a QA developer. Well, developers do that, too. We do things that we look back on and think, oh, why did I do that? All the time, because we're human. We make mistakes. Closely connected to creativity, you know, we do stuff that is unusual. And a lot of times, it doesn't work, but sometimes, it's brilliant. And we have to be able to be there for each other in order for those brilliant things to come through.
\n\nI also love what Melissa said. She said, "It's an investment." It might take 15 minutes to explain something to the developer that's testing your code, to that engineer who's testing your code, and that is a cost; that's time. But if you pay that, it will be paid back with interest. Making that investment in those relationships and in helping people develop those skills will grow your opportunities in the future. And my experience is that time is almost always worth it.
\n\nI mean, there are times when something's on fire, [laughs] and you might have to defer the conversation. But that doesn't mean the conversation shouldn't happen. Once the fire is out, well, okay, the fire is out. Let's go talk. It is worth asking those questions to develop that. It looks like, Diane, you had something to say about that, about asking questions.
\n\nDIANE: I get nervous to ask questions all the time. But one thing I do go by is that if I don't ask this question, even though I may feel like it's dumb, I'm not going to get the answer. I'm not going to know how to do these certain tests. So it's really important to, even if you feel like it's dumb to ask the question.
\n\nJAMES: And just to kind of piggyback on that as well, I've found personally, if you have a question, chances are there's at least one or two or a lot of other people that are going to have that same question or aren't 100% concrete on the answer. So I've always tried to have that mindset of not even just asking the question for myself but asking that question for other people on the team who might have that same question.
\n\nMIKE: I would offer that, in my experience, asking a question does not make you look stupid. It makes you look curious and eager and interested. I want to work with people who are curious, who are interested, who want to know what's going on because then I know that their skills will be growing. Honestly, when I'm interviewing people, and I've talked to many other developers who interview, who have said the same thing: one of the things they're most looking for is people who are curious. We're in an industry where we don't know all the answers; none of us do. But people who are curious will find the answer.
\n\nBRIAN: It's a pretty common saying, I guess, but the only stupid questions are the ones you don't ask. And it's important to keep that into perspective because, as Diane was touching on, if you don't ask the question, you're never going to know the answer, and so you'll just be in the dark, and you don't get anywhere with that.
\n\nMIKE: And then you're stuck, right? Being stuck is not good for your career. [laughs] I have to say that. It's not good for anybody. It's kind of the definition of a bad position to be stuck. If you're in a company that's interested in getting things done, that's the last thing that they want. And if you ask somebody, they're going to be interested in helping you out.
\n\nAgain, there are unhealthy companies. There are unhealthy cultures. But in companies that care, and I think it's probably most, what you'll find is somebody is going to want to work with you because they want to solve the problem. And you're going to do that better together.
\n\nMaybe to pivot a little bit, one thing that we've done a lot here at Acima, and as I mentioned before, I've seen this happen in other places, but we've really tried to emphasize it is we try to have a [inaudible 27:10] boundary, an open door, a pipeline so that QA engineers have an opportunity if they're interested to build development skills, to actually start working on code, taking tickets and writing code, getting that experience and building that over time so that they can move into development if that's something that interests them.
\n\nI personally think that that has been a fantastic thing because it gives people opportunities. It allows us to work with people that we already trust and know are extremely talented and already know the business. It just seems to be a win all around. I think that that's a fantastic thing that we've done. And again, it's not only here that I've seen it, but I think it's a wonderful thing that we should do, that we have done, and that everybody should do if they have that opportunity.
\n\nWhat do other people think about that pipeline idea of there not being a hard boundary between QA and developer but trying to spread that role around so that QA engineers can do some development if they so choose and even move over into development?
\n\nJARED: For me personally, I think nothing builds a good company culture better than the possibility of upward mobility. There are a lot of people that go and get a job, and the only thing that they know how to do to change their position is to get a different job. And some people have all that knowledge and that experience with one company, and you're using that software internally. And if you're able to move into a new position and still retain that knowledge and within the company, that makes you not only more valuable to the company but also to everyone else around you.
\n\nBecause I think there is a massive turnover cost to losing employees that have this tribal knowledge of your software, and they just go to another company versus retaining them and keeping them and moving them in other positions.
\n\nEDDY: I just love the perception that I've gotten for the past ten months that I've gotten here. And it's nothing but good things. And the fact that Acima is willing to invest within goes to show the environment and the company that you work for and the possibilities of happiness, of willingness to stay longer within the company.
\n\nI even heard of situations where people leave Acima, and they come back because of the environment that you guys provide, and I think that's really important. And I love the fact that Acima is willing to invest an hour or two a day to work on skills that we're wanting to and pay the debt back to the company.
\n\nMELISSA: This pipeline works both ways for dev and QA like; it improves both sides of the process because developers come in with that more test-focused mindset then produce better code because they're trying to think of all the scenarios. And then also it benefits QA because they start to understand the code that they're testing. So they can actually look at the code and see scenarios that maybe the developer didn't think about. So I think it goes both ways. I think it just benefits everyone all around.
\n\nEDDY: One thing that I love as well is...this was kind of explained to me when I jumped into the QA position is really that it's on me to learn. Whatever I put into this job, I'm going to get out of this job 100%. Coming from a sales background where I could be the top sales rep or hitting my quota every month, and I just keep doing the same thing every day, it's refreshing because, really, in the development world and in the QA position, I feel like whatever I put into this job I'm going to get out, Mike, like you said, with interest. I'm going to get back everything that I put in with interest.
\n\nSo it really is a cool environment where the developers are helping QA, and QA, in some ways, are helping the developers, and there's this collaborative effort. But also, it's kind of on us to be self-taught and to learn what we need to know to be more effective in these positions and to master our craft, if you will.
\n\nAFTON: I'm just going to say I have loved watching people move into development from QA, not only because I love being part of the mentoring and helping and teaching because that's something I personally find a lot of joy in, but the quality of developers, like Melissa was saying, who have learned how to ask all the questions, and test all the scenarios, and think very test minded has blown my mind actually to see these developers who were my QA and then they're my peers, and they're reviewing my code.
\n\nAnd they come up with great questions that challenge the work I'm producing and help me to become better. And also, having the opportunity to mentor people as they're coming in helps me to improve myself, explaining and thoroughly understanding why I'm doing it the way I'm doing it. It's just good all around.
\n\nMIKE: I couldn't agree more. [laughs] Absolutely. I'm interested in this idea that I think, Melissa, you mentioned and others have touched on it. It makes us better developers as well when we are test-minded that not only were we thinking about QA coming over to development but development doing some of the QA role.
\n\nAs a company, we have a policy, and it may not be exactly the same across all teams. Certainly, our team has a policy where a developer will test the code first before it goes to QA. We test within development before we send it over to QA. And we also have a process of documenting the tests so that we're thinking through the testing process enough that we can document it well enough for another developer and a QA engineer to test it.
\n\nAnd thinking through the problem, like writing up those instructions, is really good for poking holes in your code [laughs] and your thinking as you're going through that like, oh, wait, I missed this. And where our goal is to produce great software, that's a wonderful moment where the light bulb goes on, like, oh, wow, I forgot to do that. Or, oh, look at this thing that broke, or, wait, maybe I haven't tested that. I should check that and add that to the instructions.
\n\nJust going through the process of explaining what needs to be tested, I think, goes a long way, as well as doing the testing itself beyond what unit testing can do. Unit testing is fantastic. There is something to be said for manual and integration tests. They catch things in an integration sense that individual unit tests would not. Have other people seen this idea of a testing culture on the engineering side, improving your code?
\n\nZSOLT: I've seen that in some of the open-source projects that I've contributed to over the years. You can definitely tell when testing is a big part of the internal culture of the group of contributors because everything just flows way better, and there are a lot less problems most of the time. And when people understand what's important to check when they're writing these tests and when they're thinking through these problems, it does help you catch a lot that you wouldn't otherwise catch.
\n\nMIKE: So, we've talked a lot about the value of collaboration. And we've talked some about this idea of a pipeline where QA developers can become developers but also the opposite. And developers working in somewhat of a QA role are able to be better developers as well, and that bi-directional communication is really valuable.
\n\nTeam, I want to take that a little bit further. There was a comment that came up near the beginning of our conversation, but I think brought up something really valuable. Somebody mentioned the value of being able to reach out to the developer shortly after, at least get a response, and talk through a problem with them. I think that that's kind of a big deal. It sounds kind of trivial, like, okay, so you can talk to somebody, and they'll talk back to you. But having the mechanisms in place to make that really easy to where it's really easy to reach out and have that conversation, I think, is really meaningful.
\n\nWhat experiences have you had using that opportunity to discuss things where you reach out and have that conversation? Has that been universally positive? Do you feel like that is enabling to just ask for some feedback on that?
\n\nDAVID: I have a lot of feelings in that situation. [laughs] I have been in the spot where a QA writes to me or just sends me a message. And I've been like, "Oh my God, what's wrong with my code?" And then he's, "Hey, your code is ready for release." And I was imagining something completely different, [laughter] and I was scared.
\n\nAnd I've also been in the other situation where they just text me and say, "Hey, I found something strange. Do you have a few minutes to talk about it?" And we review it, and it's just a nice conversation. Sometimes there is a problem we need to fix. And probably, there is something we didn't see, and we need to communicate with someone who has more knowledge or more business logic and see if there is a new thing that we need to add or if there is a scenario that we didn't consider in that ticket.
\n\nSo I think it's just great the way we manage that here in Acima. If there is good communication between, let's call it, both teams, it's going to be great. No matter if there is something to fix or if there is something to talk, it's going to be a great conversation.
\n\nMIKE: Thank you. Any other thoughts on that topic, about that open-communication channel?
\n\nJOSH: Yeah. I guess that feeds into what we talked about originally; earlier on, I guess, is when it's not an open-communication channel or when there's...you mentioned psychological safety, I believe is what you said earlier.
\n\nMIKE: Yes.
\n\nJOSH: These all play into each other. There's a lot of significant overlap in a lot of these areas. If there's not an open-communication channel, it's not just a company or a corporate decision that was made; it's just how people trust each other. And lack of trust often leads to shutting down and not communicating.
\n\nSo that's why when we say, hey, it's a great team; you guys are all amazing; developers are great; QA is great; well, we are always communicating with each other. And I don't know of anyone who's actively angering people or causing a stir or anything. So it's like either work-related or not work-related; all those things can combine to create an open-channel communication or the opposite of that.
\n\nMIKE: I think there's a lot of truth to what you said there. It's hard to detangle all the threads there, right?
\n\nJOSH. [laughs] Yeah, for sure. I've experienced several of those in a couple of different places where I've worked where we actually have had meetings. When I worked there, we would have team meetings to discuss why we don't trust each other. [laughs] And I mean, it was like pin drop silence. No one would open up and say anything because it's this big, vicious cycle. You don't trust each other enough to be open and talk about why you don't trust each other. And it's bringing like an office head shrink trying to crack it open, have smaller meetings or something. I don't know.
\n\nBut it seems like...I don't think there's really a solution I've ever seen to that problem other than they just reorganize teams. [laughs] They shuffle teams up, like, okay, we're going to break up teams and reassign y'all. And that works for another year or so, and then the problem comes back.
\n\nMIKE: I think it has to be supported from the top. You have to have leadership that cares.
\n\nJOSH: Yes. You have to have buy-in, yeah, for sure That's a great point.
\n\nMIKE: If the company cares to promote good culture...and I say companies, but companies aren't a single atomic entity; they're made of people. And you know that you're at a healthy work environment when you have people that care enough to create that kind of culture. And when you find somebody like that who really cares, you might want to stick around. [laughs] It's a place that you're probably going to really grow your career.
\n\nJOSH: And, I mean, career growth for sure. And I'll just say this last thing, but also, I had no concept of how heavy that kind of stress was to carry around when you go into those work environments and not be able to talk to people and know that everything you do for your job is hated. And [laughs] it's a lot of stress, and you don't notice it until you do. So by comparison, when it's not like that, yeah, stay, stay. [laughs] Why would you not?
\n\nJAMES: I think Mike, you, and Josh really hit the nail on the head. I've worked for companies where they put up billboards saying how cool their culture is and how great everything is and these catchphrases. But then once you're part of that culture, it's completely synthetic, and they're trying to manufacture this culture. Whereas one thing I've always loved about Acima is it almost seems like a sleeper company, right? I got hired on here, and I was like, why isn't everybody talking about this company?
\n\nAnd I come into the dev team, the engineering team, and I'm like, oh my gosh, it gets even better here. And really, there's nothing fake or synthetic about it. It's just this cool, organic culture where everybody, you know what I mean? There's no quota on the success that we can all see together. There's no shortage of success, so why wouldn't we help each other grow?
\n\nIt is a very organic and natural culture as opposed to some other companies that I have been where it's kind of just lip service. They say, "Oh yeah, we're going to have the greatest culture, and here's free snacks and energy drinks." But it's actually very toxic with free snacks. Whereas Acima just seems to have just this amazing culture and also free snacks.
\n\n[laughter]
\n\nJOSH: Can't go wrong with free snacks.
\n\nMIKE: I was going to mention that when I'm interviewing people as new hires, prospective hires, I can often tell when they come from a place that had an unhealthy work environment. There's a little pause in what people say. They'll get close to saying something, and then they'll stop, and they'll pull back a little bit. There are some other signs as well. You don't know everything about the background.
\n\nBut my point is that it has enough effect that you can talk to somebody who's been there, and you can just see it in the way that they talk. It affects their aspect, their countenance. And seeing that, first of all, is kind of sad. And I often notice that people in that environment have not grown as much as people in other environments because they've just not had those opportunities. They've been surviving, and they haven't seen the possibilities of growth that other people have had.
\n\nJOSH: Yeah, it's like duck and cover. You don't want to be the first chicken with its head stretched out. I mean, that's really what it is. You're just like, I know what my role is. I'm going to stay here and look at my monitor and type, type, type. And I'm like, other than that, [laughs] you limit your interactions.
\n\nAnd there are probably so many companies like that. That's the thing that is a little terrifying. Because you're like, oh, I'll look around and see what's available in the Valley or whatever. And you're like; you have no idea what's going to be there. [laughs] Not that I'm looking in the Valley, Jared. I'm not looking in the Valley; I'm just saying.
\n\nMIKE: Well, and it is important that when you are looking to get hired that you're interviewing the company as well.
\n\nJOSH: True.
\n\nMIKE: And there's nothing wrong with asking some questions. "Tell me about your company culture." And you'll probably pick up on some things. Right now, if you're looking for work in 2022, you've got a lot of options. If you see something that has a lot of red flags, it's probably worth moving on, taking a different opportunity because you're worth it. Your career's worth it. Your psychological well-being is worth it.
\n\nWe've talked quite a bit about this idea, and I think that we've had some great discussion. We're near the end of the time that we had set aside for this. I love working with you. [chuckles] I love working with the developers I work with. I love working with the QA engineers that I've worked with. I love working with people who were QA and now have come to the development side. Working with you is a great pleasure. I hope that you feel appreciated.
\n\nAnd those listening who are not within this company, I hope we can leave you with a sense of your potential that there are opportunities out there to grow. And there's real value in engineers on both the QA side and the development side. And we can learn from each other, grow from each other, and make cool things together that we wouldn't be able to otherwise. It's been great having a conversation. I'll see you next time.
","summary":"Today, we have a conversation about what the relationship should be between QA, testing engineers, and development engineers. ","date_published":"2022-10-26T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/094bdb0b-9810-4678-a6dd-2894bd7f785e.mp3","mime_type":"audio/mpeg","size_in_bytes":39023846,"duration_in_seconds":2653}]},{"id":"b78248b9-94d6-4ba8-83af-1027d054a35c","title":"Episode 2: Overcoming Impostor Syndrome","url":"https://acima-development.fireside.fm/2","content_text":"Do I belong here? Am I good enough of a developer? These are questions someone with impostor syndrome may ask themselves. Today we discuss how we overcome these hard feelings.\n\nTranscript:\n\nMIKE: Welcome again to our podcast that still doesn't have a name. I'm Mike Challis. I'm hosting today. Also with us, we have Afton. Afton, do you want to introduce yourself?\n\nAFTON: Yeah. I'm Afton. I've been developing for four and a half years professionally: about. Happy to be here.\n\nMIKE: Ramses, would you like to introduce yourself?\n\nRAMSES: Hi. I'm Ramses. I've been developing for a little bit about a year now, professionally, for just a couple of weeks.\n\nMIKE: So this is a great group. Maybe let me introduce myself a little bit. [laughs] I'm Mike Challis. I've been doing development for a couple of decades now. [laughs] So we've got a perfect mix for today's topic. \n\nToday we are going to be talking about impostor syndrome and how you overcome it. And this is perfect because we've got a mix of people at different spots in their career. I've been doing this for, like I said, a couple of decades. And then we've got Afton, who's getting...what do we say? Is that mid-career? You know, into your career. \n\nWe've got different places in our careers, but we're all...I'll lead out by saying sometimes I feel like I have the question in my mind: do I really belong here? Am I doing okay? I think that's something that we all deal with. It's something that I regularly deal with. I think, well, am I really doing this okay? Sometimes I feel like I'm just winging it all the time. I'm not sure if I'm doing it right. And that's a hard thing. You sometimes don't have landmarks to go by. So maybe I'll go in the same order as before. Afton, do you find this feeling sometimes?\n\nAFTON: Yeah. I've been curious as to why that's so prevalent in this field. And I don't have experience in other areas, so I don't know if it's more engineering is just, you know, problem-solving, figuring things out, creative, if that kind of field is what gives the right environment for this feeling. But yeah, I felt it a lot more as I was younger in the career. \n\nAnd then I was actually just sitting here thinking, well, I haven't had that feeling in a while. And I was like, wait, you just said, \"Oh, should I even be here?\" And I was like, oh yeah, I thought that two days ago. [laughter] Yes, I do have that thought a lot. It's not debilitating to me. It used to be a little bit more so. But it does cross my mind regularly.\n\nMIKE: Ramses, you just started as a full-time developer in the last couple of weeks. How are you feeling?\n\nRAMSES: Generally pretty good. I always have that sense of like, do I belong here? Am I good enough of a developer to be a part of it? But I think that's part of the overall experience is learning and making those mistakes, so you just continue to learn.\n\nMIKE: I love how you said that, making those mistakes, so you continue to learn. There's a suggestion there that you're not going to be perfect, that you're going to make mistakes. And nobody's over here judging you. That's a part of the process. \n\nI'm also really interested in what Afton had to say. You wonder if this field, because of the problem-solving aspect of it, creative problem solving lends itself to that imposter syndrome. I think that's an interesting question. You started to explore that a little bit. Do you have an opinion on that, Afton?\n\nAFTON: I mean, this is my first career, so I don't have other career types jobs to compare it to. But other jobs I have had in my life, I've never felt this way. They give you an exact set of this is what you need to do, and then you did exactly that. [laughs] There wasn't a lot of unknown. There wasn't like, oh, is this my role or isn't it? It was always very clearly defined. This is exactly what I expect from you, and that was it. So I've never felt it before in a job, and this is the first time.\n\nSo I do really think that, I mean, we know what our job is; it's to take what the business needs, find a way to solve problems and produce something to better the experience for our own company and our customers. [laughs] But there's not an exact right way to do anything. There are lots of options. It takes a lot of work to figure out what's going to work best. And you've got to collaborate with a lot of people to make projects and features happen. So I think all of that openness to what's the answer, there isn't an exact answer. I think that's a big part of what creates this feeling.\n\nMIKE: I think you're right. It's been a while. I did construction work mostly before I started doing software. It was a family thing. I kind of got into it as a kid. It feels like when you can see what you're working on; there's a clear goal. You got to build a wall. You got to frame a wall. There's really just one way to do it. You maybe learn a trick, and then you use that trick for the rest of your life. You build the wall laying down; you stand it up. But beyond that, it's very obvious when you've got it right. \n\nAnd you can look at it like, hey, look at this wall I built. I did that right. [laughter] Or maybe you didn't do your [inaudible 05:02] very well, and so you really had to put a lot of mud in between the gaps. And you're like, oh, that was kind of bad; I'll have to do better next time. It's really clear whether you're doing well or not. I think it's a lot less clear here in software. You build something, and hopefully, you solved a need. There are no guardrails. It's just this wide-open field. You just try to figure it out.\n\nAFTON: That reminds me of when I was...I went and spent a couple of weeks my first year here on a different team. And we were building this kind of...just spinning up this little project to solve one problem, and then I was going to go back to my team. And while I was there, I was the only Ruby developer. And they said, \"Hey, this is what needs to be done.\" And I built something that worked. And then I was like, \"So is this okay? What do you think about this? They're like, \"Does it work?\" I was like, \"Well, yeah, I think so.\" \"Well, then, it's great.\" [laughter] I was like, \"Oh, okay.\" [laughs]\n\nMIKE: You also said something interesting before. When you described the job, you didn't say the word code. That was dead on.\n\nAFTON: [laughs] \n\nMIKE: We're here to solve problems, and that's it, right? \n\nAFTON: Yeah.\n\nMIKE: We're here to solve business problems, and that may or may involve writing code. In fact, it seems like we're all most happy when we come up with a solution to the problem that doesn't require us to write any code. \n\nAFTON: [laughs]\n\nMIKE: We're just sticking a couple of things together already there, and, hey, it already works, and everybody's happy.\n\nAFTON: Yeah, that's really interesting. And I do think of it as a problem-solving job. But you have to know how to code; I mean, it involves writing code. So yeah, that's an interesting shift in thinking about maybe how much code we don't write sometimes. [laughs]\n\nMIKE: Well, and you've been around long enough; how do people feel when they get to delete code?\n\nAFTON: Oh, deleting code is great. [laughs] Oh, man, you feel like you have a junk drawer, and you get to clean it out. It feels so good.\n\n[laughter]\n\nMIKE: It's like the best feeling in all of software. And it's, I can delete stuff? Yes! [laughs] And it solves a problem at the same time once you really understand what we're doing. You recognize that it's not about writing code. It's about exactly what you said; it's about solving problems. \n\nAnd I think that also leads to the main thrust of what we really wanted to talk about today, which is we've talked about having impostor syndrome seems to be something we all deal with. But the real question is, how do you deal with it? How do you avoid having that constant, nagging feeling that I don't belong here; I'm not good enough; I can't do it? I like how you led into some solutions, Afton, because you stressed, well, yeah, we're here to solve problems. \n\nI've got a one-year-old, and I've been watching him recently learn how to walk. This morning, he figured out how to open the little fold-out drawer in front of the sink and pull out the bottle brush. [laughter] And it took him a while because he just couldn't quite reach it. He picked it up, and he played around with it for a while, and he got it like halfway in. And finally, he got it out, and he ran off in the other room. And when he came back and tried to put it back in, he ended up pushing it through the back, and it dropped into the cupboard behind it, and he couldn't access it anymore. \n\nBut there was a new problem, and he experimented with it for a while, finally found a solution. And then he thought, oh, I'm going to experiment some more. Let's see if I can do the same thing in reverse. And he almost got it, you know, not quite. \n\nAFTON: [laughs]\n\nMIKE: He's one years old, and he is spending his life solving problems creatively and trying to fix them. I don't think that he is plagued with impostor syndrome. I think that it just comes naturally to him, and I think that that does come naturally to people. And if we approach this as like, well, I'm a problem solver, and I'm going to go solve some problems. And if I'm solving problems, I'm providing value. And if I do it a little bit differently than somebody else, well, maybe that's even a good thing. What do you think, Afton?\n\nAFTON: I was just thinking about as I was studying...because I'm a self-taught developer. I spent a couple of years at home on my own time just building an app, figuring it out as I went. I was thinking, did I have impostor syndrome then when I was isolated in my own little office at home, didn't have a bunch of other people?\n\nBecause the thought came to me just before we started this session today that impostor syndrome, I'm thinking, is caused by this assumption you make about other people and also this comparison that you imagine or feel between what they can do and what you can do. And so you're like, oh, well, they're better than me. So why am I here? How can I fit in? And the assumptions you're making about how accomplished or competent they may be maybe that fuels this feeling of being an impostor.\n\nI do recall when I had to reach out to developers that I knew as I was learning with some questions, occasionally I'd be like, oh, am I out of my league here trying to get someone who knows what they're doing to help me? But for the most part, I think I just felt really awesome. [chuckles] Like, oh man, I just spent three weeks on this one problem, and I just solved it. And I'm so cool. And other than that, it was just like, okay, I gotta figure it out. I just had to keep going, keep going. But I wasn't comparing myself to anyone else's progress. \n\nSo I think that the culture of the team you're working in or the company you're working in has a huge impact on impostor syndrome. And if you have a culture of we support each other, we're all learning together...look, I've been here five years, and I have this question that I feel like I should totally know the answer to, but I can't think of it right now, and just being vulnerable and being real, and not being afraid to ask questions. \n\nIf your culture, your team culture, your smallest level culture is that way, I think that mitigates impostor syndrome to a large extent or can because I can see how it could be otherwise if you didn't have a culture of we're learning together. It's okay to ask questions. We don't expect anyone to be perfect and know everything.\n\nMIKE: I really like that. It's interesting that you focused on culture. I think we all are at least in some position to influence it, but some more than others. If you just started in a new company, you're probably not going to be able to influence the culture a lot unless you're one of the first couple of employees. If you're in a large organization, that's harder. \n\nSo those who are in leadership positions...I'm sure that's going to apply to some people who are listening to this podcast that we have...and that applies to both you and I, Afton as well. We have an obligation to establish that kind of culture. And I think that that may be the most important thing we do as leaders in software engineering because we can't write all the code, and everybody's finding their own way. The other people you're working with they're their own selves. \n\nAnd you can enable them and create an environment that fosters their growth and development so that they feel safe and can be their own selves, achieve their own goals, be successful on their own terms. Or you can throw a wet blanket on all that and smother it. And you might get something done if you're trying to control everything, but it's certainly not going to get done as well. And you're going to take all the joy out of it if you don't allow the wild variety that's going to come out when everybody's trying something new. \n\nI also thought, as you were talking, I just feel like a superhero when I accomplish something, and you do. That feeling when you solve a problem as a software developer it's an indescribably good feeling. It's hard to explain.\n\nAFTON: [laughs]\n\nMIKE: I don't know how to explain it, that moment. I don't know if it's dopamine or some other neurotransmitter, but there's a flood of it. \n\nAFTON: [laughs] Yeah, absolutely.\n\nMIKE: [laughs] It's amazing to have that moment. That moment is deserved. It's earned. And nobody should be able to take that away. \n\nI thought, again, I've got a toddler at home. We don't expect toddlers to do anything other than what toddlers can do. And we give them a lot of praise when they do things that we wouldn't give adults praise for. [laughter] But we recognize that where they're at is where they're at and genuinely feel, I mean, I feel genuinely excited when my toddler makes an achievement, even though if I made that achievement, I wouldn't be all that excited about it. When he does it, I know that he's making this great achievement, and I feel great. \n\nWhen we're starting a career in software...so I'm going to focus on starting because that's when you probably feel most vulnerable. If you're in a healthy organization, going back to that culture, if you're in a healthy organization, nobody expects you to do exactly what the senior developers are doing. And in fact, they're celebrating with you with every achievement that you make. \n\nWhen they see you do something, everybody feels great. They're like, yes, look what they did. Look what they got done. They got code in production. Wow, already? That's great. Nobody was expecting you to be more than what you are. They're just happy to see you grow and having a willingness to ask and be curious. You might feel self-conscious, like, I'm asking so many questions. \n\nBut on the flip side, with a toddler, you expect them to ask questions; that's their job. As adults, we get shy about that. We don't want to go back to that place of, oh, I have to ask questions and be vulnerable again because we're afraid we might get hurt. Again, in a healthy company, in a healthy culture, you're going to be supported. And people want you to ask questions. They want you to grow because that's exactly how you're going to progress in your career.\n\nAFTON: And in fact, when there's someone who will not ask questions or seems to really not want to ask questions, that actually is a cause for concern. Like, do they need help and are they not getting it? Are they not using the resources available to them to get the job done? And asking questions of your co-workers and getting that variety of perspective and opinion coming in is crazy valuable in solving the problems. So it actually worries me if someone isn't asking questions and it seems like they're not making a lot of progress. [laughs] \n\nAnd in fact, I was thinking now that I'm a team lead, I have a little bit more insight into the work that everyone's doing on my team and the variety of experience that they each have. I'm not at all concerned that so and so matches the level of this other person or that so and so takes a little bit more time to get through a piece of work than someone else might. Really, if I see curiosity, if I see reaching out, asking questions, getting opinions, an outward I'm figuring this out; let's use my resources, if I see progress, I'm thrilled. \n\nProgress and curiosity that's driving this person forward, I know they're going to be fine. I know they're going to find a good solution. I know they're going to do good work because they're using the resources and all the skills of everyone around them to help in that. So that's what gives me the most confidence in the team is when they rely on everyone. \n\nI just thought of the it takes a village to raise a child. Use the village, use your team to create good work. That's actually better than trying to do it all on your own and say, \"No, I can do this on my own. I'll figure it out. I don't need anyone's help. \" That actually may stunt your ability to come up with a good variety of solutions and pick a good one. And so, yeah, it's that mentality, that willingness to use the resources that makes me be like, you've got it. I'm not concerned about how fast you're getting something done. If you have that attitude, you're going to be fine. \n\nMIKE: I couldn't agree more. I've talked to other team leaders as well when they're interviewing prospective new hires. And a common theme is if we hear somebody that has a lot of curiosity regardless of what their skill level is, that's someone we want to hire because that person is the one who's going to solve the problem. They're going to keep playing with that bottlebrush [laughter] until it comes out of the drawer.\n\nOur field moves quickly enough. And we're solving new problems nobody's ever solved before. So none of us is going to go into every problem and know exactly how to solve it. And so the key to being good at this is not about knowing all the things; it's about being curious enough that you're willing to poke around it until you figure it out.\n\nAFTON: Right. I just remembered, probably in my first, maybe second year as a developer, you were my team lead. And I had reached out to you for some help with a feature I was working on. And I said to you, \"Well, I mean, you obviously would know the right answer. So what do you think?\" And you were like, \"Well, actually, no. You've been in the code more than I have in the past long while, so you actually probably know more than I do.\" \n\nAnd I was like, wait, what? [laughter] And yeah, I just assumed your knowledge encompassed all the things and all the time and that you were up on every piece of the code everywhere because of your years of experience. And I said something like that, and you were like, \"Well, actually, no, you probably have better perspective and context and decision making because you've been digging into that code for a few days now.\" [laughs] And that really surprised me. \n\nAnd I was like, oh, you can be a little expert in your own little zone but only until...if you stop working in that zone, then a year later, someone else has mingled with it and tangled it up. And now you're not quite up to par on what's happening over there. And you have to research all over again if you need to work on that piece of the code again. So yeah, I'm just trying to say you can't know everything. You're not going to know everything. And whoever is focusing on a piece really will gain the best ability to make decisions in that problem, maybe than anyone else at that time.\n\nMIKE: How many times do you think you go to Google every day if you were to average?\n\nAFTON: I mean, at least several, I don't know, ten times a day at least. If I'm doing a lot of helping the team, meetings I'm not on there as often, but when I'm primarily developing, oh yeah, many times a day. [laughs]\n\nMIKE: If there's one most important tool, it seems like that might be it. To share a personal story, when I was in my...not even my first full-time job. I was working a part-time software development job right after I graduated from college, and I was trying to solve a problem. I could go into details, but the details aren't that important. The important thing is I was trying to find the answer in the documentation. I was trying to do the responsible thing. And I was digging through the documentation trying to find the answer, and I was not finding it. And this is think early 2000s. \n\nThe guy I was doing work for (I don't know exactly what to call his role.) the guy I was doing work for went out, and he came back with an answer in like a minute and pointed me to some documentation online. He's like, \"Let me tell you how I found this. There's this new tool called Google,\" which was brand new at the time. I hadn't really used it. I'd used some other search engines, but they were kind of useless, honestly. [laughs] If you ever used search engines back then, you'll know that they weren't very good, just flooded with spam. \n\nBut he said, \"I used this tool called Google, and it is this amazing tool. And you should always use it when you're trying to find this thing because it's much better than trying to find it yourself.\" And I learned my lesson. I've learned that you use that tool. The arc of my career [laughs] from beginning to today has been heavily reliant on this tool that came into existence about the time that I started coding full time and has been an essential. \n\nI have a hard time imagining software development without being able to use the search engine because there are so many things that we don't know. That little piece of information you're talking about is what you know, and this field is far more vast. It's full of so many things that you can't know that you have to rely on that tool. And our job is more about learning how to find information and use it than about necessarily having that information, all of that information just in our brains.\n\nAFTON: Right. I ran a mentorship for several months here at our company a couple of years ago. And I had some brand new developers who were taking their first Ruby on Rails course and JavaScript, and they were just learning to deep their toe into coding. And we would sit, and they'd have a question like, \"Well, I don't know what to do next. I'm getting this error.\" Or like, \"How do I move forward?\" And I was like, \"Let me show you Google.\" [laughter] I'm like, \"Copy and paste the error and drop it into Google. You might have your answer in one minute.\" \n\nSo I remember showing them this really is one of the most valuable skills in being a developer is being able to Google research effectively, learning how to cater your words to pinpoint the answer you're looking for. [laughs] And I remember as I was self-teaching myself just spending hours trying to figure out how to Google the right thing to get what I was looking for because I only knew what my problem was. So I would use some of the words, and I'd read the results, and I'm like, ah, this isn't really getting me what I'm looking for. And so I'd tweak my search, and I'd try again. \n\nAnd what I would do is notice that over time, I would see the same terminology being used in a lot of the results as I was going. So I'm like, okay, I don't know what that term means, but I keep seeing it, so I'm going to Google that. And I would just eventually dig my way down to this fine-tuned...and figure out how to finally get what I was looking for. But it's a lot of work. It was a lot of work learning how to do that, but one of the most valuable things that I know how to do and that helps me as a developer today. \n\nSo it was really fun running the mentorship, teaching, or helping these new developers realize how important that skill is and encouraging them to use Google all they want because they often feel like, oh, I shouldn't be using Google. I should just know it. [laughs] And no, use it, use it as much as you want, and it's going to benefit you greatly. [laughs]\n\nMIKE: Interestingly, before I was a software developer, I did customer support for Microsoft Windows through a contractor. They didn't do it themselves. They contracted it out. Anyway, I was doing support for Windows, Windows 98, and Windows Me. That gives you a sense of when this was. And I don't know how they run things today, but I can talk about how they ran it back then. \n\nMicrosoft had a knowledge base where you could search for information. And they actually had a rule that when there was a call that came in from a customer, even if you knew the answer, you were supposed to look it up anyway because that practice of searching for information was so fundamental to being successful. While I worked there, I became very good at finding the kinds of keywords that would get me the information I wanted. [laughs] And I was very diligent about that. I'd always search. \n\nAnd I had my favorite knowledge base articles that I would look up. Like, when somebody called in, and they had a network issue, I knew what the keywords to look up. And when they had...a lot of people had network card driver issues. They happened a lot. So I knew exactly what to look for because it happened all the time. I knew what to look up. And I think that has served me extremely well in my career because I spent months practicing how to look for information. And then when we got a search engine, that index, not just our internal information but the whole internet in a very effective way, it allowed me to start exploiting that.\n\nAFTON: Right. So I was just kind of thinking about the imposter syndrome. If developers have the tools and they feel confident they can get answers...because they know how to search; they know how to use Google. They know how to read through documentation and are willing to reach out to the people around them. If they are in a zone where they feel confident that they can get the answer if they don't know it, then I would imagine that would be a big factor in mitigating impostor syndrome. \n\nIf they feel like, ugh, I don't know how to even start solving a problem; I don't even know how to get answers if I need it; I don't know where to turn, I can see that being like, oh, I don't belong here, like, being a really difficult thing to get through. And so maybe people who are brand new in the field are just developing those skills. So all the encouragement and support to continue to develop those skills and use those I think would be a good way to help reduce impostor syndrome.\n\nMIKE: I like what you're saying. It also suggests that as mentors, what we want to focus on most may not be what you traditionally think of as tech skills. Most colleges, most computer science programs I'm aware of, don't have a class on how to use Google, you know, search engine of your choice. We're not playing favorites here. [laughter] I don't remember ever seeing a course like that. \n\nBut as a mentor, being able to help somebody do that, say, \"Hey, that's Stack Overflow. If you see those Stack Overflow results, they're likely to be a good source of information \" Being able to give that guidance as to where to go look for answers is maybe even more valuable than saying, \"Well, this is how you iterate over an array in Ruby.\" That's useful information, but they could find that themselves if you taught them how to Google it.\n\nAFTON: Right. And then next time, they'll find it for themselves again. [laughs] \n\nMIKE: Exactly.\n\nAFTON: Or they'll know how to get the answer.\n\nMIKE: Yeah, teach a woman or a man to fish, and they can do that thereafter.\n\nAFTON: Yeah. When I was running the mentorship, it was really fun to see them come upon a problem or a question they didn't know the answer to. I'm like, \"How do you think you can find the answer?\" [laughs] And they're like, \"Well, Google or something.\" I'm like, \"Yeah, let's go there.\" And I would let them...They're like, \"Well, what should I Google?\" I'm like, \"Well, what do you think? Think about what exactly are you looking for. What question do you have? And just type your question; that's a good starting place,\" and letting them struggle through it while I'm sitting there watching them.\n\nAnd they're all uncomfortable and like, \"I don't know if I'm typing the right thing or if this is going to get me there.\" I was like, \"The practice is great. And letting you do it is going to be so much more valuable than me telling you what to write, what to say, where to go.\" So that was a lot of fun helping them figure that out at that time. [laughs]\n\nMIKE: Yeah. And to people listening in, if you're starting your career and your mentors are encouraging you to do it on your own, that doesn't mean that they're pushing you away. They may be watching very closely, just smiling [laughter], knowing that that's such a useful thing for you to learn.\n\nAFTON: Critical, I would say.\n\nMIKE: Well said, well said. We've talked a lot about culture and how important that is. I guess there may be a flipside. If you find yourself at a place where you can't find mentors, or you are not getting support, or people expect you to just know things somehow, that maybe is a red flag. Well, I'd say more than maybe. Pay attention to the red flags. Especially right now, in 2022, there's work out there. If anybody wants to come work for Acima, let us know. It's hard to find people. \n\nIf you really have deep curiosity and drive to go solve problems, you can be successful, and you should find someplace that will allow you to do that. And you don't have to stay stuck somewhere that will hold you down. When you're interviewing, you should actively interview the company for their culture as well. Is this a place that is going to support my growth? And if they're not, it's not just your growth that's going to be stunted. They're not going to be very good at writing software. Is that consistent with your thoughts, Afton?\n\nAFTON: Yeah, yeah. And I was just thinking if you feel like it's too big of a risk to try and leave if you don't like the culture; also, I'm big into improving the place you're at, especially if that risk is too great for you. Maybe starting to push and ask for a change in culture or just start doing things, being the change you want to see. [laughs] And hopefully, you could improve your own culture and environment. To some extent, that would improve things.\n\nMIKE: There is no situation that's going to be perfect. If you're not helping, well, then you're not helping. If you are helping, then you're making it better. There are toxic situations that you should have self-respect, and if you're able to get out, you should probably get out. But a lot of situations are not so clear. They're not perfect, but they're not necessarily horrible, and maybe you can have an influence. \n\nAnd I think there's going to be a recurring theme as we talk that the things that aren't purely technical are sometimes the most important, willingness to try to make a difference and make things better for yourself and others. What can I do to improve the culture? To reach out and be a mentor, for example, or to take some portion of your day to go and just study and learn to improve your skills, or to seek out a mentor. Find somebody you can trust and establish that relationship so that you can be learning from them. Things like that that you do they do take some vulnerability and stretching yourself, and that's easier for some people than others as well. \n\nThey're as much a part of software development as are the technical skills. Technical skills are important. They don't accomplish much if you're not in a position to do the work. And some of the best developers I've worked with actually didn't necessarily write a lot of code. But they were very much this kind of thing we're describing, that Afton has described where they've gone out and tried to improve the environment that they were working at. \n\nI'm thinking of somebody in particular. I don't want to name names for somebody who's not here. But, Afton, you'll probably think of somebody who was here and has gone on to be a manager of another company who really made a big impact in mentoring other people around them and had a big influence. They didn't get a lot of code written but was hugely valuable to the company in helping other people be successful.\n\nAFTON: Yeah, that was also a really good segue into the thought that I had I just remembered. And I do have to say this, Mike. You've been my team lead since I came to Acima. And I've watched you really, really put in a lot of effort, time, and energy to create this culture we're talking about. You've always had it as a top priority, from my perspective, to have this culture for the team that we are on. And you've really, really dedicated a lot of time and effort to make that happen. \n\nAnd as a new team lead, I am trying to carry that on for my portion of our team because you've been such a great example in how valuable this is. And I think it's just created a really awesome culture on our team. And I've heard within our department at our company that our team culture is unique, and it's a place where people want to be. We've had developers move to a different team and then say, \"Can I come back [laughs] to this team? Because the culture was really great.\" \n\nAnd they really appreciate this culture of acceptance, support, learning, mentoring. Mentoring is a really big part of our team culture. And I just want to say you have really worked to create that and worked hard to maintain it over the whole span of my career here at Acima. And that has been really incredible. So you are an example of this yourself.\n\nMIKE: I didn't expect joining the podcast would bring tears to my eyes [laughs], but it did. Thank you, Afton. That was very affecting. I would hope...if there's anything that I would want to accomplish in my career, it would be that because I believe what I'm saying here. I think that providing that environment for people to be successful is the most important thing we can do as leaders in software. \n\nAnd to add to that, when people are enabled to show their own skills, to grow their own skills on their own terms, they do great things. And our team has grown and split. We were budding like microbial growth. We're splitting and forming new nodes. But as we've done that, the people on the team have grown into that and have themselves fostered other people and have enabled other people. \n\nAnd we all have different personalities. But those core principles of caring for other people and their autonomy, and their human dignity, I'd say that, and giving them a chance to shine has continued to happen. And that has just been tremendously gratifying for me to see and really the most rewarding experience of my career. \n\nWe are running up against the end of the time we had scheduled for this. But I think we hit on some key points on how you can be okay with getting started and feeling like you don't belong. What I hear is that we are all figuring it out as we go. And the important part is to not compare yourself against others. If you're building your career, embrace that curiosity and be willing to ask questions and try stuff, and if you are in a position of a mentor or a leader, enable people to do that, and they will shine. Any final words from you, Afton? \n\nAFTON: I was just thinking, yeah, it's very rewarding to hand-off a project or something and let someone run with it. Let a developer on the team run with it and see what they come up with, and see how they collaborate with each other. And it's awesome. \n\nAnd, I don't know, I just feel very fortunate to be here at Acima and to have been part of this culture that you have created and to be in a position now where I can work to continue that. And I'm just really hoping our teams will always feel free to explore and use their own skills and that they'll feel like they belong here and that they can do great things and that we're here to support that.\n\nMIKE: Thank you, Afton. And with that, we'll see you next time.","content_html":"Do I belong here? Am I good enough of a developer? These are questions someone with impostor syndrome may ask themselves. Today we discuss how we overcome these hard feelings.
\n\nTranscript:
\n\nMIKE: Welcome again to our podcast that still doesn't have a name. I'm Mike Challis. I'm hosting today. Also with us, we have Afton. Afton, do you want to introduce yourself?
\n\nAFTON: Yeah. I'm Afton. I've been developing for four and a half years professionally: about. Happy to be here.
\n\nMIKE: Ramses, would you like to introduce yourself?
\n\nRAMSES: Hi. I'm Ramses. I've been developing for a little bit about a year now, professionally, for just a couple of weeks.
\n\nMIKE: So this is a great group. Maybe let me introduce myself a little bit. [laughs] I'm Mike Challis. I've been doing development for a couple of decades now. [laughs] So we've got a perfect mix for today's topic.
\n\nToday we are going to be talking about impostor syndrome and how you overcome it. And this is perfect because we've got a mix of people at different spots in their career. I've been doing this for, like I said, a couple of decades. And then we've got Afton, who's getting...what do we say? Is that mid-career? You know, into your career.
\n\nWe've got different places in our careers, but we're all...I'll lead out by saying sometimes I feel like I have the question in my mind: do I really belong here? Am I doing okay? I think that's something that we all deal with. It's something that I regularly deal with. I think, well, am I really doing this okay? Sometimes I feel like I'm just winging it all the time. I'm not sure if I'm doing it right. And that's a hard thing. You sometimes don't have landmarks to go by. So maybe I'll go in the same order as before. Afton, do you find this feeling sometimes?
\n\nAFTON: Yeah. I've been curious as to why that's so prevalent in this field. And I don't have experience in other areas, so I don't know if it's more engineering is just, you know, problem-solving, figuring things out, creative, if that kind of field is what gives the right environment for this feeling. But yeah, I felt it a lot more as I was younger in the career.
\n\nAnd then I was actually just sitting here thinking, well, I haven't had that feeling in a while. And I was like, wait, you just said, "Oh, should I even be here?" And I was like, oh yeah, I thought that two days ago. [laughter] Yes, I do have that thought a lot. It's not debilitating to me. It used to be a little bit more so. But it does cross my mind regularly.
\n\nMIKE: Ramses, you just started as a full-time developer in the last couple of weeks. How are you feeling?
\n\nRAMSES: Generally pretty good. I always have that sense of like, do I belong here? Am I good enough of a developer to be a part of it? But I think that's part of the overall experience is learning and making those mistakes, so you just continue to learn.
\n\nMIKE: I love how you said that, making those mistakes, so you continue to learn. There's a suggestion there that you're not going to be perfect, that you're going to make mistakes. And nobody's over here judging you. That's a part of the process.
\n\nI'm also really interested in what Afton had to say. You wonder if this field, because of the problem-solving aspect of it, creative problem solving lends itself to that imposter syndrome. I think that's an interesting question. You started to explore that a little bit. Do you have an opinion on that, Afton?
\n\nAFTON: I mean, this is my first career, so I don't have other career types jobs to compare it to. But other jobs I have had in my life, I've never felt this way. They give you an exact set of this is what you need to do, and then you did exactly that. [laughs] There wasn't a lot of unknown. There wasn't like, oh, is this my role or isn't it? It was always very clearly defined. This is exactly what I expect from you, and that was it. So I've never felt it before in a job, and this is the first time.
\n\nSo I do really think that, I mean, we know what our job is; it's to take what the business needs, find a way to solve problems and produce something to better the experience for our own company and our customers. [laughs] But there's not an exact right way to do anything. There are lots of options. It takes a lot of work to figure out what's going to work best. And you've got to collaborate with a lot of people to make projects and features happen. So I think all of that openness to what's the answer, there isn't an exact answer. I think that's a big part of what creates this feeling.
\n\nMIKE: I think you're right. It's been a while. I did construction work mostly before I started doing software. It was a family thing. I kind of got into it as a kid. It feels like when you can see what you're working on; there's a clear goal. You got to build a wall. You got to frame a wall. There's really just one way to do it. You maybe learn a trick, and then you use that trick for the rest of your life. You build the wall laying down; you stand it up. But beyond that, it's very obvious when you've got it right.
\n\nAnd you can look at it like, hey, look at this wall I built. I did that right. [laughter] Or maybe you didn't do your [inaudible 05:02] very well, and so you really had to put a lot of mud in between the gaps. And you're like, oh, that was kind of bad; I'll have to do better next time. It's really clear whether you're doing well or not. I think it's a lot less clear here in software. You build something, and hopefully, you solved a need. There are no guardrails. It's just this wide-open field. You just try to figure it out.
\n\nAFTON: That reminds me of when I was...I went and spent a couple of weeks my first year here on a different team. And we were building this kind of...just spinning up this little project to solve one problem, and then I was going to go back to my team. And while I was there, I was the only Ruby developer. And they said, "Hey, this is what needs to be done." And I built something that worked. And then I was like, "So is this okay? What do you think about this? They're like, "Does it work?" I was like, "Well, yeah, I think so." "Well, then, it's great." [laughter] I was like, "Oh, okay." [laughs]
\n\nMIKE: You also said something interesting before. When you described the job, you didn't say the word code. That was dead on.
\n\nAFTON: [laughs]
\n\nMIKE: We're here to solve problems, and that's it, right?
\n\nAFTON: Yeah.
\n\nMIKE: We're here to solve business problems, and that may or may involve writing code. In fact, it seems like we're all most happy when we come up with a solution to the problem that doesn't require us to write any code.
\n\nAFTON: [laughs]
\n\nMIKE: We're just sticking a couple of things together already there, and, hey, it already works, and everybody's happy.
\n\nAFTON: Yeah, that's really interesting. And I do think of it as a problem-solving job. But you have to know how to code; I mean, it involves writing code. So yeah, that's an interesting shift in thinking about maybe how much code we don't write sometimes. [laughs]
\n\nMIKE: Well, and you've been around long enough; how do people feel when they get to delete code?
\n\nAFTON: Oh, deleting code is great. [laughs] Oh, man, you feel like you have a junk drawer, and you get to clean it out. It feels so good.
\n\n[laughter]
\n\nMIKE: It's like the best feeling in all of software. And it's, I can delete stuff? Yes! [laughs] And it solves a problem at the same time once you really understand what we're doing. You recognize that it's not about writing code. It's about exactly what you said; it's about solving problems.
\n\nAnd I think that also leads to the main thrust of what we really wanted to talk about today, which is we've talked about having impostor syndrome seems to be something we all deal with. But the real question is, how do you deal with it? How do you avoid having that constant, nagging feeling that I don't belong here; I'm not good enough; I can't do it? I like how you led into some solutions, Afton, because you stressed, well, yeah, we're here to solve problems.
\n\nI've got a one-year-old, and I've been watching him recently learn how to walk. This morning, he figured out how to open the little fold-out drawer in front of the sink and pull out the bottle brush. [laughter] And it took him a while because he just couldn't quite reach it. He picked it up, and he played around with it for a while, and he got it like halfway in. And finally, he got it out, and he ran off in the other room. And when he came back and tried to put it back in, he ended up pushing it through the back, and it dropped into the cupboard behind it, and he couldn't access it anymore.
\n\nBut there was a new problem, and he experimented with it for a while, finally found a solution. And then he thought, oh, I'm going to experiment some more. Let's see if I can do the same thing in reverse. And he almost got it, you know, not quite.
\n\nAFTON: [laughs]
\n\nMIKE: He's one years old, and he is spending his life solving problems creatively and trying to fix them. I don't think that he is plagued with impostor syndrome. I think that it just comes naturally to him, and I think that that does come naturally to people. And if we approach this as like, well, I'm a problem solver, and I'm going to go solve some problems. And if I'm solving problems, I'm providing value. And if I do it a little bit differently than somebody else, well, maybe that's even a good thing. What do you think, Afton?
\n\nAFTON: I was just thinking about as I was studying...because I'm a self-taught developer. I spent a couple of years at home on my own time just building an app, figuring it out as I went. I was thinking, did I have impostor syndrome then when I was isolated in my own little office at home, didn't have a bunch of other people?
\n\nBecause the thought came to me just before we started this session today that impostor syndrome, I'm thinking, is caused by this assumption you make about other people and also this comparison that you imagine or feel between what they can do and what you can do. And so you're like, oh, well, they're better than me. So why am I here? How can I fit in? And the assumptions you're making about how accomplished or competent they may be maybe that fuels this feeling of being an impostor.
\n\nI do recall when I had to reach out to developers that I knew as I was learning with some questions, occasionally I'd be like, oh, am I out of my league here trying to get someone who knows what they're doing to help me? But for the most part, I think I just felt really awesome. [chuckles] Like, oh man, I just spent three weeks on this one problem, and I just solved it. And I'm so cool. And other than that, it was just like, okay, I gotta figure it out. I just had to keep going, keep going. But I wasn't comparing myself to anyone else's progress.
\n\nSo I think that the culture of the team you're working in or the company you're working in has a huge impact on impostor syndrome. And if you have a culture of we support each other, we're all learning together...look, I've been here five years, and I have this question that I feel like I should totally know the answer to, but I can't think of it right now, and just being vulnerable and being real, and not being afraid to ask questions.
\n\nIf your culture, your team culture, your smallest level culture is that way, I think that mitigates impostor syndrome to a large extent or can because I can see how it could be otherwise if you didn't have a culture of we're learning together. It's okay to ask questions. We don't expect anyone to be perfect and know everything.
\n\nMIKE: I really like that. It's interesting that you focused on culture. I think we all are at least in some position to influence it, but some more than others. If you just started in a new company, you're probably not going to be able to influence the culture a lot unless you're one of the first couple of employees. If you're in a large organization, that's harder.
\n\nSo those who are in leadership positions...I'm sure that's going to apply to some people who are listening to this podcast that we have...and that applies to both you and I, Afton as well. We have an obligation to establish that kind of culture. And I think that that may be the most important thing we do as leaders in software engineering because we can't write all the code, and everybody's finding their own way. The other people you're working with they're their own selves.
\n\nAnd you can enable them and create an environment that fosters their growth and development so that they feel safe and can be their own selves, achieve their own goals, be successful on their own terms. Or you can throw a wet blanket on all that and smother it. And you might get something done if you're trying to control everything, but it's certainly not going to get done as well. And you're going to take all the joy out of it if you don't allow the wild variety that's going to come out when everybody's trying something new.
\n\nI also thought, as you were talking, I just feel like a superhero when I accomplish something, and you do. That feeling when you solve a problem as a software developer it's an indescribably good feeling. It's hard to explain.
\n\nAFTON: [laughs]
\n\nMIKE: I don't know how to explain it, that moment. I don't know if it's dopamine or some other neurotransmitter, but there's a flood of it.
\n\nAFTON: [laughs] Yeah, absolutely.
\n\nMIKE: [laughs] It's amazing to have that moment. That moment is deserved. It's earned. And nobody should be able to take that away.
\n\nI thought, again, I've got a toddler at home. We don't expect toddlers to do anything other than what toddlers can do. And we give them a lot of praise when they do things that we wouldn't give adults praise for. [laughter] But we recognize that where they're at is where they're at and genuinely feel, I mean, I feel genuinely excited when my toddler makes an achievement, even though if I made that achievement, I wouldn't be all that excited about it. When he does it, I know that he's making this great achievement, and I feel great.
\n\nWhen we're starting a career in software...so I'm going to focus on starting because that's when you probably feel most vulnerable. If you're in a healthy organization, going back to that culture, if you're in a healthy organization, nobody expects you to do exactly what the senior developers are doing. And in fact, they're celebrating with you with every achievement that you make.
\n\nWhen they see you do something, everybody feels great. They're like, yes, look what they did. Look what they got done. They got code in production. Wow, already? That's great. Nobody was expecting you to be more than what you are. They're just happy to see you grow and having a willingness to ask and be curious. You might feel self-conscious, like, I'm asking so many questions.
\n\nBut on the flip side, with a toddler, you expect them to ask questions; that's their job. As adults, we get shy about that. We don't want to go back to that place of, oh, I have to ask questions and be vulnerable again because we're afraid we might get hurt. Again, in a healthy company, in a healthy culture, you're going to be supported. And people want you to ask questions. They want you to grow because that's exactly how you're going to progress in your career.
\n\nAFTON: And in fact, when there's someone who will not ask questions or seems to really not want to ask questions, that actually is a cause for concern. Like, do they need help and are they not getting it? Are they not using the resources available to them to get the job done? And asking questions of your co-workers and getting that variety of perspective and opinion coming in is crazy valuable in solving the problems. So it actually worries me if someone isn't asking questions and it seems like they're not making a lot of progress. [laughs]
\n\nAnd in fact, I was thinking now that I'm a team lead, I have a little bit more insight into the work that everyone's doing on my team and the variety of experience that they each have. I'm not at all concerned that so and so matches the level of this other person or that so and so takes a little bit more time to get through a piece of work than someone else might. Really, if I see curiosity, if I see reaching out, asking questions, getting opinions, an outward I'm figuring this out; let's use my resources, if I see progress, I'm thrilled.
\n\nProgress and curiosity that's driving this person forward, I know they're going to be fine. I know they're going to find a good solution. I know they're going to do good work because they're using the resources and all the skills of everyone around them to help in that. So that's what gives me the most confidence in the team is when they rely on everyone.
\n\nI just thought of the it takes a village to raise a child. Use the village, use your team to create good work. That's actually better than trying to do it all on your own and say, "No, I can do this on my own. I'll figure it out. I don't need anyone's help. " That actually may stunt your ability to come up with a good variety of solutions and pick a good one. And so, yeah, it's that mentality, that willingness to use the resources that makes me be like, you've got it. I'm not concerned about how fast you're getting something done. If you have that attitude, you're going to be fine.
\n\nMIKE: I couldn't agree more. I've talked to other team leaders as well when they're interviewing prospective new hires. And a common theme is if we hear somebody that has a lot of curiosity regardless of what their skill level is, that's someone we want to hire because that person is the one who's going to solve the problem. They're going to keep playing with that bottlebrush [laughter] until it comes out of the drawer.
\n\nOur field moves quickly enough. And we're solving new problems nobody's ever solved before. So none of us is going to go into every problem and know exactly how to solve it. And so the key to being good at this is not about knowing all the things; it's about being curious enough that you're willing to poke around it until you figure it out.
\n\nAFTON: Right. I just remembered, probably in my first, maybe second year as a developer, you were my team lead. And I had reached out to you for some help with a feature I was working on. And I said to you, "Well, I mean, you obviously would know the right answer. So what do you think?" And you were like, "Well, actually, no. You've been in the code more than I have in the past long while, so you actually probably know more than I do."
\n\nAnd I was like, wait, what? [laughter] And yeah, I just assumed your knowledge encompassed all the things and all the time and that you were up on every piece of the code everywhere because of your years of experience. And I said something like that, and you were like, "Well, actually, no, you probably have better perspective and context and decision making because you've been digging into that code for a few days now." [laughs] And that really surprised me.
\n\nAnd I was like, oh, you can be a little expert in your own little zone but only until...if you stop working in that zone, then a year later, someone else has mingled with it and tangled it up. And now you're not quite up to par on what's happening over there. And you have to research all over again if you need to work on that piece of the code again. So yeah, I'm just trying to say you can't know everything. You're not going to know everything. And whoever is focusing on a piece really will gain the best ability to make decisions in that problem, maybe than anyone else at that time.
\n\nMIKE: How many times do you think you go to Google every day if you were to average?
\n\nAFTON: I mean, at least several, I don't know, ten times a day at least. If I'm doing a lot of helping the team, meetings I'm not on there as often, but when I'm primarily developing, oh yeah, many times a day. [laughs]
\n\nMIKE: If there's one most important tool, it seems like that might be it. To share a personal story, when I was in my...not even my first full-time job. I was working a part-time software development job right after I graduated from college, and I was trying to solve a problem. I could go into details, but the details aren't that important. The important thing is I was trying to find the answer in the documentation. I was trying to do the responsible thing. And I was digging through the documentation trying to find the answer, and I was not finding it. And this is think early 2000s.
\n\nThe guy I was doing work for (I don't know exactly what to call his role.) the guy I was doing work for went out, and he came back with an answer in like a minute and pointed me to some documentation online. He's like, "Let me tell you how I found this. There's this new tool called Google," which was brand new at the time. I hadn't really used it. I'd used some other search engines, but they were kind of useless, honestly. [laughs] If you ever used search engines back then, you'll know that they weren't very good, just flooded with spam.
\n\nBut he said, "I used this tool called Google, and it is this amazing tool. And you should always use it when you're trying to find this thing because it's much better than trying to find it yourself." And I learned my lesson. I've learned that you use that tool. The arc of my career [laughs] from beginning to today has been heavily reliant on this tool that came into existence about the time that I started coding full time and has been an essential.
\n\nI have a hard time imagining software development without being able to use the search engine because there are so many things that we don't know. That little piece of information you're talking about is what you know, and this field is far more vast. It's full of so many things that you can't know that you have to rely on that tool. And our job is more about learning how to find information and use it than about necessarily having that information, all of that information just in our brains.
\n\nAFTON: Right. I ran a mentorship for several months here at our company a couple of years ago. And I had some brand new developers who were taking their first Ruby on Rails course and JavaScript, and they were just learning to deep their toe into coding. And we would sit, and they'd have a question like, "Well, I don't know what to do next. I'm getting this error." Or like, "How do I move forward?" And I was like, "Let me show you Google." [laughter] I'm like, "Copy and paste the error and drop it into Google. You might have your answer in one minute."
\n\nSo I remember showing them this really is one of the most valuable skills in being a developer is being able to Google research effectively, learning how to cater your words to pinpoint the answer you're looking for. [laughs] And I remember as I was self-teaching myself just spending hours trying to figure out how to Google the right thing to get what I was looking for because I only knew what my problem was. So I would use some of the words, and I'd read the results, and I'm like, ah, this isn't really getting me what I'm looking for. And so I'd tweak my search, and I'd try again.
\n\nAnd what I would do is notice that over time, I would see the same terminology being used in a lot of the results as I was going. So I'm like, okay, I don't know what that term means, but I keep seeing it, so I'm going to Google that. And I would just eventually dig my way down to this fine-tuned...and figure out how to finally get what I was looking for. But it's a lot of work. It was a lot of work learning how to do that, but one of the most valuable things that I know how to do and that helps me as a developer today.
\n\nSo it was really fun running the mentorship, teaching, or helping these new developers realize how important that skill is and encouraging them to use Google all they want because they often feel like, oh, I shouldn't be using Google. I should just know it. [laughs] And no, use it, use it as much as you want, and it's going to benefit you greatly. [laughs]
\n\nMIKE: Interestingly, before I was a software developer, I did customer support for Microsoft Windows through a contractor. They didn't do it themselves. They contracted it out. Anyway, I was doing support for Windows, Windows 98, and Windows Me. That gives you a sense of when this was. And I don't know how they run things today, but I can talk about how they ran it back then.
\n\nMicrosoft had a knowledge base where you could search for information. And they actually had a rule that when there was a call that came in from a customer, even if you knew the answer, you were supposed to look it up anyway because that practice of searching for information was so fundamental to being successful. While I worked there, I became very good at finding the kinds of keywords that would get me the information I wanted. [laughs] And I was very diligent about that. I'd always search.
\n\nAnd I had my favorite knowledge base articles that I would look up. Like, when somebody called in, and they had a network issue, I knew what the keywords to look up. And when they had...a lot of people had network card driver issues. They happened a lot. So I knew exactly what to look for because it happened all the time. I knew what to look up. And I think that has served me extremely well in my career because I spent months practicing how to look for information. And then when we got a search engine, that index, not just our internal information but the whole internet in a very effective way, it allowed me to start exploiting that.
\n\nAFTON: Right. So I was just kind of thinking about the imposter syndrome. If developers have the tools and they feel confident they can get answers...because they know how to search; they know how to use Google. They know how to read through documentation and are willing to reach out to the people around them. If they are in a zone where they feel confident that they can get the answer if they don't know it, then I would imagine that would be a big factor in mitigating impostor syndrome.
\n\nIf they feel like, ugh, I don't know how to even start solving a problem; I don't even know how to get answers if I need it; I don't know where to turn, I can see that being like, oh, I don't belong here, like, being a really difficult thing to get through. And so maybe people who are brand new in the field are just developing those skills. So all the encouragement and support to continue to develop those skills and use those I think would be a good way to help reduce impostor syndrome.
\n\nMIKE: I like what you're saying. It also suggests that as mentors, what we want to focus on most may not be what you traditionally think of as tech skills. Most colleges, most computer science programs I'm aware of, don't have a class on how to use Google, you know, search engine of your choice. We're not playing favorites here. [laughter] I don't remember ever seeing a course like that.
\n\nBut as a mentor, being able to help somebody do that, say, "Hey, that's Stack Overflow. If you see those Stack Overflow results, they're likely to be a good source of information " Being able to give that guidance as to where to go look for answers is maybe even more valuable than saying, "Well, this is how you iterate over an array in Ruby." That's useful information, but they could find that themselves if you taught them how to Google it.
\n\nAFTON: Right. And then next time, they'll find it for themselves again. [laughs]
\n\nMIKE: Exactly.
\n\nAFTON: Or they'll know how to get the answer.
\n\nMIKE: Yeah, teach a woman or a man to fish, and they can do that thereafter.
\n\nAFTON: Yeah. When I was running the mentorship, it was really fun to see them come upon a problem or a question they didn't know the answer to. I'm like, "How do you think you can find the answer?" [laughs] And they're like, "Well, Google or something." I'm like, "Yeah, let's go there." And I would let them...They're like, "Well, what should I Google?" I'm like, "Well, what do you think? Think about what exactly are you looking for. What question do you have? And just type your question; that's a good starting place," and letting them struggle through it while I'm sitting there watching them.
\n\nAnd they're all uncomfortable and like, "I don't know if I'm typing the right thing or if this is going to get me there." I was like, "The practice is great. And letting you do it is going to be so much more valuable than me telling you what to write, what to say, where to go." So that was a lot of fun helping them figure that out at that time. [laughs]
\n\nMIKE: Yeah. And to people listening in, if you're starting your career and your mentors are encouraging you to do it on your own, that doesn't mean that they're pushing you away. They may be watching very closely, just smiling [laughter], knowing that that's such a useful thing for you to learn.
\n\nAFTON: Critical, I would say.
\n\nMIKE: Well said, well said. We've talked a lot about culture and how important that is. I guess there may be a flipside. If you find yourself at a place where you can't find mentors, or you are not getting support, or people expect you to just know things somehow, that maybe is a red flag. Well, I'd say more than maybe. Pay attention to the red flags. Especially right now, in 2022, there's work out there. If anybody wants to come work for Acima, let us know. It's hard to find people.
\n\nIf you really have deep curiosity and drive to go solve problems, you can be successful, and you should find someplace that will allow you to do that. And you don't have to stay stuck somewhere that will hold you down. When you're interviewing, you should actively interview the company for their culture as well. Is this a place that is going to support my growth? And if they're not, it's not just your growth that's going to be stunted. They're not going to be very good at writing software. Is that consistent with your thoughts, Afton?
\n\nAFTON: Yeah, yeah. And I was just thinking if you feel like it's too big of a risk to try and leave if you don't like the culture; also, I'm big into improving the place you're at, especially if that risk is too great for you. Maybe starting to push and ask for a change in culture or just start doing things, being the change you want to see. [laughs] And hopefully, you could improve your own culture and environment. To some extent, that would improve things.
\n\nMIKE: There is no situation that's going to be perfect. If you're not helping, well, then you're not helping. If you are helping, then you're making it better. There are toxic situations that you should have self-respect, and if you're able to get out, you should probably get out. But a lot of situations are not so clear. They're not perfect, but they're not necessarily horrible, and maybe you can have an influence.
\n\nAnd I think there's going to be a recurring theme as we talk that the things that aren't purely technical are sometimes the most important, willingness to try to make a difference and make things better for yourself and others. What can I do to improve the culture? To reach out and be a mentor, for example, or to take some portion of your day to go and just study and learn to improve your skills, or to seek out a mentor. Find somebody you can trust and establish that relationship so that you can be learning from them. Things like that that you do they do take some vulnerability and stretching yourself, and that's easier for some people than others as well.
\n\nThey're as much a part of software development as are the technical skills. Technical skills are important. They don't accomplish much if you're not in a position to do the work. And some of the best developers I've worked with actually didn't necessarily write a lot of code. But they were very much this kind of thing we're describing, that Afton has described where they've gone out and tried to improve the environment that they were working at.
\n\nI'm thinking of somebody in particular. I don't want to name names for somebody who's not here. But, Afton, you'll probably think of somebody who was here and has gone on to be a manager of another company who really made a big impact in mentoring other people around them and had a big influence. They didn't get a lot of code written but was hugely valuable to the company in helping other people be successful.
\n\nAFTON: Yeah, that was also a really good segue into the thought that I had I just remembered. And I do have to say this, Mike. You've been my team lead since I came to Acima. And I've watched you really, really put in a lot of effort, time, and energy to create this culture we're talking about. You've always had it as a top priority, from my perspective, to have this culture for the team that we are on. And you've really, really dedicated a lot of time and effort to make that happen.
\n\nAnd as a new team lead, I am trying to carry that on for my portion of our team because you've been such a great example in how valuable this is. And I think it's just created a really awesome culture on our team. And I've heard within our department at our company that our team culture is unique, and it's a place where people want to be. We've had developers move to a different team and then say, "Can I come back [laughs] to this team? Because the culture was really great."
\n\nAnd they really appreciate this culture of acceptance, support, learning, mentoring. Mentoring is a really big part of our team culture. And I just want to say you have really worked to create that and worked hard to maintain it over the whole span of my career here at Acima. And that has been really incredible. So you are an example of this yourself.
\n\nMIKE: I didn't expect joining the podcast would bring tears to my eyes [laughs], but it did. Thank you, Afton. That was very affecting. I would hope...if there's anything that I would want to accomplish in my career, it would be that because I believe what I'm saying here. I think that providing that environment for people to be successful is the most important thing we can do as leaders in software.
\n\nAnd to add to that, when people are enabled to show their own skills, to grow their own skills on their own terms, they do great things. And our team has grown and split. We were budding like microbial growth. We're splitting and forming new nodes. But as we've done that, the people on the team have grown into that and have themselves fostered other people and have enabled other people.
\n\nAnd we all have different personalities. But those core principles of caring for other people and their autonomy, and their human dignity, I'd say that, and giving them a chance to shine has continued to happen. And that has just been tremendously gratifying for me to see and really the most rewarding experience of my career.
\n\nWe are running up against the end of the time we had scheduled for this. But I think we hit on some key points on how you can be okay with getting started and feeling like you don't belong. What I hear is that we are all figuring it out as we go. And the important part is to not compare yourself against others. If you're building your career, embrace that curiosity and be willing to ask questions and try stuff, and if you are in a position of a mentor or a leader, enable people to do that, and they will shine. Any final words from you, Afton?
\n\nAFTON: I was just thinking, yeah, it's very rewarding to hand-off a project or something and let someone run with it. Let a developer on the team run with it and see what they come up with, and see how they collaborate with each other. And it's awesome.
\n\nAnd, I don't know, I just feel very fortunate to be here at Acima and to have been part of this culture that you have created and to be in a position now where I can work to continue that. And I'm just really hoping our teams will always feel free to explore and use their own skills and that they'll feel like they belong here and that they can do great things and that we're here to support that.
\n\nMIKE: Thank you, Afton. And with that, we'll see you next time.
","summary":"Do I belong here? Am I good enough of a developer? These are questions someone with impostor syndrome may ask themselves. Today we discuss how we overcome these hard feelings.","date_published":"2022-10-12T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/b78248b9-94d6-4ba8-83af-1027d054a35c.mp3","mime_type":"audio/mpeg","size_in_bytes":35199619,"duration_in_seconds":2117}]},{"id":"51dd9716-853c-48d7-8ca4-00b9c316598d","title":"Episode 1: What Self-Taught and Bootcamp Grads Miss","url":"https://acima-development.fireside.fm/1","content_text":"Today we talk about what self-taught programmers and bootcamp graduates potentially miss out on by not attending traditional 4-year brick and mortar universities.\n\nTranscript:\n\nDAVID BRADY: Hello, and welcome to a podcast that still needs a name. I'm David Brady, and I am a self-taught programmer who's been self-teaching for a couple of decades now or more. And today, on our panel, we have Swapnil Bhosle. \n\nSWAPNIL: Hello.\n\nDAVID BRADY: Welcome. We have Brian Parry.\n\nBRIAN: Hello, gang.\n\nDAVID BRADY: Welcome, welcome. We have David Solano.\n\nDAVID SOLANO: Hey, I'm glad to be here.\n\nDAVID BRADY: Welcome. We have Adam Lauper.\n\nADAM: Hello from South Jordan. \n\nDAVID BRADY: Howdy. We have Afton Call.\n\nAFTON: Hello from Cottonwood Heights.\n\nDAVID BRADY: And last but certainly not least, we have Tad Thorley. \n\nTAD: Hey, welcome. Glad to be here.\n\nDAVID BRADY: Awesome. Today on our docket, we want to talk about an interesting topic which is what self-taught programmers and bootcamp graduates what they miss. And I just want to open it up to the panel to see if anybody has an immediate...what is the opposite of a hot take? If anybody has a hot take, I'd like to hear it. If anybody has opening shots fired that they want to throw out there, great, or if somebody has initial comments. Anybody want to take a stab at this? I have some questions I will ask if no one wants to volunteer. \n\nADAM: I think there are some categories in terms of learning that we're talking about, so one is like self-learned. You just started, you know, your kind of 1999 website and then grew that, and you grew your experience. There's a bootcamp, which is kind of a shorter form of education; usually, they're like four to six months. And then there's a bachelor's and a master's and stuff. We're talking about what people might miss if they're going through a bootcamp.\n\nDAVID BRADY: Yeah. And I wonder if that's...you've talked about getting a bachelor's or a master's degree, or other postgraduate work like getting a Ph.D. I kind of think of that as getting a classical education. And the obvious thing that you end up missing is the general education classes, right? You don't have to take American history. You don't have to take civics and economics. You [chuckles] don't have to take PE.\n\nAFTON: I just want to point out real quick that saying that you didn't get a degree in computer science doesn't mean you didn't get a degree, go to college and get that experience. \n\nDAVID BRADY: Ooh.\n\nAFTON: You could have done your computer science later and still had a different college degree. \n\nDAVID BRADY: That's a fantastic --\n\nTAD: I know a lot of developers who got degrees outside of the field of computer science who are excellent programmers. \n\nDAVID BRADY: Yeah, thank you for pointing that out. \n\nTAD: I've got a buddy who got a journalism degree. And I think it has actually really helped him to do software development because he knows how to tease apart things, do investigation, really find out some core bits of what software needs, interrogate people [laughs] to get the facts kind of thing. His background in trying to become a journalist and a reporter helps him with his interaction and getting all kinds of things set up for software development.\n\nAFTON: I got my degree in music. And then ten years later, after I graduated, I took my first coding course online as a stay-at-home mom homeschooling my children. So I took a very different path.\n\nDAVID BRADY: That is fantastic. Thank you very much for bringing that up. Because I have said multiple times in my career, I've said this in conference talks; I've said this on Twitter: almost without exception, every programmer I have ever worked with who has a bachelor's degree in mathematics or engineering, one of the hard stem courses, and then went into programming they are without exception the best programmers I've ever worked with. Especially the folks with a math background, they have this ability to go to a whiteboard and express a really difficult formula or solve a difficult problem with a computer. \n\nI literally worked with a guy who was trying to match sound waves literally on the oscilloscope, the sound wave. We could watch the sound pressure go up and then drop off. And the speed at which the sound wave dropped off was important. And how far down and up the sound wave was when the buffer cut off; all of that had to be matched at the start so that the line would continue on the oscilloscope unbroken. \n\nAnd we were generating the sound waves, so he literally had the problem of generating that. He was a Ph.D. in geophysics with a minor in mathematics. And it took him three days to come up with a mathematical proof of why what he was doing would work. But once he had it, it took him probably two days to write the software.\n\nSWAPNIL: I would like to share my experience.\n\nDAVID BRADY: Please. \n\nSWAPNIL: I have a bachelor's in engineering and electronics, and telecommunication. I'm a Ruby developer right now. But in the past, I used to like data structures. I used to like algorithms. I used to like coding on 8051. So basically, I was more inclined towards coding. So after graduation, I started with bootcamps. I'm sure you guys have heard about Codecademy. \n\nDAVID BRADY: Mm-hmm. Yap.\n\nSWAPNIL: So, from there, I started learning Python. And after Python, as Ruby was mostly inclined with Python, so I started learning Ruby. And I really liked, you know, I started with Devise. And I really liked how Devise used to plug and play login functionality which it's doing right now as well. So that's how my career path started. \n\nSo it's not about a computer science engineer should be a software developer but one, you know, who finds a path or one who has an interest towards coding. And it's more towards and inclines towards algorithms and can select the path of coding. That's what I feel.\n\nDAVID BRADY: That is fantastic. I have a follow-up question for that. Earlier, I said that if you didn't have a college degree, you might have missed classical education. But you said something really, really interesting. You got a degree in engineering and communications. \n\nAnd you said the magic word because I was starting to think that classic maybe the thing you might miss then are the classical computer, science classes. You might miss data structures and algorithms, or you might miss that horrible class where all you do is do sorting algorithms for the entire semester. And at the end of it, you just realize quicksort is the best; just always use quicksort. \n\nSo you actually got a degree, and then you went to Codecademy. And then you actually said data structures and algorithms. Swapnil, did you have anything in particular where you actually sat down and had to learn structures and algorithms like formally or informally self-taught from a book?\n\nSWAPNIL: We had a subject named data structures. And in data structures, they used to cover address, linked list, trees, linear search, quicksort, bubble sort, all these algorithms in C. And basically, I learned that in my career. And from there, I developed an interest in coding.\n\nDAVID BRADY: That is fantastic. We have a latecomer to the podcast. I'm going to mess up your name; I apologize. I'm going to do my best. I know your first name is Sreya. How do you say your last name? Is it Bhatt? \n\nSREYA: Yeah, Bhatt. \n\nDAVID BRADY: Bhatt. Sreya Bhatt, welcome to the podcast. We are talking today about what things you might miss as a programmer, what things you might not learn if you are self-taught or if you went to a coding school. And we haven't really well-defined what the alternative is. Maybe you got it. But so far, it's sounding like you don't have a degree in computer science; what do you miss? \n\nAnd we do have some people here that have degrees in other things. And we have some people here that don't have degrees at all, myself included. And we're going around talking about that. Can I ask, Sreya, what is your computer science portion of your background? Did you study it in school? Did you do an academy? How did you get here?\n\nSREYA: I basically started my coding in college. I was basically a bio student, so coding was new to me. And I started learning from my college. I basically didn't go for it at first. \n\nDAVID BRADY: Awesome. \n\nDAVID SOLANO: I wanted to add something there. So I learned about programming in the university, so I have a bachelor's degree in that. But what I wanted to say is that if you know how to do a program or you know how to program, and you have a degree in something else like in physics or something, that will boost you a lot. I was trying to learn a few years ago how to do simulations of how they...you talked about the sound, right? \n\nDAVID BRADY: Mm-hmm.\n\nDAVID SOLANO: I was trying to simulate how the water behaves in a glass and how you will be able to simulate that using all the physics that that involves depending on the density of the water that you're trying to measure. And that's extremely crazy. If you have knowledge about that and you know how to program, it will be a lot easier. But for me that I didn't know anything about that, it was really difficult.\n\nDAVID BRADY: Yeah. One job that I had was working on graphics cards. We had built...this is right about the time NVIDIA invented the GeForce. So prior to this, nobody was doing 3D graphics in hardware. It was your computer had to do it all in software, and we were working on a card that would do it in the hardware, and it was...you've seen the GeForce; it's wicked fast. \n\nAnd we had an engineering team that wrote the device drivers for us. And then, we had to write better device drivers because we were the software team. But they all had degrees in electrical engineering. And if you wanted to be a programmer on that team, you had to be an electrical engineer because they were talking about phases of currents and Faraday linkages. And I'm making up terms now. I need like a Star Trek psychobabble generator or technobabble generator.\n\nBut they would get into how the transistors actually work and how much real-time they need in the world to transition their magnetic fields. And I would just kind of look at them and go; I am so glad all I have to do is write software to talk to that. And if you want to be a programmer in a certain field, it is so much easier to get a degree in that field than it is to get a degree in programming and then try to learn the things in that field.\n\nADAM: Yeah, I had some comments. I had this chemistry teacher in college who acted as if his class was the most important class we've ever taken. And he kept telling us that \"People complain, but I'm telling you, talk to me in 10 years. You're going to be glad you took this class. It will come up somehow in your job or whatever.\" And I always want to write them back and say, \"No, [laughter] it's never come up. It was completely useless. I hated your class.\"\n\nAnd so I feel like the college route you definitely have a lot of fluff like American heritage. I'm working for a financial tech company. That's not relevant information. A lot of those general classes don't apply directly to my work. I mean, they make me more well-rounded in conversations and knowledge, but not really in my programming aspect.\n\nDAVID BRADY: Yeah, it is actually really important to know the difference between nitrates and nitrites. And that has to do with the number of nitrogen. I'm just messing with you. \n\nADAM: Huh.\n\nDAVID BRADY: But sometimes we take a rounded thing, and then we walk into a programming situation. And with software, you can end up so upside down and with lack of context, and you're programming a thing. And I've told this story before, but I had a bug report come in from a customer once that began with the sentence, \"Fortunately, no one was killed but...\" and that'll get your attention. \n\nAnd it was the vibration stuff when we were doing sound waves. What we were doing is we were vibrating things. And we had a little test stand that could vibrate a little like a pager or a cellphone to see if it would fall apart in the real world, you know, if it had any mechanical resonances. What we weren't really clear and precedent to was the fact that our big dollar customers were vibrating entire cars, and the military was vibrating tank bodies to see if the ammo crate would fall off the back of the tank, like that sort of stuff. \n\nAnd we had a bug that caused a little bit of a transient spike. Anybody over the age of 30 or so on this podcast may remember a time when you would turn your computer on, and your speakers would go \"pop!\" really loud. This was that. It's just caused by just random noise in the line getting sent through a very powerful amplifier. \n\nWell, when you send a pop through a 75 kVA three-phase power system that is capable of throwing five tons around, you end up launching a Toyota Camry so hard that it bends the frame of the Camry. And everyone on the plant floor wore their brown trousers that day whether they wanted to or not. \n\nI mention this in the context of general education because sometimes we get so hyper-focused. It's just a one; it's just a zero. It's clear; I click a mouse, and I drag a button. There's no way this can hurt somebody. Right up until somebody in the real world connects your ones and your zeros to a machine that can launch a car across the room or, in our case...Our podcast is entirely staffed by folks who work at Acima, and that's great. \n\nBut we work with financial instruments, and there's always the possibility that we could ruin somebody's financial life if we write bad software. I don't see it happening a lot. It's not a huge risk. It's not something that we do. But it is something that should be in the back of our mind that this is real stuff. It's fun, but it's not playtime. Does that make sense?\n\nADAM: Yeah, it's a good point. I have a question. So if someone has a four-year degree in computer science, computer engineering, something like that versus someone who went to maybe a bootcamp for six months and then has three and a half years of actual experience, you know, work experience versus someone who just kind of picked up a laptop and started working in the industry for four years, how do those compare? So they've all been working four years but in different ways.\n\nBRIAN: Comparing two people is really difficult because I've met so many people, like, I've met someone...he's one of my best friends, Oz, he never went to...doesn't have a classical education. He never went to a bootcamp. He just picked up stuff. He just picked up a book, got part of the way through the book, got a job as a junior in JavaScript. And then he was so fascinated. Now he's talking about set theory and everything else. He learned all the academic stuff because he was fascinated by it. \n\nAt the same time, I've met people who graduated with a four-year degree, and this isn't their hobby, so to speak. It's not that they're bad programmers. They have some computer science knowledge, but they're not necessarily into it as much. And so they've learned some of the academic stuff, but they have no practical skills yet, if that makes sense. So I think that's a tough one to make the answer even more [laughs] valid.\n\nDAVID BRADY: I have a friend that is starting university right now in Germany, and he's pulling his hair out because he has very little programming experience. So he doesn't have the real world to bring to it. But they're throwing him into computer science theory. So he's doing red-black trees and sorting algorithms. And he doesn't understand the theory, and he doesn't understand the application. \n\nSo he's starting from scratch, this poor guy, and he's absolutely hating it. But yeah, wind him forward four years, and he's going to have a good grasp of general theory. You could sit him down and say, \"How do I sort this set? How do I guarantee that this is the way this is going to work?\" \n\nI think to touch on Adam's question, people, in my experience, that have come out of a bootcamp and then jumped straight into real-world experience if you go back to them four years later if their passion is present...I worked with a fantastic programmer named Hannah at a previous job who came out of a bootcamp. And two years later, she was every bit as...I had absolutely no problem giving her a task from the team. If she was working on something, I did not feel any need to backstop her or to check her work or anything like that. \n\nBut it is also true that her experience was entirely centered around the business that that company did, which was the healthcare sector. And a lot of it's transferable. I mean, messages go in queues. Everybody needs that. But the meaningful business part of it is going to be a little bit focused. We do kind of see that...or I do kind of see that sometimes. \n\nIt really only hangs over somebody for the first, I don't know, five to six years. And then once you're in the five to eight-year programming kind of where you would hire on somewhere as an intermediate or an early expert level programmer, you've gotten both things. You've gotten the theory and the practice under your belt by that time.\n\nADAM: Yeah. Brian, I think you have a good point in that my observation is passion is paramount. It doesn't matter what someone's experience is; if they're excited to learn, they're going to be top of their, you know, whatever you hand them because they're hungry enough to figure it out, to learn. They have that excitement, that passion. So anyone with that, to me, it doesn't matter what their previous learning has been because they're going to learn anything that's relevant and be in a good place. \n\nWith four years, my observation is they don't have the real-world experience. I remember when I came out of college, I had some kind of academic things that didn't really apply in the real world. And they're like, \"Oh, why do you think that?\" And it's like, \"Oh, that's what the book said.\" [laughs] I think with someone with a bootcamp, that's great exposure. It's just so short that compared to a four-year degree, it's really focused. And so I think they really choose the most relevant. And it's a bootcamp, but it gets you started, and then you continue your learning after it. \n\nI did notice when I was in college; I took different languages in classes: Java, C++, JavaScript, so various languages. I took a compiler class, a security class, a data structure class. My first class, we actually wrote a simple program in machine code. So I feel like the four-year degree might give you some additional big-picture stuff. It's not as tuned, but I don't know if that's as relevant day-to-day. That might come up once every few weeks or a few months of, like, oh, yeah, that was actually useful to know. \n\nSo that's kind of my take is that if you do it in a quicker way, great, because now you get a jumpstart. That's what I was saying is the person who took a bootcamp and then worked for three and a half years, so, in equivalent time, they have three and a half years ahead of that college degree in the exact relevant experience. \n\nThey're not taking American heritage. They're not taking English or all these general classes which aren't relevant, specific to the job. But I do feel like they might have some dark corners or blind spots because they haven't taken all those other classic computer classes: security, compilers, operating systems, stuff like that.\n\nDAVID BRADY: Yeah, there are a lot of things that are adjacent to, you know, we talked about things that are career adjacent or things that are conceptually adjacent. Basically, it's stuff that you learn that as you're learning something or as you're doing something in your job, here are things next to your job. Or there are things next to the stuff you're learning that turn out to be incredibly useful. You would not see if you had not gone down that alley. \n\nAnd so I have no problem hiring somebody with a degree in English as a programmer because I'm going to sit them down and say, \"I expect you to have a lot of adjacency into how to communicate with human beings.\" And I argue very passionately that source code is all about communicating with humans, not about communicating with the computer, because that's what the compiler is for is to turn your human language into stuff for the computer. \n\nAnd so somebody with a degree that's off into, you know, it's like underwater basket weaving; when is this ever going to become useful? You never know. You run into these adjacencies, and you're like, all of a sudden, oh, man, I know how to write this series of expressions in a way that's linguistically satisfying. And it ends up being code that feels really good to everybody else on the team, but it might not be any more efficient or any less efficient.\n\nMIKE: What you're saying there, Dave, Andrew Ng, one of the luminaries in the AI field, says we need a lot of people who are doing AI plus X where X is whatever career you're in. We need physicians who know how to code and can use that in their job. We need historians who can go through the data that they work in and gather that information. We need biologists. We need even artists who understand how to code. That adjacency is actually a big deal. The things that you bring that are not technical are actually some of the most valuable things I think you bring to your job.\n\nDAVID BRADY: Yeah, that's fantastic. By the way, for those of you who've been listening from the beginning, that's Mike Challis. He's our director of engineering and his time is often very well spoken for, so he couldn't come until just now. Welcome, Mike. We're glad to have you. There's an image forming in my mind of what are the adjacencies that you're going to learn in a bootcamp plus a couple of years versus in a college degree? \n\nAnd if you walked into a woodshop and your job was to take down a log, take down a board, a two by two plank, and your job was to shape it, like, put it on the lay, you know, take hand tools to it or whatever, the person who has the college degree in lumber mechanics is going to look at each of those logs and say, \"That's got knots in it. That support thing that was in a poor-growth forest. We want to use that for structural, not for cosmetic lumber.\" They're going to know all this theory about it. \n\nBut the person who went straight to a bootcamp is going to pick up one log and say, \"I can feel the grain on this wood because on day one of the bootcamp, they handed me a knife and told me to start whittling. And so I know how to listen to the shape of the wood.\" And I don't know if that metaphor is useful to anybody. It's really clear in my mind. [laughs] But I should have got a degree in English to communicate better, I guess. \n\nAFTON: The conversation has turned actually quite well into the thoughts I was having. I was thinking we've been focusing on one particular aspect of developing, and that was writing code. But this conversation has steered into other aspects that make you a good developer. And I was thinking, yeah, there's so much more that can make you successful. \n\nFor instance, I'm self-taught. And the first skill I had to develop was how do you research and find answers to problems? First of all, you don't even know maybe what the question is you're asking. You just have this new task, and you don't know enough to know how to ask the question, what words to use. And so you'd have to develop the skill of knowing how to research, how to problem solve, how to plan and organize. And those are skills that you can definitely get from any other field from classes and/or just life experience. All those things are going to benefit you in those skills. \n\nAnd in my opinion, since that's the route that I got into development, I feel like those skills have really helped me because I don't have as technical of a background from school. But I think I'm really good at getting the answers I need when I need them, or I have confidence that I can get the answers. And that I think is super valuable.\n\nDAVID BRADY: That's fantastic. I saw a question go by on Twitter, and I have a very strong opinion about the answer to this. But I want to open this up either directly to Afton or to the group. If you're in a job interview or if you're interviewing someone and a question comes up that you don't know the answer to, is it appropriate in the interview to crack open Google and search for it?\n\nAFTON: So, just real quick, in my interview for my summer internship, that did happen to me. [laughs] I got asked the question, and I didn't know. And I said, \"Can I Google it?\" I had my computer right in front of me. I was showing a project I'd been building. And he was like, \"Sure, as long as you can find the answer.\" So I Googled it, and I got the answer in, I don't know, 20-30 seconds. And that was fine in my scenario.\n\nDAVID BRADY: I ask this for a reason because I feel very, very strongly that my job every day is to find the answers to things as quickly as possible. So Googling is literally a career skill. And so I would argue that it's not only appropriate to Google, but it almost ought to be an essential question as part of the interviewing process. Like, do you know how to find the answers to things you don't know the answers to? That'd be a fantastic interview question, right? Because it's literally a job capability skill. \n\nThe difference I think sometimes we see between people who did bootcamp versus people who spent a long time in academia, in academia, you're never allowed to plagiarize, and therefore, Googling is evil, and it's wrong, and it's stupid. And this is where I think art students are the one college degree that have the biggest advantage because, in art, you get taught to paint by looking at other paintings and trying to paint copies of them. \n\nBut when we teach you to write software, we give you a math problem, and we say, \"Solve this, but don't you dare look at anybody else's software.\" It's one of the only disciplines where we don't let people study the existing work of other people. That's a habit you absolutely have to unlearn when you get out into the real world because my job is to steal as much stuff as possible because my boss doesn't want to pay me to invent everything here, at least I think so. Mike? [laughs]\n\nMIKE: Oh, [laughs] I agree. You both said some stuff that I really value. Before Afton said how she answered, I thought if somebody didn't know the answer, I would want them to say, \"Can I Google that\" [laughs] And that's exactly what Afton said. \n\nWhat you don't do is...I interviewed somebody once, who I asked them to implement an algorithm. I think it was like, write an algorithm that will show the Fibonacci numbers. And they said, \"Give me a minute.\" And then they gave me this really weird implementation. And I Googled it, and they just copied it from Google and passed it off as their own.\n\nDAVID BRADY: Yeah, that's the bad kind of plagiarism, yeah.\n\nMIKE: Exactly. That's the bad kind of plagiarism. If that developer I was interviewing had said, \"Honestly, I'll probably Google it and come up with an answer. And here's the answer that came back. It's a little weird. Here's how I would change it,\" I would love that answer. If you are upfront and honest...in fact, it's a huge red flag if you were at a company and they asked you, and you say, \"Can I Google it?\" And they're like, \"No, no, you shouldn't do that,\" I'd be a little bit worried because a surprising amount of jobs of every engineer revolves around Google.\n\nDAVID BRADY: So we've been covering a little bit of things that you need, whether you've gone through a bootcamp, or self-taught, or whether you've gone through school. But I want to pull us back to the original topic. Is there anything else that might come out of a classical education that people who are self-taught autodidacts or people who took a bootcamp and just jumped in...what are some things that they're going to have to learn on the mean streets that they could have learned in the cloistered halls?\n\nTAD: One thing that I thought was interesting is we had to take ethics classes for our CS degree, and not everyone has to take ethics classes. If you're an art history major, you don't have to take ethics classes. But if you're a computer science major, if you were a business major, there were several other majors that were required to take ethics classes because I assume the idea is that what you do will have a lot of effects on people, and you need to stop and think about what that will do or what will happen. One of my professors told us nobody is going to write a function that's called bomb Baghdad.\n\nDAVID BRADY: [laughs]\n\nTAD: But you might write a bomb function that takes Baghdad as a parameter and not realize it. So I think that was an interesting distinction. \n\nDAVID BRADY: There's a thing that I'll throw out here. This might date me a little bit. I didn't graduate from university, but it doesn't mean I didn't try. And when I was at BYU, they spent an entire good portion of a semester...not the entire semester, but they spent a good portion of a semester in computer ethics talking about the Therac-25. If you don't know about it, go Google it, T-H-E-R-A-C, Therac-25. \n\nTL;DR: if the software didn't work, they just printed up a number like 72, and you're supposed to go look up in the manual that there's this problem. This radiation shield did not close, and that literally was the error. And the programmers that wrote it never stopped to think that, oh, when the radiation shield isn't closed, the patient is being bombarded. \n\nThey killed half a dozen people before they realized that they had written software that was indecipherable. You couldn't understand it. And so the nurses were doing their dead-level best to operate the machinery, and they were killing their patients because the software was so terrible. That's kind of a bright, chipper story, isn't it? \n\nDAVID SOLANO: Was that because they didn't know how radiation worked?\n\nDAVID BRADY: Possibly. So the Therac was back in the 1980s. And I think a lot of software was written...you wore a t-shirt and jeans in an environment where business suits were the norm. And everything you did was just numbers on whiteboards, and nothing mattered. And so if the machine went into one failure state, like, oh, your password doesn't match. That's one failure state, and we should give you back an error code. And if the radiation shield is supposed to close, but it doesn't close, well, that's another error state. \n\nAnd the programmers never stopped to think one of these error states is way more serious than others. There's actual risk to life and limb. They didn't know they needed to think about that difference. Does that make sense? That literally was the point of that ethics class was to say do you need to think about this human life and endangerment type of situations?\n\nAFTON: I'm going to read really quick a paragraph from Wikipedia on this topic [laughs] or just a sentence, sorry. It says, \"The overconfidence of the engineers and lack of proper due diligence to resolve reported software bugs are highlighted as an extreme case where the engineers' overconfidence in their initial work and failure to believe the end users' claims caused drastic repercussions.\" \n\nDAVID BRADY: Yes.\n\nAFTON: There you go. [laughs]\n\nTAD: And we went through all kinds of scenarios when I was in school where we went to a lecture by one of our professors, and he's like, the top 10 worst software failures. And they resulted in deaths and stuff like that. \n\nSo the thing that I think my degree got for me was a bigger context of just what software development meant, and what software engineering meant, and the effects of what you're doing has. Whereas a lot of the bootcamp people are very focused in on their particular industry, their particular set of skills they need to do a task. But getting a bigger picture of things like, you know, we did order of Big O notations and stuff like that. \n\nAnd I've talked to a lot of bootcamp folks. And they don't think about efficiency. They just know that I coded it up, and it works, and it did the job. Whereas we were taught, you have to think about a lot of different things that are going into that loop or that sorting algorithm or whatever.\n\nDAVID BRADY: And they'll come to it from the other direction. They'll get out into the real world, and their program will be too slow. And they might not know the notion of like, oh, I have a Big O. It's a linear Big O, and I don't like that. I'd like to reduce it, da, da, da, da. They'll come at it from, oh, my Rails app has an N+1 bug in it, and it's really slow when the database is big. And yeah, they end up...\n\nI think maybe you touched on it, Tad. You said that they'll come out, and they learn what they need to know to get the next thing done. It's a very goal-oriented type of learning. I think people with a classical education learn things because their teachers tell them to. It's just here's this generic principle. You're going to use it everywhere, so go ahead and learn it. Learn De Morgan's Laws, right? \n\nTAD: Yeah, I had some professors that actually tried to emphasize the science of computer science. They said, \"Let's get into the nature of the science and develop hypotheses, test things, do all sorts of stuff that you might do just as a scientist. But let's simulate that kind of stuff with computers.\" And that's not get a specific task done; that's just try a bunch of different things and see if your theory is correct. And it doesn't necessarily accomplish any goal other than you satisfied your curiosity.\n\nAFTON: So glad that we have such varied experience on our team, so we can glean from other people's knowledge, and skills, and backgrounds and work together to have this awesome team environment of learning and growing and making good code.\n\nMIKE: Very much so. You're here.\n\nDAVID BRADY: I like we started off, like, what are you going to miss if you go this route? But we've really come to it from regardless of where you came from; what are we going to knit you together with? It's like, you have to come out of either environment and become part of a team, and the team is going to look out for you. And you have to look out for your team. \n\nI do have a question for some of the newer folks on the team. Is there anything that you feel like you missed? And this can be those of you that got a college degree. Is there anything that you feel like you missed by not just jumping straight in and going to work? And if anybody did a bootcamp or is self-taught, is there anything that you really keenly felt as a missing bolt in your quiver?\n\nSWAPNIL: Actually, I never feel that way. Basically, when I did my engineering, whatever we learn, what I feel is we utilize it in whatever way we can. So anything you learn, if you learn communication, you know, you learn microcontrollers, what I feel is somewhere I can utilize that. So that's my thought about it.\n\nDAVID BRADY: That's true. You don't know what you don't know. So you have to focus on what you do know and what can I build out of what I have? Yeah, that makes sense.\n\nSREYA: I think we learn a lot when we start working in a real-world environment rather than learning in university.\n\nDAVID SOLANO: When I finished university, no one wanted to hire me because I didn't have experience and I was like, well, teach me. [laughs] I want to learn more. At the end, I fell back into an institution, a biodiversity institution, so I didn't know anything about biodiversity. But I liked a lot of views around it by a biologist and all that. \n\nAnd what I learned there is that if you don't know something, there are other people that will help you because they are experts in those fields. We, as engineers or programmers we, probably don't know all the answers, but we can work with someone else to bring a solution to a product. And that's something that, for me, is fascinating, and I totally love that.\n\nDAVID BRADY: I personally have experienced that if you can mentor under somebody, you will learn so much faster. There's a reason the apprenticeship program was invented thousands of years ago in blacksmith shops and alchemy shops around the world. It's just so so powerful. \n\nI have one more question for the group. David, you touched on this really well about you had the degree, but you didn't have the experience, and you're like, \"Well, teach me.\" When I have interviewed people, I go in looking for two things, one, what is their skill level? What do they actually already know? \n\nBut I always try to interview for something else, which is can they think? Because I know when I hire somebody, I'm going to have to teach them how our software works. And I might have to teach them how to program on top of that, depending on where their skill level is. But those are teachable skills. And I find that I cannot teach somebody to think. \n\nI have actually rejected candidates who were five to eight years into their careers and experts at programming. And I rejected them because I can't teach this person to think. I can't teach this person to listen to their teammate. I posed a problem, and when I nitpicked the solution, the candidate got angry at me. \n\nWhat are the ways, especially this is for the senior folks on the call...do you notice anything in the difference in the way people when the candidate is out of a bootcamp or is self-taught versus coming out of a college degree?\n\nMIKE: I've worked with a lot of people. The people with a college degree seem to have a...it's like they come with a bigger toolbox, I'll say that. If somebody comes with a big toolbox, they have a lot of tools they can draw from. But going back to what people said about passion, the people who are really curious might build their own tool [laughs] And come up with something different. \n\nMy dad is a woodworker. He actually makes a lot of his own tools. And he doesn't have a university degree, but he's very creative and comes up with things. I feel that people who don't necessarily have the toolbox are forced to use their creativity. And the passion will get you there one way or the other. The tools are useful, absolutely, but somebody who's willing to be persistent and push through it will invent their own solution. So I'm more interested in the passion and curiosity, especially, than I am necessarily in how big your toolbox is.\n\nDAVID BRADY: I realized as you were talking about that that there's an inverse case to that which is here in the United States we had, especially 20 years ago, it was expected of many kids that you'll go to high school, you'll graduate, you'll go to college, you'll get a degree, you'll graduate. And there were people coming into the computer science field 10, 15, 20 years ago that had no passion. They were just doing the next thing that was expected of them. And so they went up through the educational ladder and got a bachelor's degree. \n\nAnd these are people that end up in middle-level enterprise corporations at a mid-level thing where they sit and crank out a few lines of COBOL. And they're just waiting till 5:00 o'clock so they can go home. And I think that's something I never ever see out of somebody who's been to a bootcamp. If I interview a single mother who's put herself through a bootcamp, on top of working a day job, on top of raising her kids, I know this person has a passion for the work. I know this person has got a full plate and has figured out how to make room on her plate.\n\nAnd I've never seen somebody come out of...I can't say never. I have seen some people come out of a bootcamp that were just completely lost because they were so new. But I've never seen that; well, I did this because it was what I was supposed to do. I've never seen that out of bootcamps, and I have seen that out of degrees. And those people find their own level, I think. \n\nI think we might be at a good stopping point on this. Does anybody have a closing parting shot? I don't want to end on such a downer note. [laughs]\n\nAFTON: I'll just say I came here today expecting to have to fight to defend myself [laughs] as a self-taught learner because this was, what have I missed? But it did not end up being that way, and that was refreshing for me.\n\nDAVID BRADY: I came in with the same exact expectation, and this call has surprised me. Afton, maybe you and I should go away and think hard about why did we come in with our guard up a little bit? Probably because we've been hit a few times. So that'll have to be a topic for another show, though. We're definitely coming up out of time. \n\nI want to thank everybody for being on the show today: Tad, Swapnil, Brian, Afton, Adam, David, Sreya, Mike. Thank you all for coming today. This was a lot of fun. And we'll see you in a couple of weeks.","content_html":"Today we talk about what self-taught programmers and bootcamp graduates potentially miss out on by not attending traditional 4-year brick and mortar universities.
\n\nTranscript:
\n\nDAVID BRADY: Hello, and welcome to a podcast that still needs a name. I'm David Brady, and I am a self-taught programmer who's been self-teaching for a couple of decades now or more. And today, on our panel, we have Swapnil Bhosle.
\n\nSWAPNIL: Hello.
\n\nDAVID BRADY: Welcome. We have Brian Parry.
\n\nBRIAN: Hello, gang.
\n\nDAVID BRADY: Welcome, welcome. We have David Solano.
\n\nDAVID SOLANO: Hey, I'm glad to be here.
\n\nDAVID BRADY: Welcome. We have Adam Lauper.
\n\nADAM: Hello from South Jordan.
\n\nDAVID BRADY: Howdy. We have Afton Call.
\n\nAFTON: Hello from Cottonwood Heights.
\n\nDAVID BRADY: And last but certainly not least, we have Tad Thorley.
\n\nTAD: Hey, welcome. Glad to be here.
\n\nDAVID BRADY: Awesome. Today on our docket, we want to talk about an interesting topic which is what self-taught programmers and bootcamp graduates what they miss. And I just want to open it up to the panel to see if anybody has an immediate...what is the opposite of a hot take? If anybody has a hot take, I'd like to hear it. If anybody has opening shots fired that they want to throw out there, great, or if somebody has initial comments. Anybody want to take a stab at this? I have some questions I will ask if no one wants to volunteer.
\n\nADAM: I think there are some categories in terms of learning that we're talking about, so one is like self-learned. You just started, you know, your kind of 1999 website and then grew that, and you grew your experience. There's a bootcamp, which is kind of a shorter form of education; usually, they're like four to six months. And then there's a bachelor's and a master's and stuff. We're talking about what people might miss if they're going through a bootcamp.
\n\nDAVID BRADY: Yeah. And I wonder if that's...you've talked about getting a bachelor's or a master's degree, or other postgraduate work like getting a Ph.D. I kind of think of that as getting a classical education. And the obvious thing that you end up missing is the general education classes, right? You don't have to take American history. You don't have to take civics and economics. You [chuckles] don't have to take PE.
\n\nAFTON: I just want to point out real quick that saying that you didn't get a degree in computer science doesn't mean you didn't get a degree, go to college and get that experience.
\n\nDAVID BRADY: Ooh.
\n\nAFTON: You could have done your computer science later and still had a different college degree.
\n\nDAVID BRADY: That's a fantastic --
\n\nTAD: I know a lot of developers who got degrees outside of the field of computer science who are excellent programmers.
\n\nDAVID BRADY: Yeah, thank you for pointing that out.
\n\nTAD: I've got a buddy who got a journalism degree. And I think it has actually really helped him to do software development because he knows how to tease apart things, do investigation, really find out some core bits of what software needs, interrogate people [laughs] to get the facts kind of thing. His background in trying to become a journalist and a reporter helps him with his interaction and getting all kinds of things set up for software development.
\n\nAFTON: I got my degree in music. And then ten years later, after I graduated, I took my first coding course online as a stay-at-home mom homeschooling my children. So I took a very different path.
\n\nDAVID BRADY: That is fantastic. Thank you very much for bringing that up. Because I have said multiple times in my career, I've said this in conference talks; I've said this on Twitter: almost without exception, every programmer I have ever worked with who has a bachelor's degree in mathematics or engineering, one of the hard stem courses, and then went into programming they are without exception the best programmers I've ever worked with. Especially the folks with a math background, they have this ability to go to a whiteboard and express a really difficult formula or solve a difficult problem with a computer.
\n\nI literally worked with a guy who was trying to match sound waves literally on the oscilloscope, the sound wave. We could watch the sound pressure go up and then drop off. And the speed at which the sound wave dropped off was important. And how far down and up the sound wave was when the buffer cut off; all of that had to be matched at the start so that the line would continue on the oscilloscope unbroken.
\n\nAnd we were generating the sound waves, so he literally had the problem of generating that. He was a Ph.D. in geophysics with a minor in mathematics. And it took him three days to come up with a mathematical proof of why what he was doing would work. But once he had it, it took him probably two days to write the software.
\n\nSWAPNIL: I would like to share my experience.
\n\nDAVID BRADY: Please.
\n\nSWAPNIL: I have a bachelor's in engineering and electronics, and telecommunication. I'm a Ruby developer right now. But in the past, I used to like data structures. I used to like algorithms. I used to like coding on 8051. So basically, I was more inclined towards coding. So after graduation, I started with bootcamps. I'm sure you guys have heard about Codecademy.
\n\nDAVID BRADY: Mm-hmm. Yap.
\n\nSWAPNIL: So, from there, I started learning Python. And after Python, as Ruby was mostly inclined with Python, so I started learning Ruby. And I really liked, you know, I started with Devise. And I really liked how Devise used to plug and play login functionality which it's doing right now as well. So that's how my career path started.
\n\nSo it's not about a computer science engineer should be a software developer but one, you know, who finds a path or one who has an interest towards coding. And it's more towards and inclines towards algorithms and can select the path of coding. That's what I feel.
\n\nDAVID BRADY: That is fantastic. I have a follow-up question for that. Earlier, I said that if you didn't have a college degree, you might have missed classical education. But you said something really, really interesting. You got a degree in engineering and communications.
\n\nAnd you said the magic word because I was starting to think that classic maybe the thing you might miss then are the classical computer, science classes. You might miss data structures and algorithms, or you might miss that horrible class where all you do is do sorting algorithms for the entire semester. And at the end of it, you just realize quicksort is the best; just always use quicksort.
\n\nSo you actually got a degree, and then you went to Codecademy. And then you actually said data structures and algorithms. Swapnil, did you have anything in particular where you actually sat down and had to learn structures and algorithms like formally or informally self-taught from a book?
\n\nSWAPNIL: We had a subject named data structures. And in data structures, they used to cover address, linked list, trees, linear search, quicksort, bubble sort, all these algorithms in C. And basically, I learned that in my career. And from there, I developed an interest in coding.
\n\nDAVID BRADY: That is fantastic. We have a latecomer to the podcast. I'm going to mess up your name; I apologize. I'm going to do my best. I know your first name is Sreya. How do you say your last name? Is it Bhatt?
\n\nSREYA: Yeah, Bhatt.
\n\nDAVID BRADY: Bhatt. Sreya Bhatt, welcome to the podcast. We are talking today about what things you might miss as a programmer, what things you might not learn if you are self-taught or if you went to a coding school. And we haven't really well-defined what the alternative is. Maybe you got it. But so far, it's sounding like you don't have a degree in computer science; what do you miss?
\n\nAnd we do have some people here that have degrees in other things. And we have some people here that don't have degrees at all, myself included. And we're going around talking about that. Can I ask, Sreya, what is your computer science portion of your background? Did you study it in school? Did you do an academy? How did you get here?
\n\nSREYA: I basically started my coding in college. I was basically a bio student, so coding was new to me. And I started learning from my college. I basically didn't go for it at first.
\n\nDAVID BRADY: Awesome.
\n\nDAVID SOLANO: I wanted to add something there. So I learned about programming in the university, so I have a bachelor's degree in that. But what I wanted to say is that if you know how to do a program or you know how to program, and you have a degree in something else like in physics or something, that will boost you a lot. I was trying to learn a few years ago how to do simulations of how they...you talked about the sound, right?
\n\nDAVID BRADY: Mm-hmm.
\n\nDAVID SOLANO: I was trying to simulate how the water behaves in a glass and how you will be able to simulate that using all the physics that that involves depending on the density of the water that you're trying to measure. And that's extremely crazy. If you have knowledge about that and you know how to program, it will be a lot easier. But for me that I didn't know anything about that, it was really difficult.
\n\nDAVID BRADY: Yeah. One job that I had was working on graphics cards. We had built...this is right about the time NVIDIA invented the GeForce. So prior to this, nobody was doing 3D graphics in hardware. It was your computer had to do it all in software, and we were working on a card that would do it in the hardware, and it was...you've seen the GeForce; it's wicked fast.
\n\nAnd we had an engineering team that wrote the device drivers for us. And then, we had to write better device drivers because we were the software team. But they all had degrees in electrical engineering. And if you wanted to be a programmer on that team, you had to be an electrical engineer because they were talking about phases of currents and Faraday linkages. And I'm making up terms now. I need like a Star Trek psychobabble generator or technobabble generator.
\n\nBut they would get into how the transistors actually work and how much real-time they need in the world to transition their magnetic fields. And I would just kind of look at them and go; I am so glad all I have to do is write software to talk to that. And if you want to be a programmer in a certain field, it is so much easier to get a degree in that field than it is to get a degree in programming and then try to learn the things in that field.
\n\nADAM: Yeah, I had some comments. I had this chemistry teacher in college who acted as if his class was the most important class we've ever taken. And he kept telling us that "People complain, but I'm telling you, talk to me in 10 years. You're going to be glad you took this class. It will come up somehow in your job or whatever." And I always want to write them back and say, "No, [laughter] it's never come up. It was completely useless. I hated your class."
\n\nAnd so I feel like the college route you definitely have a lot of fluff like American heritage. I'm working for a financial tech company. That's not relevant information. A lot of those general classes don't apply directly to my work. I mean, they make me more well-rounded in conversations and knowledge, but not really in my programming aspect.
\n\nDAVID BRADY: Yeah, it is actually really important to know the difference between nitrates and nitrites. And that has to do with the number of nitrogen. I'm just messing with you.
\n\nADAM: Huh.
\n\nDAVID BRADY: But sometimes we take a rounded thing, and then we walk into a programming situation. And with software, you can end up so upside down and with lack of context, and you're programming a thing. And I've told this story before, but I had a bug report come in from a customer once that began with the sentence, "Fortunately, no one was killed but..." and that'll get your attention.
\n\nAnd it was the vibration stuff when we were doing sound waves. What we were doing is we were vibrating things. And we had a little test stand that could vibrate a little like a pager or a cellphone to see if it would fall apart in the real world, you know, if it had any mechanical resonances. What we weren't really clear and precedent to was the fact that our big dollar customers were vibrating entire cars, and the military was vibrating tank bodies to see if the ammo crate would fall off the back of the tank, like that sort of stuff.
\n\nAnd we had a bug that caused a little bit of a transient spike. Anybody over the age of 30 or so on this podcast may remember a time when you would turn your computer on, and your speakers would go "pop!" really loud. This was that. It's just caused by just random noise in the line getting sent through a very powerful amplifier.
\n\nWell, when you send a pop through a 75 kVA three-phase power system that is capable of throwing five tons around, you end up launching a Toyota Camry so hard that it bends the frame of the Camry. And everyone on the plant floor wore their brown trousers that day whether they wanted to or not.
\n\nI mention this in the context of general education because sometimes we get so hyper-focused. It's just a one; it's just a zero. It's clear; I click a mouse, and I drag a button. There's no way this can hurt somebody. Right up until somebody in the real world connects your ones and your zeros to a machine that can launch a car across the room or, in our case...Our podcast is entirely staffed by folks who work at Acima, and that's great.
\n\nBut we work with financial instruments, and there's always the possibility that we could ruin somebody's financial life if we write bad software. I don't see it happening a lot. It's not a huge risk. It's not something that we do. But it is something that should be in the back of our mind that this is real stuff. It's fun, but it's not playtime. Does that make sense?
\n\nADAM: Yeah, it's a good point. I have a question. So if someone has a four-year degree in computer science, computer engineering, something like that versus someone who went to maybe a bootcamp for six months and then has three and a half years of actual experience, you know, work experience versus someone who just kind of picked up a laptop and started working in the industry for four years, how do those compare? So they've all been working four years but in different ways.
\n\nBRIAN: Comparing two people is really difficult because I've met so many people, like, I've met someone...he's one of my best friends, Oz, he never went to...doesn't have a classical education. He never went to a bootcamp. He just picked up stuff. He just picked up a book, got part of the way through the book, got a job as a junior in JavaScript. And then he was so fascinated. Now he's talking about set theory and everything else. He learned all the academic stuff because he was fascinated by it.
\n\nAt the same time, I've met people who graduated with a four-year degree, and this isn't their hobby, so to speak. It's not that they're bad programmers. They have some computer science knowledge, but they're not necessarily into it as much. And so they've learned some of the academic stuff, but they have no practical skills yet, if that makes sense. So I think that's a tough one to make the answer even more [laughs] valid.
\n\nDAVID BRADY: I have a friend that is starting university right now in Germany, and he's pulling his hair out because he has very little programming experience. So he doesn't have the real world to bring to it. But they're throwing him into computer science theory. So he's doing red-black trees and sorting algorithms. And he doesn't understand the theory, and he doesn't understand the application.
\n\nSo he's starting from scratch, this poor guy, and he's absolutely hating it. But yeah, wind him forward four years, and he's going to have a good grasp of general theory. You could sit him down and say, "How do I sort this set? How do I guarantee that this is the way this is going to work?"
\n\nI think to touch on Adam's question, people, in my experience, that have come out of a bootcamp and then jumped straight into real-world experience if you go back to them four years later if their passion is present...I worked with a fantastic programmer named Hannah at a previous job who came out of a bootcamp. And two years later, she was every bit as...I had absolutely no problem giving her a task from the team. If she was working on something, I did not feel any need to backstop her or to check her work or anything like that.
\n\nBut it is also true that her experience was entirely centered around the business that that company did, which was the healthcare sector. And a lot of it's transferable. I mean, messages go in queues. Everybody needs that. But the meaningful business part of it is going to be a little bit focused. We do kind of see that...or I do kind of see that sometimes.
\n\nIt really only hangs over somebody for the first, I don't know, five to six years. And then once you're in the five to eight-year programming kind of where you would hire on somewhere as an intermediate or an early expert level programmer, you've gotten both things. You've gotten the theory and the practice under your belt by that time.
\n\nADAM: Yeah. Brian, I think you have a good point in that my observation is passion is paramount. It doesn't matter what someone's experience is; if they're excited to learn, they're going to be top of their, you know, whatever you hand them because they're hungry enough to figure it out, to learn. They have that excitement, that passion. So anyone with that, to me, it doesn't matter what their previous learning has been because they're going to learn anything that's relevant and be in a good place.
\n\nWith four years, my observation is they don't have the real-world experience. I remember when I came out of college, I had some kind of academic things that didn't really apply in the real world. And they're like, "Oh, why do you think that?" And it's like, "Oh, that's what the book said." [laughs] I think with someone with a bootcamp, that's great exposure. It's just so short that compared to a four-year degree, it's really focused. And so I think they really choose the most relevant. And it's a bootcamp, but it gets you started, and then you continue your learning after it.
\n\nI did notice when I was in college; I took different languages in classes: Java, C++, JavaScript, so various languages. I took a compiler class, a security class, a data structure class. My first class, we actually wrote a simple program in machine code. So I feel like the four-year degree might give you some additional big-picture stuff. It's not as tuned, but I don't know if that's as relevant day-to-day. That might come up once every few weeks or a few months of, like, oh, yeah, that was actually useful to know.
\n\nSo that's kind of my take is that if you do it in a quicker way, great, because now you get a jumpstart. That's what I was saying is the person who took a bootcamp and then worked for three and a half years, so, in equivalent time, they have three and a half years ahead of that college degree in the exact relevant experience.
\n\nThey're not taking American heritage. They're not taking English or all these general classes which aren't relevant, specific to the job. But I do feel like they might have some dark corners or blind spots because they haven't taken all those other classic computer classes: security, compilers, operating systems, stuff like that.
\n\nDAVID BRADY: Yeah, there are a lot of things that are adjacent to, you know, we talked about things that are career adjacent or things that are conceptually adjacent. Basically, it's stuff that you learn that as you're learning something or as you're doing something in your job, here are things next to your job. Or there are things next to the stuff you're learning that turn out to be incredibly useful. You would not see if you had not gone down that alley.
\n\nAnd so I have no problem hiring somebody with a degree in English as a programmer because I'm going to sit them down and say, "I expect you to have a lot of adjacency into how to communicate with human beings." And I argue very passionately that source code is all about communicating with humans, not about communicating with the computer, because that's what the compiler is for is to turn your human language into stuff for the computer.
\n\nAnd so somebody with a degree that's off into, you know, it's like underwater basket weaving; when is this ever going to become useful? You never know. You run into these adjacencies, and you're like, all of a sudden, oh, man, I know how to write this series of expressions in a way that's linguistically satisfying. And it ends up being code that feels really good to everybody else on the team, but it might not be any more efficient or any less efficient.
\n\nMIKE: What you're saying there, Dave, Andrew Ng, one of the luminaries in the AI field, says we need a lot of people who are doing AI plus X where X is whatever career you're in. We need physicians who know how to code and can use that in their job. We need historians who can go through the data that they work in and gather that information. We need biologists. We need even artists who understand how to code. That adjacency is actually a big deal. The things that you bring that are not technical are actually some of the most valuable things I think you bring to your job.
\n\nDAVID BRADY: Yeah, that's fantastic. By the way, for those of you who've been listening from the beginning, that's Mike Challis. He's our director of engineering and his time is often very well spoken for, so he couldn't come until just now. Welcome, Mike. We're glad to have you. There's an image forming in my mind of what are the adjacencies that you're going to learn in a bootcamp plus a couple of years versus in a college degree?
\n\nAnd if you walked into a woodshop and your job was to take down a log, take down a board, a two by two plank, and your job was to shape it, like, put it on the lay, you know, take hand tools to it or whatever, the person who has the college degree in lumber mechanics is going to look at each of those logs and say, "That's got knots in it. That support thing that was in a poor-growth forest. We want to use that for structural, not for cosmetic lumber." They're going to know all this theory about it.
\n\nBut the person who went straight to a bootcamp is going to pick up one log and say, "I can feel the grain on this wood because on day one of the bootcamp, they handed me a knife and told me to start whittling. And so I know how to listen to the shape of the wood." And I don't know if that metaphor is useful to anybody. It's really clear in my mind. [laughs] But I should have got a degree in English to communicate better, I guess.
\n\nAFTON: The conversation has turned actually quite well into the thoughts I was having. I was thinking we've been focusing on one particular aspect of developing, and that was writing code. But this conversation has steered into other aspects that make you a good developer. And I was thinking, yeah, there's so much more that can make you successful.
\n\nFor instance, I'm self-taught. And the first skill I had to develop was how do you research and find answers to problems? First of all, you don't even know maybe what the question is you're asking. You just have this new task, and you don't know enough to know how to ask the question, what words to use. And so you'd have to develop the skill of knowing how to research, how to problem solve, how to plan and organize. And those are skills that you can definitely get from any other field from classes and/or just life experience. All those things are going to benefit you in those skills.
\n\nAnd in my opinion, since that's the route that I got into development, I feel like those skills have really helped me because I don't have as technical of a background from school. But I think I'm really good at getting the answers I need when I need them, or I have confidence that I can get the answers. And that I think is super valuable.
\n\nDAVID BRADY: That's fantastic. I saw a question go by on Twitter, and I have a very strong opinion about the answer to this. But I want to open this up either directly to Afton or to the group. If you're in a job interview or if you're interviewing someone and a question comes up that you don't know the answer to, is it appropriate in the interview to crack open Google and search for it?
\n\nAFTON: So, just real quick, in my interview for my summer internship, that did happen to me. [laughs] I got asked the question, and I didn't know. And I said, "Can I Google it?" I had my computer right in front of me. I was showing a project I'd been building. And he was like, "Sure, as long as you can find the answer." So I Googled it, and I got the answer in, I don't know, 20-30 seconds. And that was fine in my scenario.
\n\nDAVID BRADY: I ask this for a reason because I feel very, very strongly that my job every day is to find the answers to things as quickly as possible. So Googling is literally a career skill. And so I would argue that it's not only appropriate to Google, but it almost ought to be an essential question as part of the interviewing process. Like, do you know how to find the answers to things you don't know the answers to? That'd be a fantastic interview question, right? Because it's literally a job capability skill.
\n\nThe difference I think sometimes we see between people who did bootcamp versus people who spent a long time in academia, in academia, you're never allowed to plagiarize, and therefore, Googling is evil, and it's wrong, and it's stupid. And this is where I think art students are the one college degree that have the biggest advantage because, in art, you get taught to paint by looking at other paintings and trying to paint copies of them.
\n\nBut when we teach you to write software, we give you a math problem, and we say, "Solve this, but don't you dare look at anybody else's software." It's one of the only disciplines where we don't let people study the existing work of other people. That's a habit you absolutely have to unlearn when you get out into the real world because my job is to steal as much stuff as possible because my boss doesn't want to pay me to invent everything here, at least I think so. Mike? [laughs]
\n\nMIKE: Oh, [laughs] I agree. You both said some stuff that I really value. Before Afton said how she answered, I thought if somebody didn't know the answer, I would want them to say, "Can I Google that" [laughs] And that's exactly what Afton said.
\n\nWhat you don't do is...I interviewed somebody once, who I asked them to implement an algorithm. I think it was like, write an algorithm that will show the Fibonacci numbers. And they said, "Give me a minute." And then they gave me this really weird implementation. And I Googled it, and they just copied it from Google and passed it off as their own.
\n\nDAVID BRADY: Yeah, that's the bad kind of plagiarism, yeah.
\n\nMIKE: Exactly. That's the bad kind of plagiarism. If that developer I was interviewing had said, "Honestly, I'll probably Google it and come up with an answer. And here's the answer that came back. It's a little weird. Here's how I would change it," I would love that answer. If you are upfront and honest...in fact, it's a huge red flag if you were at a company and they asked you, and you say, "Can I Google it?" And they're like, "No, no, you shouldn't do that," I'd be a little bit worried because a surprising amount of jobs of every engineer revolves around Google.
\n\nDAVID BRADY: So we've been covering a little bit of things that you need, whether you've gone through a bootcamp, or self-taught, or whether you've gone through school. But I want to pull us back to the original topic. Is there anything else that might come out of a classical education that people who are self-taught autodidacts or people who took a bootcamp and just jumped in...what are some things that they're going to have to learn on the mean streets that they could have learned in the cloistered halls?
\n\nTAD: One thing that I thought was interesting is we had to take ethics classes for our CS degree, and not everyone has to take ethics classes. If you're an art history major, you don't have to take ethics classes. But if you're a computer science major, if you were a business major, there were several other majors that were required to take ethics classes because I assume the idea is that what you do will have a lot of effects on people, and you need to stop and think about what that will do or what will happen. One of my professors told us nobody is going to write a function that's called bomb Baghdad.
\n\nDAVID BRADY: [laughs]
\n\nTAD: But you might write a bomb function that takes Baghdad as a parameter and not realize it. So I think that was an interesting distinction.
\n\nDAVID BRADY: There's a thing that I'll throw out here. This might date me a little bit. I didn't graduate from university, but it doesn't mean I didn't try. And when I was at BYU, they spent an entire good portion of a semester...not the entire semester, but they spent a good portion of a semester in computer ethics talking about the Therac-25. If you don't know about it, go Google it, T-H-E-R-A-C, Therac-25.
\n\nTL;DR: if the software didn't work, they just printed up a number like 72, and you're supposed to go look up in the manual that there's this problem. This radiation shield did not close, and that literally was the error. And the programmers that wrote it never stopped to think that, oh, when the radiation shield isn't closed, the patient is being bombarded.
\n\nThey killed half a dozen people before they realized that they had written software that was indecipherable. You couldn't understand it. And so the nurses were doing their dead-level best to operate the machinery, and they were killing their patients because the software was so terrible. That's kind of a bright, chipper story, isn't it?
\n\nDAVID SOLANO: Was that because they didn't know how radiation worked?
\n\nDAVID BRADY: Possibly. So the Therac was back in the 1980s. And I think a lot of software was written...you wore a t-shirt and jeans in an environment where business suits were the norm. And everything you did was just numbers on whiteboards, and nothing mattered. And so if the machine went into one failure state, like, oh, your password doesn't match. That's one failure state, and we should give you back an error code. And if the radiation shield is supposed to close, but it doesn't close, well, that's another error state.
\n\nAnd the programmers never stopped to think one of these error states is way more serious than others. There's actual risk to life and limb. They didn't know they needed to think about that difference. Does that make sense? That literally was the point of that ethics class was to say do you need to think about this human life and endangerment type of situations?
\n\nAFTON: I'm going to read really quick a paragraph from Wikipedia on this topic [laughs] or just a sentence, sorry. It says, "The overconfidence of the engineers and lack of proper due diligence to resolve reported software bugs are highlighted as an extreme case where the engineers' overconfidence in their initial work and failure to believe the end users' claims caused drastic repercussions."
\n\nDAVID BRADY: Yes.
\n\nAFTON: There you go. [laughs]
\n\nTAD: And we went through all kinds of scenarios when I was in school where we went to a lecture by one of our professors, and he's like, the top 10 worst software failures. And they resulted in deaths and stuff like that.
\n\nSo the thing that I think my degree got for me was a bigger context of just what software development meant, and what software engineering meant, and the effects of what you're doing has. Whereas a lot of the bootcamp people are very focused in on their particular industry, their particular set of skills they need to do a task. But getting a bigger picture of things like, you know, we did order of Big O notations and stuff like that.
\n\nAnd I've talked to a lot of bootcamp folks. And they don't think about efficiency. They just know that I coded it up, and it works, and it did the job. Whereas we were taught, you have to think about a lot of different things that are going into that loop or that sorting algorithm or whatever.
\n\nDAVID BRADY: And they'll come to it from the other direction. They'll get out into the real world, and their program will be too slow. And they might not know the notion of like, oh, I have a Big O. It's a linear Big O, and I don't like that. I'd like to reduce it, da, da, da, da. They'll come at it from, oh, my Rails app has an N+1 bug in it, and it's really slow when the database is big. And yeah, they end up...
\n\nI think maybe you touched on it, Tad. You said that they'll come out, and they learn what they need to know to get the next thing done. It's a very goal-oriented type of learning. I think people with a classical education learn things because their teachers tell them to. It's just here's this generic principle. You're going to use it everywhere, so go ahead and learn it. Learn De Morgan's Laws, right?
\n\nTAD: Yeah, I had some professors that actually tried to emphasize the science of computer science. They said, "Let's get into the nature of the science and develop hypotheses, test things, do all sorts of stuff that you might do just as a scientist. But let's simulate that kind of stuff with computers." And that's not get a specific task done; that's just try a bunch of different things and see if your theory is correct. And it doesn't necessarily accomplish any goal other than you satisfied your curiosity.
\n\nAFTON: So glad that we have such varied experience on our team, so we can glean from other people's knowledge, and skills, and backgrounds and work together to have this awesome team environment of learning and growing and making good code.
\n\nMIKE: Very much so. You're here.
\n\nDAVID BRADY: I like we started off, like, what are you going to miss if you go this route? But we've really come to it from regardless of where you came from; what are we going to knit you together with? It's like, you have to come out of either environment and become part of a team, and the team is going to look out for you. And you have to look out for your team.
\n\nI do have a question for some of the newer folks on the team. Is there anything that you feel like you missed? And this can be those of you that got a college degree. Is there anything that you feel like you missed by not just jumping straight in and going to work? And if anybody did a bootcamp or is self-taught, is there anything that you really keenly felt as a missing bolt in your quiver?
\n\nSWAPNIL: Actually, I never feel that way. Basically, when I did my engineering, whatever we learn, what I feel is we utilize it in whatever way we can. So anything you learn, if you learn communication, you know, you learn microcontrollers, what I feel is somewhere I can utilize that. So that's my thought about it.
\n\nDAVID BRADY: That's true. You don't know what you don't know. So you have to focus on what you do know and what can I build out of what I have? Yeah, that makes sense.
\n\nSREYA: I think we learn a lot when we start working in a real-world environment rather than learning in university.
\n\nDAVID SOLANO: When I finished university, no one wanted to hire me because I didn't have experience and I was like, well, teach me. [laughs] I want to learn more. At the end, I fell back into an institution, a biodiversity institution, so I didn't know anything about biodiversity. But I liked a lot of views around it by a biologist and all that.
\n\nAnd what I learned there is that if you don't know something, there are other people that will help you because they are experts in those fields. We, as engineers or programmers we, probably don't know all the answers, but we can work with someone else to bring a solution to a product. And that's something that, for me, is fascinating, and I totally love that.
\n\nDAVID BRADY: I personally have experienced that if you can mentor under somebody, you will learn so much faster. There's a reason the apprenticeship program was invented thousands of years ago in blacksmith shops and alchemy shops around the world. It's just so so powerful.
\n\nI have one more question for the group. David, you touched on this really well about you had the degree, but you didn't have the experience, and you're like, "Well, teach me." When I have interviewed people, I go in looking for two things, one, what is their skill level? What do they actually already know?
\n\nBut I always try to interview for something else, which is can they think? Because I know when I hire somebody, I'm going to have to teach them how our software works. And I might have to teach them how to program on top of that, depending on where their skill level is. But those are teachable skills. And I find that I cannot teach somebody to think.
\n\nI have actually rejected candidates who were five to eight years into their careers and experts at programming. And I rejected them because I can't teach this person to think. I can't teach this person to listen to their teammate. I posed a problem, and when I nitpicked the solution, the candidate got angry at me.
\n\nWhat are the ways, especially this is for the senior folks on the call...do you notice anything in the difference in the way people when the candidate is out of a bootcamp or is self-taught versus coming out of a college degree?
\n\nMIKE: I've worked with a lot of people. The people with a college degree seem to have a...it's like they come with a bigger toolbox, I'll say that. If somebody comes with a big toolbox, they have a lot of tools they can draw from. But going back to what people said about passion, the people who are really curious might build their own tool [laughs] And come up with something different.
\n\nMy dad is a woodworker. He actually makes a lot of his own tools. And he doesn't have a university degree, but he's very creative and comes up with things. I feel that people who don't necessarily have the toolbox are forced to use their creativity. And the passion will get you there one way or the other. The tools are useful, absolutely, but somebody who's willing to be persistent and push through it will invent their own solution. So I'm more interested in the passion and curiosity, especially, than I am necessarily in how big your toolbox is.
\n\nDAVID BRADY: I realized as you were talking about that that there's an inverse case to that which is here in the United States we had, especially 20 years ago, it was expected of many kids that you'll go to high school, you'll graduate, you'll go to college, you'll get a degree, you'll graduate. And there were people coming into the computer science field 10, 15, 20 years ago that had no passion. They were just doing the next thing that was expected of them. And so they went up through the educational ladder and got a bachelor's degree.
\n\nAnd these are people that end up in middle-level enterprise corporations at a mid-level thing where they sit and crank out a few lines of COBOL. And they're just waiting till 5:00 o'clock so they can go home. And I think that's something I never ever see out of somebody who's been to a bootcamp. If I interview a single mother who's put herself through a bootcamp, on top of working a day job, on top of raising her kids, I know this person has a passion for the work. I know this person has got a full plate and has figured out how to make room on her plate.
\n\nAnd I've never seen somebody come out of...I can't say never. I have seen some people come out of a bootcamp that were just completely lost because they were so new. But I've never seen that; well, I did this because it was what I was supposed to do. I've never seen that out of bootcamps, and I have seen that out of degrees. And those people find their own level, I think.
\n\nI think we might be at a good stopping point on this. Does anybody have a closing parting shot? I don't want to end on such a downer note. [laughs]
\n\nAFTON: I'll just say I came here today expecting to have to fight to defend myself [laughs] as a self-taught learner because this was, what have I missed? But it did not end up being that way, and that was refreshing for me.
\n\nDAVID BRADY: I came in with the same exact expectation, and this call has surprised me. Afton, maybe you and I should go away and think hard about why did we come in with our guard up a little bit? Probably because we've been hit a few times. So that'll have to be a topic for another show, though. We're definitely coming up out of time.
\n\nI want to thank everybody for being on the show today: Tad, Swapnil, Brian, Afton, Adam, David, Sreya, Mike. Thank you all for coming today. This was a lot of fun. And we'll see you in a couple of weeks.
","summary":"Today we talk about what self-taught programmers and bootcamp graduates potentially miss out on by not attending traditional 4-year brick and mortar universities.","date_published":"2022-09-28T00:00:00.000-04:00","attachments":[{"url":"https://aphid.fireside.fm/d/1437767933/274ca584-3a57-4d5a-8089-1192fc4fe3f1/51dd9716-853c-48d7-8ca4-00b9c316598d.mp3","mime_type":"audio/mpeg","size_in_bytes":49287607,"duration_in_seconds":2547}]}]}