Acima Development: Recent Episodes
Mike Challis
At Acima, we have a large software development team. We wanted to be able to share with the community things we have learned about the development process. We'll share some tech specifics (we do Ruby, Kotlin, Javascript, and Haskell), but also talk a lot about mentoring, communication, hiring, planning, and the other things that make up a lot of the software development process but don't always get talked about enough.
Panelists discuss the contrasting mindsets of focusing on the destination versus the journey in personal and professional growth. Dave initiates the topic, emphasizing the importance of a growth mindset that values continuous learning over mere achievement. This theme is further explored by Eddy, who talks about the significance of embracing challenges and discomfort to foster growth. Mike and others delve into educational theories like Lev Vygotsky's "zone of proximal development" to illustrate how discomfort can lead to substantial learning. The discussion moves to real-world experiences, sharing insights into the rapidly changing world of technology. Kyle's insights about the importance of understanding concepts over tools lead to a thoughtful debate about coding bootcamps, their role in jumpstarting careers, and the importance of ongoing learning. Sergio's experience with on-the-job learning and risk-taking further emphasizes the importance of hands-on experience and the ability to adapt. Everyone shares personal examples of how learning outside of work has shaped their professional lives, highlighting the need for continuous growth. Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'll be hosting today. Today with us, we have Dave, Kyle, Eddy, Sergio, and Tyson. I think we'll have a good mix of opinions here. I'm excited. We are going to be talking about how we manage to stay learning and growing our skills when there's always work to do. There's always something else to do. This is a challenge for all of us. I want to start, as I like to do, with a story or two. I'm going to start with a kind of a fail story. I was a few years into my career. I was at a company that got into a tight spot financially and laid off the development staff, all but one. And then he quit. And they ended up hiring me back on. [laughs] I came in not being the senior developer on the team, trying to pick up where the lead developer had left off. And, you know, he gave me some guidance and laid out some things he'd been working on, and, like, away you go. Good luck. So, for about a year, I was running things by myself. So, you know, I had my choice as to what to work on every day. And we were largely in maintenance. We weren't really adding new features. One thing I discovered is there were a lot of manual jobs that we had lined up. And this applies to more than learning, by the way. We had a lot of things that needed to be done manually. This company was a content management system. And we had to set up email addresses for a lot of our customers, as well as some other things. And it was a somewhat manual process. I knew I had to do that every day. And I noticed after a while that all of the manual tasks that needed to get done consumed more hours than I had in a day, and as well as all the other miscellaneous support requests. And I struggled for that year as to how to prioritize my time. There were things that I let slip because I was working on other things. And I just kind of really struggled to get all of the things done because there was absolutely more to do than I could do as a single person on the team, where we previously had a team of about six. I thought about that in retrospect quite a bit, about what I would do differently today. I'm going to kind of leave that story there for a second and come back to it. Another story I've got is from the last year, and it's outside of work entirely. My oldest son went to college. I used to ride a bicycle with him every morning, almost every morning. We'd go out and ride bikes, all-weather. We live in Illinois, so it's winter more than half the year. [laughs] So, we've got bikes that are built appropriately, big, fat tires. We'd go riding in the snow, and we had a lot of fun. And kind of the day he left, my daily rides pretty much went away because I had other priorities. I would be spending a lot more time with my other kids. Well, it's something that I still enjoy, that I like to do a lot. In fact, this morning, my son is back from college for the summer. This morning, he and I went on a bike ride, and I had a great time. It's something that I really enjoy. But when I didn't have the person who was really engaged in doing it (My younger kids think it's too cold in the winter.), when I didn't have somebody who wanted to do it, my priority suddenly shifted, and it just didn't happen very much anymore. So, I'm not that interested in going out alone. These two stories, I think, say a lot about me, at least, [laughs] I think also about human nature. When we're confronted with more things than we can do, we tend to latch on to something that's maybe easy to do or that we're familiar with. It's hard to take a step back and look at all of the things that need to get done and prioritized and say, "Well, here's something that's not necessarily urgent, but it's important. And if I don't do it regularly, then the whole system is going to fall apart." And this applies to paying down tech debt. It applies to, you know, a lot of things in life, eating good food, [laughs] nutritious food. But, in particular, today, we're going to be talking about learning. And I think that it fits very much into this first story of, well, you've got all these things. How do you possibly fit the learning in? And the other story, I think, reveals a lot about how you keep yourself motivated to do something. We tend to prioritize, I think, as humans, things very socially. And if we've got a partner in something, it makes a world of difference as to whether we're interested in doing it. And people sometimes talk about that as accountability, but I think that's inadequate. It's an inadequate representation. Accountability suggests that somebody's making sure you're doing something that you ought to do, that you maybe don't want to do. But I think it's a little bit different than that. I think that there's some things that we actually really enjoy doing and want to do but only find ourselves motivated to do if we are in some sort of social situation, if there's somebody who's doing it with us because, otherwise, we'll tend to prioritize something else that is also good because there are many good things to be working on. If there's something that you really care about, one of the best ways to make it happen is to have a partner. There's, I think, a lot to talk about how you manage to get learning done when you've got all of the other things to do. I think that I'd like to start with those couple of ideas, which are that prioritization is hard, and somehow you need to make that work. And secondly, anything you want to get done tends to happen much more when you do it in some sort of social situation. What are your all's thoughts about, you know, the ideas I've just shared but even, in general, about the topic today? DAVE: Mike, you mentioned accountability. And there is kind of a sentiment that we have of if I'm not the one making myself do it, it's somehow cheapened. It's somehow it's not enough, right? We lack discipline, and we have a problem. And I got really struck by the book Freakonomics by Stephen Dubner and the other Steven. He points out that he caught a lot of people cheating. Now, he's an economist, and he caught people cheating. Because what he'd do is he'd open a spreadsheet, and he would just say, "This is not right. Your averages aren't average. I can tell which people are lying." He then went around the world, finding different people that cheated in different ways. What he [inaudible 06:19] really shocking to him is that about 3% of the population are incorruptible. These are people who will do what they say. They will not cheat, and by cheating, is you go against the rules. No matter how easy it is to cheat, no matter how unlikely they are to get caught, and no matter how minimal the punishment if they get caught, there's no risk to this reward. And no matter how great the reward, these people, 3% of the population, won't do it. Just nope, that's wrong; I won't do it. 2% of the population are on the other end. They are incorrigible. These are the people that will cheat no matter how small the reward, no matter how likely they are to get caught, and no matter how severe the punishment might be. And that's kind of an interesting thing to find out. But the really staggering thing I see in there is that 95% of the population have a price. There's an old Calvin and Hobbes comic where Calvin says, "Everybody has a price. Mine is 75 cents." I like that [inaudible 07:24] honesty. What does that have to do with accountability? We are social creatures. And when we have accountability, when we have a friend doing something that is, you know, going to be hard for us to do, but it's, you know, good for us, and we really ought to do it, I don't think it's a lack of discipline to grab a friend and say, "Hey, let's go work on this together." Or "Hey, what do you think about this?" And then get excited about it. I don't think it's a lack of discipline. I think it's excellent planning and a great understanding of, like, our own conduct and, like, how humans operate, right? At the end of the month, if one person is like, "Well, if I don't force myself to do it, I lacked the discipline," and that person did not spend any time working on the new thing, and this other person that said, "I got to have a friend to get this done," and they worked on it every day for an hour for a month, right? The results talk, and I like the person that got the results in that. MIKE: It sounds like you're running with the same idea I was that getting a partner in doing something is not cheating. It's recognizing human nature that we prioritize. Just innately, we tend to prioritize things we do together. I'm sure there's exceptions. Some people really don't want to be [laughs] involved with somebody else in something, but that's rare. We're very social creatures, and recognizing that allows us to use that to do something that we really want to do together. And that's a valid and valuable way to get something done, and pretending that it isn't that way isn't going to help anyone. [laughs] It's just recognizing that's human nature. DAVE: Yeah. I came across a quote a couple of years ago that said, "Half of being smart is knowing what you're dumb at." I came across this, like, back in the '90s. It was a long time ago. And sometime in the mid-noughties, I had this great epiphany where I realized that I knew what I was dumb at, but I was still trying to do everything that way, or I was letting people bait me into doing it the hard way and then I was failing. And what I realized was what I want is the results. I don't want the honor of having done it right. I want it done successfully. That kind of led me to a personal epiphany that the other half of being smart is don't take on the world with your dumb. MIKE: Taking this idea a little further, I think that most of us want to grow our careers. There's things that we want to learn, we know that we ought to, but then we face the first problem that I talked about. Well, where can we possibly fit it with all of these other things that take up more time than we have in a day? And that kind of leads to the two meeting, right? [laughs] DAVE: Mm-hmm. MIKE: These two stories connecting. If you want to get something done, schedule it with somebody. [laughs] And there are a lot of different ways that we can make that happen, you know, find a study partner and say, "Hey, let's get together for half an hour every day." Take a class where you pay for it, and you're going to go meet with a professor. Take an online class where there's some social aspect. You know, take an online class together with somebody that you know. Even better, start a book club. Any of these involve the social aspect, where you've got something scheduled, and you've got somebody else that you're doing with. It changes the perception of things in your mind and is far more likely to make something happen than if you say, "Hey, you know, I'm tough. I can go [inaudible 10:37]." DAVE: I like that. There's also people (I definitely fall in this boat.) who are kind of on the other end of the spectrum. Like, I never have to force myself to go learn something. The question of, like, how do you make yourself learn? In my case, it's a little bit like asking a cocaine addict, "What do you like to do," right? It's like, my problem is sometimes I will take on too much unknown just because I want to go learn it all, right? And so, a lot of the strategies that I've had to learn are, how do I take this really cool, neat thing from a completely missing skill that I'm not skilled at at all, how do I turn that into something that I can sell? And I don't have a single clear, do this, and it will work. But I've got, like, 100 tiny, little hacks that I use that my goal right from the get-go is...actually, [inaudible 11:26] I was going to say my goal is to get to a point where an employer is happy to pay me. That's actually not true. I just bite straight into the pleasure of finding things out. I just love going, oh, that's another piece of how the universe works. That's another piece of how the world really is. And if I just let myself play with things, that's the hack right there. Let it be play instead of like, ahh, I got to do this thing, right? Back off and say, what do you want to play with? There's a time in the Atlas skills clinic when we stepped back and said, "Hey, let's look at, you know, game frameworks. Let's look at something silly. Let's look at something weird." And because that engages, like, this sense of play, you get this growth mindset. Instead of having the closed mindset of like, this is what I want to accomplish and have when I'm done, you look at it with the growth mindset of, what can I do to get into this process and get enmeshed and just experience the process, right? The journey is everything. I don't even want to reach the destination. And ten years down the road, you realize that you've gone through thousands of destinations because you never stopped journeying. Does that make sense? MIKE: I think so. You're talking about cultivating that child-like sense of wonder [laughs] that is hungry for it. If we didn't all have it, we'd never learn to walk. [laughs] You know, it's fun. I like to think that learning and fun are synonyms. What little kids like to do, well, they'll run around in a weird circle until they fall down. [laughs] It's kind of exploring the boundaries of what running [laughs] can do. It's fun to try out new things. And learning only ceases to be fun when it's kind of mandated, and we're often not actually learning but rather going through some sort of rote activity that has the trappings of learning, but it's not actually very engaging. DAVE: Yeah. I came across a really fascinating, like, a micro-observation, and all these conclusions came from it that I'm still finding, and it blows me away. So, closed mindset is when you focus on the objective, right? The destination. And growth mindset is when you focus on the journey. And very specifically, if you're playing a game in a closed mindset, the objective is to win. And, as humans, we want to do everything we can to optimize. We want the victory at, you know, the most victory at the cheapest cost. We want to put the least effort into this. We look at the thing we want to do, we want to get, and we go, ugh, how am I going to get this? What's the easiest way to get this? And when we look at growth mindset when you look at a game that has, like, an open-minded growth mindset, the objective is not to win; the objective is to keep playing, right? The objective on a growth mindset, you know, a journey versus the destination the objective is to keep journeying. And the conclusions that you can draw from this is that when you focus on the outcome, you actually make it harder on yourself to take the journey because you just [inaudible 14:15], right? And I can give you a really good example of this, which is you walk into school on the first day, and you're excited to learn all of these great things. And then the teacher says, "And this is what's going to be on the final." And you realize I just got to get through this final and move on. I've heard a student straight up tell a teacher, "Just tell me what I have to do to get an A." And the teacher got mad, right? Because the student did not want to learn the material. She just wanted to optimize and get out. She was basically telling the teacher, you are not important, and this subject matter does not interest me. How do I get out of your class with the minimum amount of hassle? Even though she said, she wanted an A, right? She wanted the highest grade possible, but, you know, she wanted to do 93% of the required effort to get an A, but she was not going to give 110. MIKE: That ties into this idea of what we prioritize. I think it'd be helpful to expand the group talking here. Eddy, if I could ask you, what has helped you? I know that you're somebody who has really grown your skills. What is something that's helped you keep learning and growing despite, you know, all the constraints of things you've needed to get done? EDDY: It's really just putting myself in uncomfortable positions, challenging my skill set in order for me to make sure that I'm learning something and just staying out of my comfort zone. After transitioning to full-time development, I realized, hey, you get assigned tasks about things you don't know anything about. Well, time to look up and try to figure out other blogs on Stack Overflow, et cetera, to figure out, oh, someone else ran into this problem. So, I'm constantly learning because the job...[laughs] that's the job requirement, essentially. MIKE: That's really interesting. You point out something we haven't really talked about much yet today, which is that one way to make sure you're learning is to deliberately put yourself out there—maybe not quite jump in the deep end and drown—but put yourself somewhere uncomfortable and make that conscious choice. Choose to embrace that discomfort, and then you find yourself growing a lot. Is that a fair summary? EDDY: Yeah, it's basically how I was able to learn as much as I did. Because the listeners may not be wary of this, but I'm just about completing my two years since I started coding, right? So, computer science or programming has existed for decades, right? So, starting a career path two years ago is basically drinking from a fire hydrant. But it is the only way to learn, at least for me, was just embracing it and just putting myself in situations where it wasn't comfortable. MIKE: And I think there's a lot of power in that, and it connects some to what Dave saying. If you embrace the discomfort, it kind of changes what happens. Because if you're never uncomfortable, you're probably not going to stretch very much. Once you realize, you know, discomfort maybe isn't so bad, then it opens up a whole new world. You know, I've seen you grow a lot. I've seen other people who have grown dramatically. It's because they've done something similar. They've been willing to put themselves in a situation where they might look dumb, where they might feel uncomfortable, and had to trust that it would work out. It means that you've got to be in a supportive environment. If you're in a hostile environment where people are going to treat you badly, you're probably not going to learn very much there, and maybe you should go somewhere else. When you have a supportive environment where you have people willing to work with you on that, you know, jumping in is just so vital, [laughs], you know, to be able to grow quickly. I believe that I've mentioned before on the podcast...it's such a powerful idea that I visit in my mind a lot. I know in education theory, there was a theorist named Lev Vygotsky. He was in the Soviet Union, and I don't know that his work was very much embraced there, but it's come to be widely used in education in the years since. And he suggested that people learn the most when they are in the space between what they can learn alone and what they can't learn, even with help. So, between what you can learn alone, which is fairly limited, and what you can't learn at all, even with help because it's just too hard, in between there, there's a range. They call it the zone of proximal development. That range is where you learn a lot. You know, getting yourself in that situation means that you have to have people who are there to help you, and it means that you're going to be uncomfortable. That's where most of the learning happens. Kyle, where have you found success in growing your skills, even though you've always got an endless pile of work to do? KYLE: In my endless pile of work? MIKE: Uh-huh. [laughs] KYLE: That's about the simplest answer. I always say that DevOps work is very breadth work. You can be somewhat provisioned in a few things, but you have to know about everything. And I feel like I'm constantly working on stuff that I do not know that much about and I'm not an expert in. But, you know, give it time and trial and error. A few days later, and it's not half bad, and you've figured the system out. MIKE: Interesting. So, you're in a position where you're frequently being confronted with new and challenging things. KYLE: Yeah. I would say that half the job, if not more than half the job, is troubleshooting. It's either troubleshooting or spinning up new tech, or upgrading old tech that has new features. And with that constantly happening, you're having to pivot all the time to learn. You might get comfortable with one tooling in DevOps, and as soon as you get comfortable with it, there's a new tool out there. It's so rapidly changing. I mean, we've discussed this in previous podcasts, but DevOps today, compared to DevOps even a few years ago, three, four years ago, it's a completely different environment. MIKE: And that's not so different from software development, generally. It's such a rapidly moving field. You're always a little bit behind, right? Always something to learn. KYLE: I actually question sometimes with some of the training materials, right? I always wondered, in school, like, why are they teaching me concepts? You know, why are they teaching me theory? I want to know how to program in C#. I want to know how to program better in Java. Why aren't they teaching me these tools? Well, I mean, you get looking at it, and if our schooling taught us how to just use tools, we wouldn't be very far along. It's that there is just the concepts that we really needed to understand to move forward and be able to adapt to all the changes that we've been faced with. MIKE: Amen. I've seen that be true over and over again. And I've seen some schools that focused a lot on skills say this, even something like a coding bootcamp. And this is not a criticism of coding bootcamps. They're focused on skills, right? They'll get you proficient in the skills you need to get going. But those concepts and fundamentals still have to be learned. And the people who are very successful coming into software development through that skills-first approach take a lot of time to continue to learn those concepts as they go. There's a price there that must be paid. There's really no shortcut. You have to actually be seeking out, oh, what is, [chuckles] let's all say, Big O Notation? You know, how do I figure out how fast this algorithm works? You know, it's something you probably weren't taught in your bootcamp, but understanding that some things go faster than other things [laughs] and learning to recognize the difference is going to be really important throughout your career. And actively seeking to grow your awareness of those concepts is going to make a huge difference. DAVE: I had a really interesting epiphany about coding bootcamps. I think they're fantastic, but you have to know what they are. I don't really think of them as a way to jumpstart you getting going. They're a way to jumpstart getting paid. You can go from working at Walmart (That's what I did.) shelving product...and then, in my nighttime, I was, you know, doing everything I could to learn everything I could, but I was still working at Walmart. And then I did kind of, like, a bootcamp induction-type thing. Back in the '90s, bootcamps weren't called bootcamps back then, but I did a thing like that. And it jumped started me into a programming job. I was still behind everybody. You know, I would go home and drink from the fire hydrant because I wanted to learn that. And so, the skills, the general concept knowledge, came. I had to fight for it the entire time. But now I had cash flow, right? Now I could make my rent payment. And we live in the real world, right? Sometimes you got obligations that prevent you, you know, from going places you want to go. And having a coding bootcamp to say, "Oh, hey, you want to get out of that job and get into this other thing? Great. Here you go." But again, growth mindset. If you think the coding bootcamp the objective is to finish it and get a job, and now you're done, you're going to be back at Walmart next year. MIKE: Yeah, I think that's well said. And again, this is not a criticism of coding bootcamps. DAVE: It's also not a criticism of Walmart. That was honest work when I was doing that there. I'm just saying if you want to move into knowledge work, you have to recognize that your knowledge portfolio has a half-life of about 18 months. That's a phrase I heard, like, 15 years ago. It's probably shorter now. And what I mean by that is half of what you know to do your job will be useless to you in two years. I don't use Vagrant very much anymore. I use Docker. And five years ago, I didn't use any container technology, and how much of what I know, right? You can pick any weird aspect of something. How much do you know about Chef and Puppet? We don't do that anymore, right? But it was an essential skill at the time. MIKE: That just illustrates this vital importance of looking for those concepts, you know, and actively prioritizing some learning. One thing you mentioned there is you go home, and you drink from the firehose. I think that there is real value, real value, important value in taking some time outside of work hours to learn something beyond what you're doing at work. I would say that most of my learning has been kind of the way that Kyle said, you know, at [laughs] work. There's a big pile of work, and you'll learn from it as you go. How could that not be where you learn most of what you know? Because that's where you spend your time. Sometimes, in order to learn something new, something that you haven't done yet, well, you might have to do some learning outside of what you are paid to do because they might not be paying you to learn that technology. Now, it might go back and benefit you [laughs] in your career, even your paying career. But I do think that it makes sense to schedule some time every day, if possible, to learn something that interests you, you know, someplace that you want to grow your career, or, you know, just your skills, or even if it's something that's outside of monetary compensation. It's something you just want to grow in your abilities. Take some time that you dedicate that's not even paid that you're just going to learn it each day, whether that's reading a book, whether that's taking a class. I do think that taking some of that dedicated time makes a really big difference over time. You know, it's probably not going to make very much difference if you do it for a week. But if you're studying for an hour a day, if you do that for a year, that's hundreds of hours. If you do that for ten years, it's thousands of hours. Thousands of hours of study in any topic is going to really push your skills forward. I would argue that doing something like that really matters. Has anybody had a lot of success with having something to just schedule, whether it be a class, or a book, or newsletters? There's many different ways that you can get some of that information. What have you done outside of work hours to grow your skills? KYLE: I thought about an example as you were talking. So, here at work, for my work environment, I work a little bit different than most of my team where I have a Windows box. And I would run a VM through VirtualBox, and I would use Linux on that. And I did that for two or three years with the newer releases of VirtualBox. And drivers in Windows, I was having quite a few issues with that. And this is where I segue and say I'd gotten to where WSL 2 had come out. And on my personal rig, I'd been exploring that for quite a while, and just how seamless that was between that and Windows terminal, being able to use all the different terminal options, just from one window. And I know these things are available on other OSs, but I was stuck on Windows. But I then utilized what I'd learned on my personal experiments and the transition from using a VirtualBox VM to using WSL for all of my work here. And I was able to dump that VM. In doing so, I have a lot more resources on my machine that have been freed up because I'm not running two machines, technically, now. So, that was just kind of an example I thought I'd throw out. MIKE: It's one that I relate to a little bit. I used to always run VirtualBox as well [laughs] to run Linux. I had a work machine that didn't have it. And once again, you know, those experiments help. Thanks, Kyle. Anybody else have any experience with doing something outside of work that ended up providing a lot of benefit later? SERGIO: I have something to tell you. I think the way I learn is by doing stuff. Yeah, for example, two years ago, I wanted to build my own house. So, I hired some people to make this happen. But in the process, I found I can design wood furniture, so I just started to design small things. I guess feeling that sense of accomplishment is what motivates me. So, when I feel comfortable, I end up doing nice things. So, I guess you need to understand yourself, yeah. Something that I find nowadays, knowing smart people, makes you think, oh, well, it makes me think that I need to improve. Yeah, there is a good example in this company that I found people really smart, and see how they work, see how they do things. Yeah, it made me think I need to improve in some areas. That's something. Also, when I was a teacher...I don't know if you know, but I was teaching in a university here in Honduras. I had this idea of make people live better through education. What I mean is, here in my country, there are a few resources. If you are a good teacher, you try to do your best to your students till they get or learn difficult things the best they can. So, I guess something motivates people is, well, when thinking in the position of a teacher, yeah, I guess that opportunity to help people, and the people will understand you that you are really interested in they. It is nice for them to getting in shape really quickly on doing some stuff. So, I was a teacher from attending classes for software engineers. MIKE: I think you hit something really important there. We're talking about how you learn something. We've talked about how we learn things on the job. And a lot of the reasons we do learn things on the job is that we're doing them, right? When we're doing something hands-on, we learn it very quickly, in a way that you just can't do when you're just reading about it or studying about it. Yeah, to your point, Sergio, you got to do it. So, if you're really interested in learning how to do a new language, well, go and pick a project that you want to build and the language you want to learn and go start building it. And you'll learn far more building it than you would reading about that language. Not that you shouldn't do some reading, but the actual getting your hands-on, right? And working on it. SERGIO: Yeah, I agree with that. Me working in this company is a real example of that. I don't know if you know, guys, I am being hired here without having so much knowledge about Ruby on Rails. So, I had to negotiate with me of the lack of knowledge that I have in certain areas. I know that I don't have to be perfect, but I made this negotiation and just keep forward. Right now, I feel so nice with Ruby on Rails. I guess Eddy helped me in the process. Many people here is helping me, and yeah, that's awesome. But you need to understand...how much risk you are able to handle. [laughs] Yeah, it's [inaudible 30:45] in the professional environment, right? MIKE: Yeah, you kind of tied several things together there that we've been talking about, taking risks, right? Being willing to get out and take those risks, getting yourself hands-on, but also getting yourself involved with mentors. You talked about, as a teacher, you know, really getting a lot of sense of reward in going and helping other people. That's so true. [laughs] It also is true when you are the student that you have to engage. There's a lot of reward to you personally in being willing to engage and getting those social engagements active, that when you do that, you tend to progress more than you would otherwise. DAVE: I think there's a subtlety there as well, which is sometimes when we are trying to learn at work, right? We've got this key problem of, like, how do I get paid? How do I get my employer to be happy to pay me to learn this thing, right? And so, Sergio is coming in, and he's got to learn Rails because we're a Rails shop. And, Sergio, there's something you did in your interview that convinced us to say, "Oh yeah, yeah, we're happy to teach you this particular skill because we know you can think." You sell your ability to think. You say, "Hey, I'm good at this general field," or "I'm bringing these other things to the table." And we're like, "Oh, we're going to have to teach you our database naming conventions anyway. It's just an extra couple of hours to learn how the Rails generators work," right? And down the road, you go. It's really good to recognize, like, what skills you can bring that are, like, horizontal, like, wide-ranging skills that you can bring to the table, and they're going to apply everywhere. And then when you go to an employer and say, "Hey, I want to do this, and I want to use this specific technology," then the employer is like, "Yeah, yeah, I know you can get things done. Go for it." MIKE: To maybe go back to the first story that I told [laughs] about my job where I really struggled with prioritization, in retrospect, I've learned when put in a situation like that, when put it in a situation where there's more to do than you can possibly do, it turns out that's pretty common in life if not the norm. You need to look at what needs to get done, realize not all of it is going to get done, and choose what you're going to work on each day. You need to make a conscious choice. There is going to be an endless pile of work. And if there's an endless pile, it means you're not going to do all of it. You're going to be making choices, and embracing that choice means that you know you're going to work on this and not some other things. And it's very liberating to realize that, hey, there's this work I'm never going to get done, and maybe that's okay. And if that's the case, then it means that you can prioritize some things that maybe aren't quite as urgent but you know need to get done. If you're feeling like you're not making very much progress in learning, in growing your career, well, maybe it's time to take a step back and look at those priorities and say, well, I'm not getting everything done. And maybe I would get more done [laughs] if I grew my skills in some way. If it's impossible for me to get everything done, then I shouldn't even try. What I should instead do is prioritize, work on the most important things first, and take some time to do something I really care about. In this case, take some time each day to learn something new, something maybe you're not going to do in your typical daily work. Hopefully, you can do that at work. Hopefully, you can do something at work that maybe is from the other inbox, right? Some work that you're not usually doing because you can grow your skills there. That prioritizing makes a huge difference. Secondly, we've talked a lot about social environments and how...with other people that can really help. I know that when I've taken classes with people, I finish, and I enjoy doing it together. Finally, some people also brought up some really interesting ideas about being hands-on. If you really want to learn something, you have to pick a project and work on it so that you can actually have that experience rather than just kind of knowing about it at a distance. Also, about, you know, there's some talk about mentorship and that sometimes the best way to learn something is to teach. [laughs] And paying back is a really valuable thing to do as well. KYLE: Just a thought I've had during this. Hopefully, the rain outside isn't terrible. [laughs] But I was kind of thinking, one thing that drives me that I've had to become okay with is the idea of imposter syndrome. I've ran into impostor syndrome, I feel like, for most of my career. And it has taken me a while to realize that's not a bad thing, and that's a driving point. And that is something that can keep you learning, and don't be afraid of it. MIKE: Thank you. Talking about getting yourself in that uncomfortable situation, right? [laughs] Recognize that's okay, and that's how we learn. Thanks, Kyle. I think that's a great place to end our discussion today. Remember, you're not an impostor if you're actually trying. An imposter isn't trying. If you're actually doing the work, getting it done, well, you're not an imposter. You're somebody who's there getting the work done. It's been great talking to you all. I've liked hearing all of your different perspectives. We'll be here next time on the Acima Development podcast. Thanks.
Today's conversation delves into the multifaceted topics of learning, motivation, and engagement, shedding light on their relevance in both professional and educational spheres. The panelists scrutinize various job satisfaction elements, such as advancement, compensation, and engagement, with David notably challenging conventional wisdom on compensation, asserting that its importance diminishes once basic needs are fulfilled, and further arguing that increased compensation may actually hinder performance in cognitive tasks. The discussion then shifts to the exploration of engagement, centering on the acronym NICU (Novelty, Interest, Challenge, Urgency) as pivotal factors for maintaining investment in work. David and Mark reflect on their educational journeys and the transformative power of innovative teaching strategies. They illuminate the nuanced balance between engagement and disengagement, investigating the subtle boundaries between motivation and procrastination, and examining how an overwhelming workload can erode one's connection to their tasks. Transcript: DAVID: Hello and welcome to the Acima Developer Podcast. I'm your host today, David Brady. Today we have a fun panel of Eddy Lopez, Ramses Bateman, and Mark Hymowitz on board. And we're going to talk about job satisfaction and what you can do to find a job that you're satisfied with or that you could be more satisfied with. And I have a lot of thoughts and opinions on this. And I'd really like to hear from some other people before I stand up on the soapbox and start preaching. What do you guys think? What makes a good job? EDDY: We mostly try to figure out, like, what makes the job fulfilling for you, or, like, what do you like about the job? DAVID: I would say that's the first question you actually have to answer, right? Because I've worked at jobs where I was working on bleeding-edge technology from the future. I mean, we were strapping hover boots onto the cow. It was awesome. And I've also worked on jobs where it's just knuckle-dragging, mind-numbing work that, you know, from enterprise stuff from 20 years ago and not solving any interesting problems. But, boy, we were making the company money. It might surprise you to know that the technically challenging job was not very satisfying to me, and the mind-numbing job was immensely satisfying. I personally would say if we're going to talk about job satisfaction, I would say it needs to correlate directly to your happiness as a human being. Eddy, since you asked, basically, just for a split on that, let's start with saying what makes a job satisfying? EDDY: Personally, I got to be able to see movement, if that makes sense. Like, the moment I become stagnant and I feel like I'm stuck is where I start to lose interest, right? DAVID: Yeah. EDDY: Versus if they tell me, "Hey, this is your path. This is your course for success," and I can work towards that path, to me, that gives me the motivation I need in order to push forward and do my research and become better at my job. So, as long as I have a path for advancement and not a lateral movement, I'm pretty happy about that. So that's my primary reason for job satisfaction. A lot of it also has to do with, like, the work dynamic, the relationship between me and my peers, other sub-teams, you know, flexibility, time management, et cetera. But my primary one really is advancement. DAVID: Yeah, no, that totally makes sense. MARK: For me, I guess it would be to be able to look back and say, "Hey, this is what I've achieved so far." I like, for example, the Jira ticket system because it lets me kind of go back and see, wow, I've done all this over time. And I am achieving something every week or with every assignment. Doing a job where you're just mind-numbingly doing the same thing every day or seeing little results from it, for me, it's kind of off-putting. Being able to see that I'm growing and achieving something. DAVID: Yeah, it's interesting to have, like, younger perspectives and older perspectives and to hear myself in your answers. I remember being very, very excited in my 20s to be working on just, you know, high-tech, just amazing, you know, crazy stuff. And I got really surprised by working on some jobs that were kind of cutting-edge, bleeding-edge technology, and I ended up very unhappy at those jobs. I want to be clear here; the high-tech, cutting-edge was not what made me unhappy. Since then, I have worked on stuff that was just immensely fulfilling that was also, you know, new. But I was really surprised that I'm like, hey, why isn't there a strong correlation here between what I'm working on? Because I came out of there...the job that I'm thinking of, we were working on hardware. The NVIDIA GeForce had just come out, and I was working at a competitor company to them. So, people didn't know what the GeForce could do. They didn't know about hardware graphics acceleration. And I was working at a company that made 3D graphics hardware acceleration back when nobody else was doing it. So, we were working on version 3.0. And it was an okay job. But it was, like, really, really disappointing when things folded up, and I, you know, ended up on the [inaudible 04:25] So, the job that I went to after that, I ended up working in Java, which was not my favorite language. Java is very much a, you know, for me, it's, this is how we used to write software kind of language. It's like you're going back in time to pick up Java. Although, to be fair, this was 2006, and Java was actually, you know, fairly cutting edge. But I loved that job, even though I spent most of my job writing a database driver. Like, we were writing a full-stack application to do, you know, travel reservations for people in high adventure, like, white water rafting reservations. Like, we could book you a seat on a raft that was going down the Colorado River. It was really kind of exciting, you know, kind of cool stuff. And I was writing the low-level stuff to synchronize two separate databases to keep them in sync when they would be physically disconnected for up to 72 hours from each other. Like, you literally had people selling products out of the same database on two different servers that can't talk to each other because one of the databases is on a laptop up the river, literally up the river, with a paddle, with a whole truck full of paddles but no Wi-Fi. No way to get on the Internet. And so, like, the river guide would jump on the river, and he's selling stuff to people, which I realize sounds really, really weird, right? But, like, people would show up at the launch spot and say, "Hey, do you have any open seats that we could get at a discount?" He's like, "Yeah, sure, not a problem." And so, he had to be able to sell that from his laptop. So, I ended up having to synchronize databases that were, you know, disconnected for, like, you know, up to 72 hours. And it was the most fun I've ever had. It was just, like, grindy bit twiddling, you know, garbage coming in, writing our own read-write, you know, splitting adapter that would read from multiple, you know, multiple read databases but always send the updates to the same master if possible. I don't know if it was mind-numbing, but it definitely...if it weren't mind-numbing...The other half of the application was accounting. So, we literally were writing finance tables, like, you know, credit and debit into an account. And what's the current balance? And what's the report for tax season? Another thing that a lot of programmers don't find, you know, exciting. And I guess I will go ahead and spill the beans. I will let you guys know my secret, and that is there's a saying that you'll hear in this industry which is, "People don't quit their jobs; they quit their manager." And if you've ever had a terrible job and you think back to it, it probably wasn't the work that you hated. It was probably your boss or your boss's boss that you actually hated. I've met people who cleaned out sewer lines, okay. Their job was literally to shovel crap, right? We joke about that; oh my, I'm just going to go shovel crap at the software mines. No, these people were shoving literal crap. And they loved their job because their boss knew this is hard, filthy, thankless work. And we are good people. We work hard, we get paid, and we go home. The boss took care of his people. And his people were like, yeah, the job stinks, like, literally, but metaphorically, it's a fantastic job. I love my job. And it's surprising to hear. Like, you're doing the worst job I can think of, and you're happy in that job? And yeah, yeah, they were. So, I came across a piece of advice back in my late teens, which changed my world. I was about to head off to college. And this guy...I basically heard this guy talking. And he said, "If you have the choice between taking a super interesting class or signing up for the most amazing teacher that you've ever heard about, like, you've heard about the class. You've heard about the teacher, and that teacher is not teaching that class. You can either take the coolest class, or you can go with the coolest teacher." He just hammered on the lectern and said, "Take the teacher. Take the teacher every time." Because a bad teacher will make that awesome subject terrible, a bad teacher will make you hate that awesome subject. And the cool teacher could be teaching, you know, basket weaving 101 or just the most mind-numbing, you know, dreaded, boring points of industry legal factions in 1600 Europe, right? And you come out of that at the end of the semester going, oh my gosh, can you believe the legal implications of the 60 or 70 century Europe? And everyone looks at you like you're crazy because who cares? And the reason you care is because you had this amazing teacher. Oh, and by the way, you also got an A because you loved the work, and you got passionate about it, and you went nuts for it. And it's the people that you work with, not the actual work. And I think a lot of people, when they're first starting out their career, they jump on the best work, and that's great. Like, if you don't know what to do and you don't know anybody in the industry, yeah, take, you know, take the most interesting work. But if you have the option to go to work for somebody who's amazing...and that job where I was doing database synchronization was the first time I'd worked with somebody who was the most amazing leader I had ever worked for. Like, this guy he was not a good manager. He could not keep a schedule organized to save his life. But his leadership skills, man, we would crawl over broken glass for this guy just for the chance to lick a light socket for him. I remember telling him at one point...he was traveling on the road half the time, and the office was falling apart. And he's like, "What can I do to help you guys?" And I said, "Rodney, I don't know what you do here. I just know I need you here doing it because when you're here, nothing goes wrong, and everybody is happy. And when you're gone, everything goes wrong, and everybody is miserable." Yeah, it was because he was just the most amazing leader. When he was in the building, you felt safe taking risks. You felt empowered to get something done. You could get meaningful things done; important things could get done. And, yeah, we were closing tickets left, right, and center when Rodney was in the office. And when he wasn't, every ticket seemed to grow new heads of, like, well, we solved this, but there's this edge case that we didn't consider. And why a good leader made it so that tickets spawned more and more edge cases versus just closing them and getting them done, I still, to this day...I'm in my 50s now, and I still could not tell you why that happened. All I can tell you is that it did. And I worked for him for a year, and I had, like, consistent data. He would travel for three weeks, and everything would fall apart. He'd come back, and everything would get better. And then he'd travel, and it would all fall apart again. It wasn't, like, a sample size of, like, one weekend in November. It was a full year of this guy. And it's amazing. So, yeah, if you have the chance to work on a great project or if you have the chance to work for a great team or with a great manager, take the people every time. Take the people. That's my big spill-the-beans secret for the podcast. So, I'm done. What do you guys want to talk about? [laughs] RAMSES: In regards to this job satisfaction, one of the things where I feel satisfied about my job is, or most satisfied about my job, is when I'm learning something. I feel like if I do something for too long and I don't learn anything; I just get bored with it. DAVID: Yeah, it gets mind-numbing, right? You're just, like, ugh. I've always been an autodidact, somebody who teaches themselves constantly. And I've literally had a boss tell me, "I'm not paying you to learn. I'm paying you to get stuff done." And I just had to laugh. So, what I did is I just made sure I was learning when he couldn't see me because every single week, he would sit down, and he'd say, "Well, I want you to do this." And he would name something that had never been done in our industry. Nobody knew how to do it. So, he was actually paying me to learn. I just thought it was ironic that he thought he wasn't. EDDY: Yeah, that's me every day. MARK: That's why we're working here. We're being paid to learn, and we're using our knowledge to build up Acima. DAVID: Absolutely. EDDY: I think what's also really important is having someone give you the patience, you know, that you need in order to get over the hump or something that you're stuck in. And I'm indebted to so many people [laughs] at Acima. It's insane. Like, I couldn't have gone as far as I have now had it not been for my peers having the patience and the willingness to help me. I think that's attributed a lot to my satisfaction here thus far. DAVID: Yeah. I think I've said this before, maybe not on the podcast. But I've never seen a company with such an aggressive in-house career pipeline. Ramses and Eddy, were you both in customer support, customer service before moving into QA, before moving into engineering? Didn't you guys both come from QA or support into development? RAMSES: Yeah. DAVID: Yeah, that's rare. EDDY: Not quite. [laughs] DAVID: Not quite? EDDY: Not quite. I'm almost there, but not quite. DAVID: You're moving into engineering, correct? EDDY: Yeah. DAVID: Forgive me, I thought you were already here because of the level of competence that you have demonstrated and the amount of time that you spend, like, in the skills clinics class. I've worked at a bunch of companies that tolerate the engineers doing a skills clinic, as long as it's, like, at lunchtime and not on the company dime, right? I've worked at a lot of companies that were like that. Acima is the first place I've ever worked at that said 10:00 o'clock every day, stop what you're doing, and go to skills clinic because that's the most effective thing we can do to get stuff done. It's not going to get the most done today, right? And it's a 12.5% tax, right? I mean, it's one-eighth of your day, every single day that we're taking out of your work schedule. But we're banking on the fact that we can get 10 to the 100th power out of you a year from now. And it pays itself back in exponential dividends down the line, you know. Having somebody hang up the phones in QA for an hour, well, next year, we get that person as an engineer. And it's just the start because the year after that, we get that person as an intermediate engineer. And five years from now, we get that person as a senior engineer. And all because we said, "Hey, why don't you sit down and let's learn how to write a web server, or let's learn how to use the SQL gem, or let's learn how to do, you know, this thing. Let's write a compiler for, you know, a couple of months." I just think that's amazing. [crosstalk 14:58] EDDY: I mentioned this, and I'm sorry if I put you on blast in front of millions of people that listen to this. But you were the very first person that taught me how to create a branch from GitHub. DAVID: Oh, wow. EDDY: And how to push it up. You legitimately spent, like, two hours walking through step by step on, like, how the architecture works using Git commands in order to get it up in the cloud. Like that, for me, I'm just like, oh my God, I have someone who's a senior developer in their own right, who's been in the industry for years, and he's spending an hour or two out of his day, you know, teaching me how to do a simple task, as simple as checking out a branch in GitHub. Thanks to you, I had my very first branch created, and then, ultimately, it got merged. And I do want to say that that's paid its dividends because I've also helped other people interested in that as well. DAVID: In defense of you, it did not take you two hours to learn how to create a branch, right? We dove in, and we explored this is how Git works. This is how Git thinks about your project. And once that light bulb went on, pulling down a branch, you're like, oh yeah, I can totally see. You had this mental model in your head of this is what GitHub is holding. This is what's on your hard drive. This is how Git's organizing. That's how Git is organizing this. And creating a branch is how you just create a leaf on this tree. And then, you can move that branch up to here and the differences between merging and rebase. And I knew when I sat down with you that teaching you how to pull down a branch would be trivially easy once I explained how all of Git worked. [laughs] And I knew that showing you how all of Git worked was going to be the slowest way to teach you how to check out a branch, but, like you said, would pay dividends down the road. Because now we've got all the people around you know how Git works. And that's absolutely in your defense. Yeah, absolutely. EDDY: Yeah. Yeah. No, I just wanted to make it known in case, you know, I've never expressed that. So, thank you for that. DAVID: Thank you. I'll give you your 20 bucks after the podcast. Thank you. EDDY: [laughs] While we were talking, I did look up an article online that gives you, like, a guideline of what topics make a job satisfactory. So, I was thinking maybe if we can go through that. DAVID: Yeah. EDDY: The first one is advancement, and I think we did touch on that. And I think I guess we can all just agree that a sense of advancement in a company gives you the motivation to continue. The second one, and I think it's just as important, is compensation. And I think that attributes a lot to people's, like, longevity for employment. Would you agree? DAVID: How much time do we have? No, I don't. There's a whole slew of studies that have come out that basically show us that once you have enough compensation to pay your rent, buy your groceries, to live comfortably, and, you know, have just enough disposable income to not go crazy, compensation becomes one of the least important parts of your job. After you break out of the poverty line, compensation just becomes a score. And, yeah, it's fun bumping up that score. I got to be honest with you; I enjoy that. But it's so low on my feature list. The correlation, however, or the other half of this, is that when compensation is not sufficient, it's the only motivator, right? You could have the best job in the world, with the best people, doing the most meaningful charitable work in the world, really improving the lives of humans around you. And if you can't make rent, you have to go flip burgers at McDonald's to make up that money. If you don't have enough money, it's the only motivator. I will just throw this out for people that want to look at this; go Google Drive by Dan Pink. Google it or search for it on YouTube. There's, like, a half-hour version where he gives the full talk. And there's, like, a five-minute synopsis. There's a really good one (This is old, and it's going to date me.) where it's the YouTube channel where the guy draws on the whiteboard. And, like, he makes an animated sketch of the entire talk across the whiteboard. And if you find that one with Dan Pink's Drive, it's fantastic. He gets into the other side of it, which is that they've shown that if they escalate your compensation in a job where you just have brain-dead physical labor if they increase your compensation, your output goes up slightly because you'll sweat harder, right? You'll knuckle down and like, ooh, I want that extra, you know, I want that extra bonus at the end of the day, and you'll sweat harder. But if your job is to think, the more money is on the line, the more stressed out you get, and the lower your performance becomes. And it's dramatic. Like, if we say, "Hey, come solve this logic puzzle. If you can solve this logic puzzle in five minutes, and it's, like, one sentence or two sentences, so it's an easy solution, if you can solve this in five minutes, we'll give you $5." And a lot of people can solve it. And then they sat down, and I want to say they went to India, and they basically gave...I can't remember, but it was a lot of money. It was, like, two or three days' wages. So, like, for us, it would be like somebody sitting down and saying, "If you can solve this logic puzzle in five minutes, I will give you $1,000." Now you're thinking about the $1,000 instead of thinking about the logic problem. And presto, you can't solve the logic problem because you actually need your full brain to do it. I will agree that if your compensation is insufficient, it's the only thing. And I can also say I've worked at a company where I wanted a raise, and I felt like they promised me a raise and based on my performance. And, at the end of the time period, by every plausible metric, I had blown the doors. Like, my manager literally said, "You have blown the doors off of your performance review, drastically exceeds all expectations. Oh, but we recalculated the budget this year, and we can only give you a third of the raise that we promised you." And I was [inaudible 21:08] because I had busted my back because I wanted the raise, not because I wanted a pat on the back from this manager, but because I wanted the raise. And I didn't get the raise. And over the next, I think, nine months, I kept pushing on my manager, like, "You really need to give me this raise. You really need to give me this raise." And he's like, "Well, we can't do it. We can't do it. We can't do it." And then I gave notice. I'm like, you know what? I'm going to go work...and I literally told him, "I don't have another job lined up. I'm just done working here." Now, to be clear, I was really sick of my boss. I was really sick of his boss. And I was really sick of the president of the company. They were all very miserly. And they also had a lot of contempt for their employees. Like, it was apparent they were better than you; that's how they felt. And I turned in my notice, and my manager said, "I'll give you three times the raise we promised you." Just on the spot, like, I will give you a raise. And, to be clear, we're talking about dimes and nickels here. The raise they promised me was 2,500 bucks per year, and they gave me a $1,000 raise. And he came back and said, "I'll give you a $9,000 raise effective immediately if you stay." And I lost it. I became absolutely livid. I'm like, "Rob, what you're telling me is that you've always had enough money to pay me what I wanted. And you just wouldn't give it to me. No. You have just doubled my reason to leave. I really just don't want to work here anymore." Then I walked out. So, yeah, compensation, eh. MARK: It sounds like you experienced exactly what you were telling us at the beginning of this podcast, that you quit the manager and not the job. DAVID: Yeah. I think we've beaten compensation to death. What's next on the list, Eddy? EDDY: Yeah, the next one is engagement. So, what holds your attention? It keeps you invested while you're working. And some people attribute that to be just as important as everything else on the list that we've mentioned. And I think I've mentioned that too, right? Well, sort of. My job needs to continue to be interesting and challenging, or else I'll lose interest. Now, to be fair, personally, that's how it's always been since I started [laughs]. Like, I'm always being dealt with challenges, and it's great. DAVID: Yeah, I learned a really great acronym, and I can't remember where I found it, and my Google-fu has failed me. So, anybody listening to this, if you find it, please contact us and let me know where you find it. But there's an acronym for things that engage us, and the acronym is NICU, like, natal intensive care unit. But, in this case, it stands for Novelty, Interest, Challenge, and Urgency. These are the four things that will get you out of bed running to your computer to get some work done, that will sharpen your focus, you know, to a razor's edge. And we were talking about attention deficit disorder, which is something that colors my life excessively. I'll just say it that way. And so, I have to learn how to work with my strengths and not work with my weaknesses, or I get just destroyed. And people with ADD we are much more slave to NICU, to novelty, interest, challenge, and urgency. And so, if you don't have these things, you can disengage, right? And, yeah, if you don't feel like you're getting anything done, it can disengage you as well. MARK: So, I think I can see that. During college, I was very disengaged with a lot of my classes just because of how I was taught. But then, like, outside the class, I'd be interested in basically the exact same thing, either by watching YouTube videos or doing [laughs] online challenges. DAVID: Yeah, if this doesn't describe you, I'm certain everyone listening to this knows somebody who, the night before the end of the semester, the teacher basically, you know, grants a plea bargain to the student and says, "You're currently getting a D- in my class. You haven't turned in any homework. I will give you 70% credit for everything you turn in all the way back to the beginning of the semester if you turn it in before the deadline tomorrow." And then that person stays up all night. I've been this person. I've been this person multiple times; I'm ashamed to say. Where it's like, oh, okay, yeah, I could not get engaged. I physically could not force myself to do the homework when it was assigned. But now that it's like, oh, I've got a D- and you're telling me I can raise this to a B+ by doing all of it overnight? That's urgent. That's a challenge. Now I'm interested, and now I'm engaged. And, yeah, you stay up all night just slaving away. And you have fun. You actually enjoy doing your homework, which is what the teacher wanted you to do from day one. MARK: Question is, where's the line between you just not being engaged and when you're just being a procrastinator? [laughs] DAVID: Well, for me, about 20 milligrams of Ritalin. [laughter] I'm kidding. I'm kidding. But Ritalin doesn't actually help. [laughter] It's a good question, right? If you've ever been in a meeting with me where we're talking about a subject or a topic, I will ask, like, really far-reaching questions about, like, who's using this, and what's important to them? And who's using their product, and what's important to them? And people are like, why does Dave care what's happening seven time zones away with people that are using this business that uses our product, you know, that we are writing? And the answer is because once Dave can see where the software is going through the entire world and can see someone getting happy as a result of the lines of code that he writes, Dave gets really excited about the software. And he will stay up all night writing database splitters and grinding accounting code. And it's, like, programmers want to work on cool stuff, and that's, you know, we all talk about that. But there's a dirty little secret of computer science, which is it's all cool stuff. The only thing that's uninteresting to me is when nobody cares when you write it and, meh, thanks, and one ticket moves. Or you don't even have a ticket, right? It's just like, oh, yeah, cool, meets the expectations. Ahhh, yeah, it's soul-draining to have that. MARK: You've got me thinking now. I'm now remembering my high school math teacher who said all homework was optional. Paying attention in class was optional. You could be drawing in class or whatever. As long as you did well in the tests, in the final, he didn't care what you did. And he made a habit of every 20 minutes in class; he would stop the class and say a random joke or go off topic completely just to make sure everyone was focused, engaged because he read somewhere that the average kid's attention span was 20 minutes. And, as you get older, that attention span starts to shrink. So, trying to listen to someone or teach someone something for longer than 20 minutes at a time, you need to give them a break. Otherwise, things start going in one ear and not the other. DAVID: Yeah, totally. There was a professor at my university who did the most cunningly evil thing I've ever heard. He started class on day one, and he said, "I'm going to give the lecture, and I have inserted an error into the lecture. You get plus 10% to your grade...on any assignment you turn in, you get 10% extra credit if you can write the error down. If you can catch me making the mistake and write it down, and then correct the error, you get, like, this big jump on your grade." And now, everyone is watching the whiteboard like a hawk, right? Just, okay, did he put all the, you know, pluses and minus? Okay, yeah, he did. The parenthesis are matching. Ah! There it is. He made a mistake right there. And you just, like, all the pens are like [vocalization]. You're like, oh, like, if you weren't paying attention, you're like, oh, sounds like he just made the mistake. I better check what's on the whiteboard, right? And now, even the people who weren't paying attention are paying attention. And it was awesome. And the reason it was evil, I mean, it was genius to have done that to the entire class because he had so much more engagement as a result by putting in this challenge, this interesting challenge, like, interesting challenge, right? Also, novelty, right? Like, I've never had a teacher pull this kind of, you know, BS before. The reason it was evil is the last week of class...this was calculus. And he ground into one of the really hardest theorems that we were going to try to understand. I want to say he was taking integrals of, like, trig functions. So you had to...we'd been thinking in differentials and changes all semester. And now we had to think differentials and changes in circles because we were working with trig functions, right? Things that go around and around. And he went all the way through the whiteboard and through the class, and we couldn't spot the error. And so, we all had notes from everything he had written. So, we all went back. And we went through everything top to bottom, and we couldn't find the error. And, like, I went through my notes, like, three four times, and other people in the class, you know, multiple times. I went through my notes twice, let's be honest. I went through twice. I wasn't that dedicated. But yeah, came to class to turn in homework, you know, the following two, three days, you know, the next day of lecture was, like, a Monday, Wednesday, Friday class. So, we come back in on Wednesday, and he says, "Yeah, so there was no error in yesterday's assignment. I just really wanted you guys all to study the crap out of differential on trig." [laughter] And it worked. And we all did it. And -- EDDY: That's -- DAVID: We laughed, right? MARK: He played you guys. DAVID: Yeah. MARK: He played you guys. [laughs] DAVID: And I got 100% on that part of the test, and I did really well on the rest of the test because of how he'd done. EDDY: He found a way to engage you. And I think that's key, right? DAVID: Yeah. EDDY: I think there's a thin line between engagement because there have been times or situations, personally, and I think maybe some people can relate where, like, if you feel overwhelmed taking, like, a task, right? Like, your engagement slowly goes down, right? Because you see no purpose. And that's part of the reason to why, like, a teacher or a mentor is really important if done correctly because even if you hit those bumps, there's just methodologies on getting unstuck, right? DAVID: Yeah. EDDY: I actually wanted to say something that's kind of interesting, kind of, like, as a side topic to that. And I think I had a professor in college who had, like, three classes, and, like, his attendance for each class was, like, 15 students, a little over. And it was English, and, to myself, I was just like, there's no way this teacher reads all these essays. And, like, these essays we were turning in were, like, 15 pagers, front and back. And I'm just like; there's just no way he reads through everything, right? And so, like, one of his assignments somewhere in the middle, I tried to be funny. And I was just like, if you read this sentence, I'll buy you a pizza. And I continued with my research, right? And a couple of days pass. He's handing them out. And he hands it to me, and he's like, "What do you know?" He's like, "You owe me a pizza." He continues. [laughs] And I was in awe, right? And I gave him his pizza if you're curious. But, in reality, I was just like, wow, wow, right? DAVID: Yeah. And what's the message there? The message is, Eddy, you are important to me. And that's why I'm paying attention to what you're writing, right? EDDY: Yeah. DAVID: It's not that I paid attention. It's not that, oh, I'm a good teacher. Look at how clever I am. It's, you're important to me. MARK: Now give me the damn pizza. [laughter] DAVID: Yeah. Now give me the pizza. Yeah, right? [laughter] And now, helping you be honorable and fulfill your commitments is important to me, too, so give me a pizza. [laughs] We are getting close to the top of the hour. Do you want to just burn through the rest of the list? EDDY: Sure. The other ones are flexibility, proficiency, security, teamwork, and value. DAVID: Nice. EDDY: Yeah. And I think all those are pretty strong [inaudible 33:41] in their own right. We can even enlarge that and make it its own topic, honestly. DAVID: Yeah. If you go check out Dan Pink's Drive, he gives, like, four or five things. And there's a really strong matchup, like, the ability to get better at a hard thing; mastery is what he calls it. But that's, you know, challenge, and proficiency, and engagement, right? The ability to get better at something and to be recognized for getting better. Yeah, it's well worth the read. It helped me understand...I had...the year prior to Drive coming out or two years prior, I had taken a job. I was already in the industry. But I was making pretty poor money. And I got a job making double. But, I mean, I was already, like, a salaried software engineer. Making double was big money for me. And I was working for a lawyer who was, in hindsight, a psychopath. Like, I genuinely believe the man was a psychopath. He liked making people suffer. And I quit that job after, like, three months. I lasted a very, very short time at that company because this guy would come in, wind me up, and piss me off, and scare the hell out of me, and then giggle and walk off. And I'm like, no. No amount of money is worth this. And it literally...I went back to, you know, about half of my salary. And I was making money in the 30s. So, you know, the job working with this guy was in the 70s, which, 20 years ago, again, big, big money, especially for Utah, right? Where the, you know... And my wife, I came home and told her I had quit my job, and she's like, "It's about time." I'm like, "What?" She's like, "You have hated this guy since, I mean, this guy has just made you miserable. And you have been miserable to be around as a result. So, yeah, it couldn't happen soon enough." And I'm like, wow, okay. We are out of time. Thank you very much. This has been a lot of fun. And I hope to see you guys next week.
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. Transcript: TAD: Hello and welcome to the Acima Development Podcast. My name is Tad Thorley, and I'm hosting today for the first time. We also have a whole host of guests today as well. We have David Brady. DAVID BRADY: Howdy, howdy. TAD: David Solano. DAVID SOLANO: Hello. TAD: Eddy Lopez. EDDY: Howdy. TAD: Matt Hardy. MATT: Hello there. TAD: Mike Challis. MIKE: Hello. TAD: And Sergio Peralta, who's also new. SERGIO: Yeah, I am new. Hi, guys. TAD: Our topic today is, how did you get up to speed when you're starting with a new codebase? Also, with that comes along the idea of working with legacy code. One thing I was thinking I'd start with is maybe focus on a Rails project because I know we all are familiar with Rails, and then maybe expand that out to just codebases in general. My first question for you guys is, when you start brand new with a new Rails codebase, what is the first file that you think you look at? MATT: I'm going to say the gem file. DAVID SOLANO: Me too. TAD: Cool. What does the gem file teach you? MATT: By looking at the gem file, you can see some of the project's dependencies, some of which you may already be familiar with. And that can really help you learn your way around a project, just knowing the tools that are being used inside of a project. For instance, if I look at a gem file and I see Grape API in there, I know where those endpoints are going to be, and I know how they're going to be structured, right? TAD: Right. I think it's interesting. You can often see, like, Ruby version; sometimes people will put it in a gem file, internal gems. DAVID BRADY: I was going to comment that I have a weird answer to the what file do you start with? And the answer is no. TAD: [laughs] DAVID BRADY: My favorite place to start is by pairing up with somebody and having them show me the app so that I know what it does. And then, like, very, very quickly, somebody who will sit you down, and they'll say, "Okay, let's go here." And then they will casually mention offhand, you know, "Oh, this whole section is generated. It's just static. It's generated by Jekyll." And I'm like, ah, okay, I know where all of this section comes from. After I pair up with them or while I'm pairing up, I will often pull up the directory listing of the root of the project and often app models and app controllers. And I'm trying to come in very breadth-first, very top-down. So I can work on a project for a day or three without ever opening a source code file to look at it but probably because I'm a bad programmer. But I like to get the layout of the forest before I, like, take a core sample out of a tree. Does that make sense? TAD: Sure. Yeah, [inaudible 02:57], right? DAVID BRADY: Mm-hmm. DAVID SOLANO: I [inaudible 02:59], David. I pretty much do the same. But if you ask me to look, like, one file kind of just to have, like, a quick look of the entire project, I will say a gem file, but I'll also take a look at the application controller. And you'll see some weird stuff happening there. TAD: [laughs] Yeah. DAVID SOLANO: I'll give you an idea. Like, I remember one time I saw it, and I saw an application controller from really old code, right? Like legacy. I don't know; it was like 3,000 lines. [laughs] So it was pretty funny at that time, right? TAD: Well, it's interesting to see some of these, like, grandpa classes that everybody's going to be inheriting from because, a lot of times, there will be behavior that's happening there, maybe like a before filter or an after something going on that is always happening, but you don't realize it because it's kind of tucked away. MATT: Yeah, I think Dave brought up a very good point, though, if possible, the most important thing is let's look at a running version of this application and have a tour of the UI. You know, you can learn a whole lot just by seeing the UI of something. You get a feel for how it works. And then I also really liked how he said top down. If I'm going to get into the code and look at something, the first thing that I'm going to look at are the endpoints, right? Because that's the entry to everything. And I think if you can track down the proper endpoints, you can find your way through the entire integration of that particular feature. TAD: No, I agree. Finding kind of the entry point into the code is really valuable. And the parts that you present to people are probably some of the more important pieces, right? MATT: Absolutely. Any transformations that happen can be tracked down as long as you can find your entry point. I mean, with modern IDEs, it's pretty easy to navigate your way through code and kind of fumble your way through to see where things happen. DAVID BRADY: I think it might also depend on your team style as well. Like, I will often open a project and like David was saying, drill into, like, the applications controller, but I will do it, like, dynamically. I'll just go to the project and do Rake routes and say, okay, you tell me where these things are coming from. And that'll show you things that are mounted in the app directory that aren't in the app controller. They're brought in from somewhere else, and that sort of thing. But it'll also show you in a hurry if the team cares about what the Rake routes thing returns, right? If you get 700 lines of RESTful routes and it's just create-update-edit, create-update-edit, you know, da, da, da, you know, over and over, no, no, you're just like, uuh, okay, all right, [inaudible 05:50] [laughs] to do this. But if the team does care about it, if it's, like, maintained and very, very careful...which actually dovetails on to the next idea, which is the next place that I will check is I'll try to run the spec suite. And you very quickly find out if the team is writing specs, like, after they write the code, if they just try to bolt down the edges of their features, or if they started with the specs first and said the app should do this. And now when you open up the spec file, it says, oh yeah, the app does this, and it does this, and it does this. And you drill under that [inaudible 06:19], and it does this way, this way, and this way. And you could really see that. It's almost like recognizing handwriting in the code. And that goes into, like, gathering the lay of the land on a project. You very quickly pick up, okay, that developer is very terse and very direct. And this developer is very verbose and nuanced. And it changes how you pick up their code and how you follow their breadcrumbs. TAD: Right. I still remember I was on a team, and one of my co-workers asked me, "So, what does this feature do?" And I said, "Oh, well, I wrote a bunch of tests." I told them where the tests were. And he's like, "No, I don't care about the test. Just tell me what it does." And I was kind of dumbfounded because, for me, the tests are telling me what it does, right? Like, that was the obvious place to learn what something does is by going and looking at the tests, but his approach was a little different, I guess. And it sounds like you're kind of the same way, Dave, where you would love to see some good tests to really get a grasp of what's important, what people's styles are, what it does, right? DAVID BRADY: Mm-hmm. Absolutely. At risk of ending up on a soapbox about specs—and some of you have been to conferences where I've really gotten on my soapbox—there are multiple audiences for testing. And a lot of people don't care about the first two audiences. And that ends up creating low-value tests, which is sad because the reason they don't care about those first two audiences is because they've been brutalized by low-value tests, and it's a vicious cycle. You write them bad; you get them bad. But the first two audiences of a spec file is, if I pull down the app and run, you know, migrations and boot everything up, I want to run the spec suite. And I don't want to have a conversation. I just want a green dot or a green okay. Does the app work? Does it take over? After that, the next bit of audience is, if I'm coming into a piece of code that I have to maintain, I will go to the spec suite and say, can you tell me the story of this? What does this code do? What is its responsibility? What's it [inaudible 08:20] Don't tell me how it's doing it, just tell me what it's trying to do. And then do I care about drilling in to say, you know what? How does the API work? How does the code work, and what are the implementation details? And if you care about those first two audiences and getting those things airtight, the spec suite will get your back later on. And, yeah, when you come into a team if...and this harks back to what I just said about, you know, the team style. If the entire team doesn't care about the test suite, the specs won't get your back, right? They'll be very sparse, and there'll be lots of gaps. And, you know, you come behind and do your best to preach in the wilderness, you know, to repent and write better specs. TAD: To further your point, Dave, you'll know which flags they use when they run their tests even? DAVID BRADY: Yes, right? MATT: Thanks for saying that, Dave. Because I think something that really helps define how I would look into an unknown codebase is team culture. Any of us who have been in this industry for a length of time we've worked in codebases where there aren't any tests, where that culture isn't there that people want to help you out. If I walk into a great culture like we have here at Acima, the first thing I'm doing is I'm pairing with someone. And they're going to walk me through the code, and they're going to lend me some assistance. And they're going to explain how things are tested, and why we test, you know, and the importance of those things. And I think culture has a really big role to play in this. DAVID BRADY: 1000% to that. I moved last year from the Atlas Team over to the Data Services Team because I really wanted to get into big data. And one of the things that surprised me is that our process over on data services is a little bit old school. It's a little bit enterprise. It was where software development was in, like, 2005, like, pre-agile. And I'm not saying that to criticize the team. It's just that's just, like, the way the culture here works. So we don't use tests. Developers work alone. They want a quiet office so that they can think and get really, really deep in the code. That creates some artifacts, right? There are files in the codebase that have been abandoned for three years. And you have to know when you get into a file, oh, I need to go check git. This is not even, like, an indictment of my current team, and I don't mean it that way at all. You have to come to the team from their culture, right? You can come into a piece of code and go, this makes no sense. How does this ever...oh, wait a minute, git log. Oh, this was last tested in 2017. This is probably not current code, okay, cool, fine. And then, you can pick it up and move to the next piece. And you run into a piece of code, and you're like, how the heck does this work? And you have to, instead of saying, well, the Atlas team, I would expect a very shallow cut, a very quick test, a very high-level, you know, break this down just this one piece, [inaudible 11:14] detach this and run it. But on data services, I expect a data warehouse to be present. I expect a lot of, like, very expensive dependencies to be present. I expect to lean on those very, very heavily. And so, I'm not expecting a small cut. I'm expecting to pick up this entire ETL file that transforms the data out of the merchant portal database and moves it into our data warehouse. I expect to pick up that entire chain and hold it all in my head because, remember, we are working...we're not pairing. We're not doing any high-bandwidth communication. We're doing slow, deep thinking about how we work with the things, and that really, really dramatically affects, you know, what direction the code is going to be in. I'm not going to go look for a test. I'm going to dig into this file, this file, and this file because we have a working template of how these three files always fit together. TAD: Yeah. We've heard from probably, I'd say, some more of the senior folks on what they look for and what they do. I'd like to also hear from our newer folks. Eddy, when you get a new codebase or you're exploring, what's your approach? EDDY: To give you a bit of perspective, I want to premise saying that I only got about a year and a half of experience total, and I probably went on it the wrong way. I didn't ask the right questions. I was just too eager to pick up, like, tech debt tickets. And so, I got familiarized with the code by picking up work that didn't have as much attention. And I slowly trickled my way through the whole codebase based on my necessities. In hindsight, that's probably, like, the wrong way to do things, at least to me with having a bit more wisdom, not a lot but having a little bit more. Seeing other people's approaches to tackling new codebases is amazing. Like, you, for instance, made a comment about I like to look at the biggest file. Like, so if you look in the app directory for models, for example, the biggest contender for that was lease. And you're like, huh, Acima does leases. And I think, for me, that would have been something to truly understand before I even picked up any changes because, in order for the changes that I'm implementing to be efficient, I also need to understand at the core what the app is doing. And that was my biggest fault when I first started. So I would say grasping the fundamental core of what the actual app that you're developing for does. And one thing that really solidified that for me was running the app as an end user. So I played around with it, played around with the functions. What am I able to do? But you mentioned something really important that I've done without even realizing is ask for help, right? TAD: Nice. EDDY: Asking my peers what their experience is like with the code changes that I'm supposed to be making and have them just take time to really drill that in my head. I think that's really helped me out a lot. DAVID BRADY: I just want to back you up, Eddy. I don't think you were wrong with your initial approach, like, jumping in, grabbing, like, a corner case ticket or a weird, you know, bit of abandoned work. First of all, that's proactive. You're not on your back foot waiting for your manager to just throw stuff at you. You're actually, like, going in and saying, "What can I go get?" And that changes your attitude. And then the other thing is you would pick something up and try to figure it out. And one of the most powerful things you can do is just grab one piece of data and follow it completely through the system. Like, from the moment a user typed it in on the web page to when it ends up in the accountant's reporting spreadsheet, how did that get through the system? And knowing all of those pieces. You have to string all of the beads onto the string that represent the app. And that is super powerful. It gives you a ton of context. DAVID SOLANO: It's also [inaudible 15:07], for example, so you receive, like, some ticket with a new implementation. But maybe no one knows how to get that calculation right. But you know that your PM or someone else knows that that's reflected somewhere in the UI. And you know that if you go to that specific part of the UI, and you find that number and say, oh, hmm, here it is. Now you follow back to the code, to the back end. And then you know, oh, this is how the way it works. And if you're able to follow that approach also, that's a good way to do your work, to come to the idea on how to solve this because you already...you were able to follow it through the UI and through the end code. TAD: I think it's interesting that there's different approaches. And I don't know that certain approaches are necessarily better than others. And sometimes it's just, like, the approach that works for you given your current familiarity, experience level, that kind of thing. Sergio, I'd like to hear from you because you've recently joined the team. And you've had to do this where you came in, and we said, "Here's a codebase. Figure it out and go." What did you do, and what was your experience? SERGIO: Yeah, yeah, I have a nice history behind this. Like, I don't have a very big experience with Ruby on Rails. I am coming from another stack. And I am facing two different things; one is lacking the knowledge of Ruby on Rails in some things, and also the lack of the knowledge of the business rules behind, and the legacy code, and the [inaudible 16:43] of code. So my approach right now is, yeah, seeing that unit testing, getting a know of how the application works. I've talked with other people about if they have this kind of issue before and also with most experienced people about how to do some specific things. So, yeah, what I can tell is, like, I am the kind of people that like to learn myself is, like, trying to figure it out by myself. If I don't spend enough time to try to figure it out by myself, I guess I don't move in the right path. It is like having someone else telling you how to do it step by step is good. But, at least for me, I need the time to process myself and figure it out myself and struggle with some stuff, then continue with the role. That's what I do usually. But it is, like, the way I learn. So that's the thing I can say. TAD: I think that's a fair point because definitely, the code I've thought about and struggled with is the code I remember best, right? EDDY: I want to really fixate on what you just said, Tad. Holy cow that resonated with me deep down. The tickets that I particularly struggle with the most are the ones that not only grow my skill as the developer but also, like, really drill down [laughs], you know, for my fundamental understanding of that particular code change that I'm making. I also want to say thank you, Dave, for reaffirming my path initially for merchant portal's codebase. DAVID SOLANO: Hey, guys, I don't know this...this is out of topic. But right now, I am using this ChatGPT tool in some cases where, hey, what if we can improve this code? At least for me, I don't have the sense that the code is wrong. But I just paste the code, check what ChatGPT is thinking, and just let's compare it with my notes and see if the things are good or not. Yeah, sometimes, yeah, I got nice answers, sometimes not, even the code doesn't run. But I like it. It's a tool that is helping me in some stuff, maybe when I feel stuck with something. But, yeah, just to mention. I don't know if it's out of the pocket but yeah. DAVID BRADY: I've played with ChatGPT as well. And the thing I love about asking it to write your code for you is not that it's going to write the code but that it will say, "Okay, well, here's a block of code." And then, in plain English underneath the code, it starts breaking down the code that it just gave you, and it says, "Okay when I do this, it's setting up this kind of a thing. And then I'm going to do a double dispatch into that. And then I'm going to do this, which is going to set..." And it walks you through how the entire thing... I asked it to write a really weird SQL query. And it gave me a SQL query and then broke it down and said, "When I use this window function, I'm going to get this, and then when I do this, I'm going to do a subquery." I'm like, holy crap, that's awesome. Yeah, I like the explanations that it gives. [crosstalk 19:58] TAD: It seems like pure programming but just with a bot instead of a person, right? DAVID BRADY: Yeah, yeah. EDDY: I've had ChatGPT breakdown code in certain aspects. And I'm like, huh, I don't really understand what this method is actually doing. So, like, I've copied and pasted in ChatGPT. I'm like, can you break down in layman's terms what exactly this is doing? And it kind of follows the same thing that Dave said where, like, it adds comments, you know, to each line of code and tells you, oh, this is what this does. This is what this does. This is what...I was just like, oh, interesting. I did not know Ruby was capable of such things. DAVID BRADY: I had a fun...it's a little bit off-topic, but it gets more into the ChatGPT thing. The other thing I like about it is it really does act like a pair. I asked it to write a bit of code, like, a Bash prompt for colorizing some things. Who keeps ANSI color codes memorized, right? And it came back, and it said, "Well, you can do this." And it gave me the ANSI color codes for the thing that I wanted. And then it said, "That works because this, this, and this." And it was wrong, the explanation. I mean, the code was right, but the explanation was wrong. And ChatGPT it's read-only in terms of the big brain. Like, when you finish a conversation, nobody can use the contents of your conversation. It's not modifying and updating the AI. But in the context of the conversation, it will act like a pair programmer. So I actually...I went, "Close, that's very good, but this is wrong." And I told the bot, "This is wrong. This piece actually means this, and this other piece means this thing." And then, because it's a bot and because it's AI, I said, "Would you try to explain it again?" And it gave me the code and the explanation again, and this time it was perfect. It said back in its own words what I had just told it about the code. I thought that was mind-blowing. Really great. And a good way to think, again, like a pair programming partner. TAD: Well, I thought it was interesting, Dave, that you pointed out that maybe step zero is not even read the code; get someone to guide you through the code. And it sounds like ChatGPT can kind of do that, right? Like, it can serve as a sort of guide as you're trying to understand a new codebase. DAVID BRADY: Yeah, it's going to give you what we're trying to accomplish along with the how we accomplish it. Yeah, it breaks it down at both levels. It's really neat. EDDY: Not to mention that ChatGPT is almost always available for you to pair versus asking someone else on the team who might be busy. TAD: Do you think we'll see more tools like that integrated in the future? I mean, we already have some pretty powerful plugins and IDE support and things like that for understanding the codebase. Do you think we'll get kind of cyborg-guided things as well? DAVID BRADY: I think it's inevitable, yeah. MATT: Yeah, I think -- DAVID BRADY: Everyone's afraid that, oh, the bots are going to take over my job. No, they're not going to take over your job. But your job in five years is not going to be to punch in all of the codes to create a Rails route in a back-end controller. In five years, the most effective programmers are the ones that tell their IDE, which is backed by AI, and say, "Give me this resource controller [inaudible 23:08] connected to that." And the AI goes da, da, da. "On this one connection, did you mean this or that?" "I want it that way." "Okay, cool." And it'll spit it all out. The people who can operate the high-level machines the best are the people that, you know, will have the best jobs in five years. And it's exactly the same way as we are. You go back 25 years; people were running...well, 35 years, people were writing code with text editors, with dumb text editors. And then IDEs came about, and our job now is to know how to run more and more sophisticated IDEs. I think that's inevitable, yeah. TAD: So your argument would probably be, when you first start, like, you were talking about meeting with somebody who could give you a tour of the overarching ideas, point out the different pieces from kind of the higher level thing. And it sounds like you're saying that's probably not going to go away, that you're still going to need to have someone that has an understanding of what needs to happen, what all the pieces are, and that kind of thing. But those pieces are maybe going to be, you know, bot-augmented, rather than you hand-code all of them. DAVID BRADY: Yeah, 100%. There's always going to be a market for somebody thinking. There is a fantastic quote that I saw about 25 years ago. I can't remember who said it, but the way they phrased it was no amount of best practices, industry-sophisticated tooling, or agile, or otherwise processes can take the place of knowing how to program a stupid computer. And I think that will continue to be true where the term program a computer is slowly turning... it's no longer dropping, you know, bit one, bit zero, bit one, bit zero into the CPU. Now it's more and more tell me how you feel, and I'll write an app. TAD: So one of the interesting things that was mentioned is, as you look through the code, you can kind of see people's signatures, so to speak, on different parts of the code. Does that become more consistent? And if the code becomes more consistent being generated by a tool, does that make it easier for a tool to then understand the code? DAVID BRADY: Ooh. I think the second half of that is going to be really hard because I think the first half of the question of does it become more consistent? I would say it depends on your team. If you're doing very high-bandwidth, high-pairing, lots of retrospectives, lots of communication, then, yes, the code is going to homogenize as everybody cross-pollinates, you know, best practices, you know, between each other. Where the team that I'm on, which is involving a lot of really, really deep thought, I have found really clever tricks that my co-workers have done in the code, but they're down in the code, and they're undocumented. And when I go into that person's piece of code, I will copy that trick for the next piece because it's consistent with their style. But when I then move from that person's code to another person's code who doesn't, it's clear from the context of the code that this person's skill set is way, way powerful somewhere else in the code. I try to copy that, but they don't understand that trick that that first developer was doing. I won't copy that in because that second developer is probably going to come back to this piece of code and maintain it. And I don't want to trip them up. So maybe, you know, maybe in, you know, 5 or 10 years, the bot can basically step in and say, "Okay, yeah, this team has a highly fractionated, you know, highly speciated personalities in the code." I've had long conversations with my boss about "I got some code, and I think it was written by this guy, Zack; just look at the file anyway." "Yep, that's him." And, you know, and we had a laugh about that person's style. And I think early cuts of the AI are going to make the mistake of thinking that there is THE way to do it. And later, more and more sophisticated versions are going to recognize that, oh no, there's a bunch of different ways to do it, and some of them are more appropriate to the given situation. EDDY: I kind of want to add to that if that's okay. The skills that I've learned so far have been with me stumbling upon the answer, right? Reading up on documentation about someone who ran into this problem once before and explaining the solution to how they got there. The reasons why I was able to remember those solutions so well was because I landed on that after probably half a day or a day, you know, for a solution that was so simple. I'm afraid that if we start relying a bit more on AI services that are just spoon-feeding our answers to our questions almost immediately, I feel like that may create bad habits in a sense and, therefore, like, losing retention on that answer, right? TAD: I think it's -- DAVID BRADY: There's a really fantastic book from about 20 years ago called The Pragmatic Programmer. And one of the chapters in the book is called Don't Trust Evil Wizards. And back in, like, Visual Studio around Y2K era, there were wizards that you could run. It was like a, you know when you do Rails scaffold, and it will generate the scaffolding for you. The wizard would do this. It would write a whole bunch of really deeply nested, complicated C++ code for you. And it would wrap it up in macros, and you never really needed to know what those macros did until you did need to know it, and then you were screwed because you had no idea how the wizard was doing it. And that's an evil wizard. Like, a good wizard is somebody who's going to, you know, scaffold out your code and then leave it all very clearly documented at a very high level. And then, yeah, you have to come back and follow through and understand what the wizard was doing for you. You don't want the wizard...and I realized that with AI being, you know, intelligence being the I in AI, you don't want your wizard to do your thinking for you. And that's the danger of AI is it really feels like it's doing thinking for us. And the first people to really leverage AI will be the ones who know how to constrain its thinking into the things that we can understand and maintain so that if we move outside the AI's, you know, knowledge or, you know, the power [inaudible 29:21] for that tool, that you're not left high and dry with wondering, well, how did it build this great, big, black box? You're like, oh no, I've got all the pieces. I can modify this from here. EDDY: Or what happens if you get...you're so acclimated to use a service that spoon feeds you, and then, all of a sudden, that service is down because that's inevitable, right? Services go down all the time. So, what are you going to do in that point when you're in a pressing...a time constraint, and you're like, oh, I really need to get this done? And, all of a sudden, the tool that you rely on isn't available. DAVID BRADY: Yeah, it's the 3:00 a.m. fire, right? Like, okay, it's just me, eMacs, and a server that's on fire. How are we going to get through this, right? For everyone else on the team, step one is shut down eMacs and start-up Vim. But I get it. DAVID SOLANO: Hey, Eddy. I have my thoughts about what you mentioned of bad habits. For example, look back in the past, in the '80s, when everyone who wants to make a program have to do Assembly coding. And right now, [laughs] it's nearly impossible that some of you guys use Assembly to write a program. So, yeah, it's like the technology is changing, and we are changing with this. And probably, I don't know if in the future we will be based only on the IA, so... AI, sorry. [laughs] But yeah, that's the point. It's like everything is changing. And probably all our habits will change with the tech. DAVID BRADY: I think so. I worry that we're getting off-topic of tearing into legacy codebases. But I realize I'm the problem as well as the [inaudible 31:02] concerned about it. But, yeah, I am the source of most of my problems. I wanted to shift a little bit to talk about a couple of resources that I have used for maintaining older code. Is now a good time to do that? TAD: Yeah, I think that's great. DAVID BRADY: Okay. I think most of us have heard about Working Effectively with Legacy Code. It's a book by Michael Feathers. And it's still the gold standard, in my opinion. He talks about, like, when you get a gigantic legacy codebase, what do you do? Like, when you have this big chunk of untested data with this hideous dependency, how do you dig into it? And it's a little bit like the old refactoring book where he literally gives you recipes, right? If it's this, you need to do, you know, extract static method, or you need to change the parameter of this but try to maintain the signature and that sort of thing. There's another book, though, that I think is this beautiful, beautiful gem. It's called Code Reading. And I'm going to mangle this guy's name, Diomidis Spinellis, I think is his name. But Code Reading is a book about reading code. He starts with the argument that every other creative endeavor that you go into, an engineering class or anything, the first thing they do is they sit you down and they make you study the masters. And, like, if you take a painting class, the first thing you do is copy different paintings in different styles to learn these artists' styles so that you can develop your own style. But when we teach software, we tell you plagiarism will get you expelled. Don't even look at anything outside of your paper. And that's crazy because when you get out into a career, your boss just wants the website to process a credit card. You know, she doesn't care if you wrote it all original code or if you had an AI, you know, spit something out. It doesn't matter. We just want it to work. TAD: Or Stack Overflow, right? That's -- DAVID BRADY: Yeah, Stack Overflow. TAD: [inaudible 32:48] Stack Overflow exists. DAVID BRADY: Yeah. And so Code Reading is literally a book on how to develop the skill of reading code. He makes the pretty bold argument that open source is just a godsend for us. He's like, yeah, you probably want to learn C. Now, this book is 10 or 15 years old. But he's like, you probably want to learn C because, like, if you learn just enough C to get around, you can now read the entire codebase of Linux and all of the tools that are in Linux because the source code is in C. And holy crap, right? It's like, you want to figure something out. And he throws a wild curveball, like, in chapter three or four. He's like, okay, write a program to calculate the date of the next Easter. You have one hour, go. And, okay, hang on. Easter falls on the first Sunday after the first full moon after the spring equinox. Oh, good luck, right? And he walks you through how you can solve this in 15 minutes if you know that Linux has a bunch of calendaring apps. And there's a function down in there called POTM, Phase Of The Moon. [laughs] And it will let you calculate what is the next full moon going to be? And it's hyper-accurate, and it works. I mean, it's good enough for the operating system. And you have to be able to surf into a million-line codebase and find the piece that you need, and then read that code in high detail and go; it's this. This is the math, and then this is the offset, and this is the thing. And you're like, okay, cool, and down the road you go. And you can build it out, you know. And that, I think, was a really, really good thing because he talked about the necessary grammars and patterns that you want to develop. Tad, you mentioned at the start that, you know, we'd start with Rails and then back up to general, and this is a perfect example of this is that when you're in a Rails project, there's a certain directory structure that you can expect. And there's a certain way that the resources are, you know, that we expect them. There's a naming convention for how tables work in the database. And if you switch from Rails to Django, that changes, or if you switch from, like, on the team that I'm on, we're all writing in Python. And we don't use a framework. We wrote our own stuff. But it is very rigid. There's a very solid process that we used for, you know, the way we get data from the database is standard. The way we transform it is standardized on our team. The way we load it into the warehouse is standard. And then, we write a custom piece for each of those three steps. But those three steps are very standardized at the interface or at the behavior level. And coming from Rails into this team, instead of saying, "Well, I expect there to be an app directory or a models directory and a DB directory," I'm just saying, "Okay, what is the structure?" Oh, the structure is we're going to have this directory, and under this directory, we have these subfolders with these files in them. And you, very quickly, you learn what is the layout of the forest? And that will tell you when you look at a tree, you're like, well, where is this tree? This tree is down in the model's directory, or this tree is deep in the ACL directory for this particular vendor. I'm like, ah, okay, I know where the holes are in this. There's going to be some holes in this file that are going to be filled in by the base classes because the app structure is going to take care of it for us. TAD: So a follow-up question that I had is, it seems like both when dealing with legacy code and just any new codebase, your ability to just read code and have experience with code goes a long way. And I like your idea that there's tons of open source out there. But the thing is, like, they're not all masterpieces, right? DAVID BRADY: No. TAD: There's some really bad open-source code out there. So my follow-up question is, how do you find the masterpieces in the sea of GitHub repos? DAVID BRADY: How does that old quote go? If you want to find a prince, you got to kiss a lot of frogs. I would actually say there's an essential code reading skill, which is the ability to, as you are reading through this piece, gets this, transforms this data, sends this message to this object. At the same time, you're doing that low-level, like, almost, like, compiling the code in your head to find out what it does. There's also another thread in your brain that's basically assessing the quality of the code that you're reading. Like, is this code easy to follow? And is it easy to follow because it's very clearly written? Or is it easy to follow just because it happens to be in my preferred style? And I love the moments...like, I don't know if I would recognize a masterpiece if it smacked me in the face. But I do know that I become consciously aware of the feeling of pleasure reading code; that's how I'll phrase it. I find myself smiling when I read code that I simultaneously realize I understand this code, and it's in a completely different style than what I'm used to, which means, in the worst possible way for this code to try to teach me, it's teaching me amazingly well. And that, I think, is...I don't know if it's a masterpiece, but it's certainly the code that makes me the happiest. I'm like; I want to write code like this person because they're communicating to a stranger very, very well what their thoughts are and how they want to accomplish the thing. TAD: Excellent. We're at the end of our time. So I'm going to...I think we'll just end on that and just encourage all of our listeners to go out and read some code, huh? DAVID BRADY: Right on.
There are things you work on that don't change your abilities much, and you can kind of fall into a rut and stay there. Then there are things that push your skills to the next level, and that's what we're talking about today: projects that propelled our skills, knowledge, and careers to the next level. Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. Today, we're going to be talking about projects that really propelled our abilities to the next level, projects that moved us forward. There's things that you work on that don't really change your abilities much, and you can kind of fall into a rut, stay where you are for a while. Then there's those projects that really push your skills to the next level. That's what we're going to talk about. What's the difference between those? What are some of the projects we've worked on that have made a big difference for our skills, for knowledge, for our careers? I'm going to start by sharing a couple of stories from my career. The first one I wanted to share is actually a really long time ago, like, 20 years ago. I learned from this project, not because it was a good one; I learned what not to do. I was working at a company that acquired a credit card processing gateway. For those of you who aren't familiar credit card processing, you don't work generally directly with the networks. You go through an intermediate service that does the work of taking the credit card information and storing and talking to the credit card networks, and interacting with the bank, and putting the money into the bank. Then they call that a gateway. It does the work of interfacing with the credit card networks and the bank to connect the two together. They call it, it's like I say, a credit card processing gateway. I've worked on a couple of those over the years, but we acquired one at this company I was working for. They had quite a few clients. They worked mostly with small businesses. They had a partnership with a company that worked a lot with small businesses, so they had a lot of business. But they were having some financial troubles. We took them over with the thought that we would help them grow. Well, this service was written in VBScript. [laughs] It was a scripting language based on Visual Basic. It was used a long time ago. It was a predecessor to Microsoft's .NET that they have now, which is kind of a more solid platform. This old way of doing things was similar to some of the other scripting languages at the time where they just...they gave you a scripting language, and that's about it. So there weren't libraries for interacting, for doing clean interactions with the database. You kind of built everything yourself. And the people who had implemented this had written a query where they didn't sanitize their inputs. They just took input straight from what people had submitted to the application and sent it directly to the database. For anybody who's not familiar with that, that's considered the number one security no-no, [chuckles] that it allows a malicious user to send in a little snippet of text that will allow them to interact with the database. And that's exactly what happened. Shortly after we took it over, and perhaps even before we took it over, somebody had started exploiting this hole and ended up stealing, I think, over a million dollars from users of this gateway, which was terrible. And I had to go through and try to figure out what was going on in the code because we were told that there was a problem, like, there's something that seems funny. And so, I had to start going and looking through the code and trying to find where something, who knows what might be funny. I found this SQL injection vulnerability, like, oh no, and fixed it. So, I learned dramatically when you choose to build everything yourself rather than using a library, you put yourself in a lot of risk. There's relationships poisoned between businesses with this experience, and it really kind of sent the company I was working at on a different trajectory that wasn't as good. It was a really, really bad thing because people had not taken the time to have a library that did things right. So, I learned from that experience, and it sticks with me today. In fact, when I interview people for a job, I often ask them [laughs], still, what sort of security vulnerabilities they've found because it was such a poignant experience that it let me know how important it is to do things right when it comes to security. Another story I wanted to share, I also worked at another company that was doing a content management system, mostly for publications like newspapers. We were doing decent business. But then we primarily focused on classified ads, built the content management system, and started bringing on newspapers, and we grew so fast. We grew...if I remember correctly, we had 10000% growth in a year in traffic. If you're growing 100 times bigger in a year, that kind of growth is very difficult to sustain because about every two weeks, something new would break. [laughs] If you're doubling in traffic every couple of weeks, you quickly find things that were working and no longer are. In that kind of environment, I had to learn an awful lot about monitoring performance, addressing performance concerns, about tooling, about how to quickly address problems that arise. It was really invaluable the kinds of debugging skills I got and the kind of situational awareness of knowing what was happening and looking out for the kinds of things that might be going wrong next. We've got Kyle with us here who [inaudible 05:11] the DevOps team. So he's probably got some interesting insight on that. Those are the two stories I kind of wanted to share to lead off our conversation. First, where I learned what not to do and one where I was really kind of thrown into the fire [laughs] and had to figure out what to do for an extended period of time, both of those were times when I learned an awful lot in a short amount of time. What stories do you all have or experiences you all have with projects that really pushed your career forward? MATT: I have a couple as well, very similar to your stories. The first one would be I was a little bit earlier in my career working for a startup. And this startup, just for context, was the deal engine. They discount deals for various companies. And we started out a local deal engine here in Salt Lake City and ended up landing a national deal with one of the big movie theaters. And we were used to hosting probably 3,000 max concurrent users at a time. And our services were hosted in a data center single server. There was no virtualization, anything like that. And it just so happens that they talked about us on Good Morning America. Almost immediately after, we got over a million concurrent users, and it just brought everything to its knees. And we had to act very, very fast to figure out some sort of a solution that wasn't going to put us out of business because, you know, servers crashed, and we couldn't have any site visitors. So, what we ended up doing was just throwing up an email form of, hey, we'll get back to you as soon as we can get it back up, and then ended up switching to VMware. And long story short, I learned a lesson in scalability and how not to scale. We were nowhere close to being able to support that kind of traffic. And, you know, while that kind of traffic is great for a startup, it brought us to our knees. You know, eventually, the company, not a long time after that, went out of business, and I think it's because of some of those problems. So lesson is, don't scale too fast if you can't support it. And I have one other story that's on the opposite end and more of a doing things the right way type of story, and that is a company I worked for in healthcare. Starting out, we had a system that was kind of similar to an ERP system. But it was custom-built in PHP. And we were doing a full system rebuild from the ground up and switching it to Ruby. And this is the beginning of my Ruby career. And it was a really great experience for me and kind of pushed me to the next level because I learned a lot about gathering requirements, how having a really good product and project management team works, and how important it is to break tickets down into small incremental stories so they're workable and releases aren't going to cause a ton of bugs and testing. I had never worked in a test-driven development shop before, either. And just that experience it was incredible and kind of made me what I am today. MIKE: [inaudible 08:54] I ask a couple of questions. That first place that went out of business, if your infrastructure had been built on a more solid foundation, and, you know, hindsight makes things easier. [laughs] You know, if you've been in an environment where everything was containerized, virtualized somehow, and was in the cloud, what difference would it have made to the company? MATT: I think it probably would have saved them. They would have that national exposure, and it wouldn't have left a bad taste in customers' mouths. And, you know, I'm betting 90% of these customers that tried to visit and saw that everything had crashed didn't try and come back. And had we been able to support that, we probably would have got some return traffic and been much more successful. And, to be fair, I was the IT director at the time for this company, and I probably shouldn't have been. I was still pretty early in my career and kind of fell into the position, and I didn't have the knowledge that I needed to be able to support the team as I should have. So I will take some responsibility because I shouldn't have been in the position I was in. And, you know, I took it because I thought, oh, wow, I get to be a director for this company. And I really shouldn't have been there. We should have hired someone with some more experience that was better suited for the role. MIKE: We're talking about lessons, not about pointing fingers. You know -- MATT: Well, like, but it was a lesson to me that, hey, don't accept something you're not prepared for and you're not qualified for. MIKE: So, it sounds like the other company they already had some people who were following best practices. It sounds like you were able to learn from people who had set up a culture and an environment of those best practices. Am I hearing that right? MATT: Yeah, absolutely. And I wouldn't generally share names, but there's a company called Pivotal Labs, and some of you are probably familiar with them. EMC owns them, so now Dell. But they were one of the biggest contracting agencies in the world at the time. And they were very good in helping us learn and ensure those best practices. They came in, taught us test-driven development, taught us requirements gathering, and it was a great experience for me. TAD: I'm curious, what separates the projects that will help a developer really level up and push their skill set versus a project that will crush somebody, and they'll be sad about it later on in their life? MIKE: There's a Russian education theorist that came up with the idea of the Zone of Proximal Development that I actually love. Let me explain the idea. You draw a circle, and then you draw a bigger circle around that circle, and that's it. So, you got two concentric circles, a smaller circle and a bigger circle around it. Well, the smaller circle is what you can do alone. And the circle around it, the bigger circle, represents a larger area, and it's what you can do with help. And the area between what you can do and what you can do with help is kind of ring-shaped. Picture these two circles, you know, a smaller circle inside the larger circle so that donut [laughs], that donut shape. That sweet goodness is the area between what you can do alone and what you can do with help. And that area is where you're stretched beyond your own skills, right? You're stretched beyond what you would be able to do normally, but with somebody who can guide you and help you accomplish things in that area. And that area is, I think, where we tend to learn the most. If you're inside, you know, if you're in the what you can do alone, you can learn, but it tends to be kind of slow. And if you're outside of that outer circle, you're beyond what you can do with help. Well, then, you're just in an area where you just can't do it. And then you tend to fall flat on your face, and it's awful. The sweet spot, you know, you don't want to be in the hole of the donut. You don't want to be outside the donut. You want to be inside the donut. That ring where it's harder than what you can do alone but something that you can do with help. In that area, you're really stretching. That's when you're going to make most use of the mentorship and training opportunities that you have. That's when...as Matt was talking about where he learned from others, he was learning new things that he wouldn't have learned necessarily alone. There's more than one way to learn. You can learn from the internet, but a good mentor is invaluable. They really put you into that donut space. So, if I were to give an answer, I'd say that zone of proximal development, that sweet spot between what you can do alone and what you can't do at all, is, I think, where we do the most growth. MATT: What a great analogy. I've never heard the donut reference, but that's perfectly stated. And it's true. If you sit in an area and aren't willing to take on things that you don't know yet and you may not be able to handle yourself, you kind of get stuck. And you get black-holed, and you don't really grow. But that was perfectly stated. I think fear is one of those things that holds us back as well. We're scared because we think, what if we fail? And, you know, you have to be willing to fail and willing to accept help to grow. TAD: Does that mean you're willing to push code even if that means bugs in production? That's the scary thing, right? It's what happens if I fail and the company loses a bunch of money or I lose data. Or, I mean, there's a lot of big things that can happen in our field due to mistakes or due to not having enough information or enough knowledge to handle something. That was one of your examples, right, Matt? MATT: Right. TAD: You're, like, we needed to scale, and we didn't know how, and we got crushed. MATT: Yeah, absolutely. I think that's both sides of the coin. I think overconfidence can also have you push those bugs into production because you're so confident in yourself that you think everything's just going to work. That's why we write tests, right? MIKE: Well, that's why we write tests, and you hit on some key things. There are things we can do to mitigate our humanity, right? [laughs] Our fallibility. We can automate. Like, with tests, we can automate the verification of what we're doing. Further, we can collaborate with other developers. If you have two people look at it, you are less likely to have problems than if one does. Like, your risk goes significantly down. You never completely eliminate the risk. But you can, again, back in that sweet spot [laughs] between the center and the outside when you have somebody who can verify, who can give that second pair of eyes. It really helps to address some of those weaknesses we have when we're doing things alone, I think. TAD: Interesting. Yeah, I think it's Etsy. Everyone has to push to production on their first day. And I think I read that they set it up so that anything that gets pushed can be easily rolled back. And it doesn't matter what you do. They have a mechanism to make it almost push-button rollback. So, the risk is very low. And they just want people to come in and just get their hands dirty, get their feet wet, whatever you want to say, where it's like, yeah, look, you could just push to production, and you're done. That includes people that aren't necessarily even devs, right? It's, like, QA guys or whatever. If I remember correctly, they also come in and do something...it sounds like the idea is find that project, kick them out of the nest, but make sure there's a safety net so that it's not so bad and so scary. MIKE: That infrastructure idea. Like you said, they make it safe to deploy. If you have a sophisticated deployment kind of pipeline, you can push out to, say, 1% or 5% of your users. And you kind of do the canary test there, you know, say, hey, is this going to work? Is there something wrong? [chuckles] And only expose a small percentage of the users to the risky new code because anything new is risky, as well as the testing and the peer review. And there's conversations about the code, you know, all the many things that we do to try to mitigate that risk, you know, add up to an immensely helpful system. And I think that process of putting those things in place to make the deployment safer really changes our ability to experiment because if you can't experiment, you're not going to get very much done. And giving yourself that ability to bias toward action enables a lot of progress. So, a really good DevOps team can make all the difference. MATT: Yeah, you have stated that very well. And as we're talking, I'm thinking, you know, these things we're talking about are the things that push us to the next level. And had we not gotten there and probably learned some of these hard lessons, we wouldn't know this. You know, small incremental changes. Make your PRs as small as possible. And you do create that safety net. And back in that first story I was talking about, I didn't know these things. And, as we grow, we learn these lessons, and they just make us better. TAD: It's interesting because this is reminding me of a project that really helped me grow was I had an internship with Compaq Computers back when Compaq Computers existed. And my manager's manager came in to all the interns the first day, and he said, "Forget everything you learned in school." Not quite, but he said, "In school, you learn to do your own work, do things on your own, don't ask for help, figure it out, that kind of thing." He says, "That's garbage. Forget all that. If you get stuck in the slightest, I want you to be talking to your fellow interns. I want you to be talking to the other engineers here on this floor because we have tons of expertise. And you're going to move much faster if you talk to somebody than trying to figure it out on your own. Because, yo, I know you're all interns, and you don't have a lot of expertise and stuff." And it was kind of understood. But all of us were on the same floor in this building. And the hallway was actually kind of like a big circle. So whenever you got stumped or stuck, you would just kind of turn to your office buddy, who was another intern, and be like, "I don't know how to do this." And he'd be like, "Yeah, I don't know how to do this either." It's like, all right, time to walk the hall. And you would just kind of think as you walked around the circle and did a few laps. And the other engineers, when they were free, would leave their doors open. And they'd see these interns, like, walking the hall, and they'd be like, "Hey, what's going on? [laughs] Like, why are you walking the hall?" You're like, "Ah, I got this thing." And I remember I was trying to do something. I was trying to measure something and really calibrate something, but I couldn't get it working. And this guy is like, "Hey, what are you doing?" Then I'd tell him. "Oh yeah, the best thing to do is read this register in the processor, right? It says how many cycles have happened since the very first time it booted up. And that's going to be the most accurate way for you to calibrate what you're trying to do." I'm like, "Okay." [vocalization] He's like, "Oh yeah, well, you have to use Assembly, right?" And it's "Oh yeah, I'll just email you the code I wrote." [laughs] So I was just like, "Oh, awesome. Like, thanks. I've been trying to figure out how to find enough calibration for the last three days, and you happen to have a snippet of code that does it for me, and you solved the problem." But that was something where I had no idea. Every intern was given a project, and none of us knew anything about anything. And they gave us a whole summer, and I just [vocalization] [laughs]. But we went into the donut away from the hole, I guess, and learned a ton. MIKE: That's great. Kyle, from the DevOps perspective, it's come up repeatedly how much difference good infrastructure can make that enables us to experiment more safely. I'm curious both what experiences you've had but also your thoughts about that importance of having good infrastructure to enable us to experiment with less risk. KYLE: Yeah, I was sitting here thinking about those as we're talking about a few of these things. I would almost share...I'll start out by saying I'll share that there's probably been four things that I can think of that have really I feel like propelled me, I would say, and that's I got onto a QA monitoring team. And one of my first projects that I had to take up was a dialer bot. And what this dialer bot did was it basically constantly called our beta environment and would make sure that the phone system was up. Anybody that's worked with phone systems, those are very particular. The average person, I would assume, gets frustrated when they try and make calls. Sometimes they just don't go through, and that was kind of the case that we would deal with. And so, I had to design a bot that, you know, was resilient enough to determine, okay, well, this is just the phone system, or this is actually our code. This is something that we broke when we deployed. And that was interesting because I had to deep dive into Python. It was my first time really writing anything in Python of substance and getting that going. So that kind of got me into the world of monitoring. And that forced me into the world of, at the time, it was the TICK Stack, which is more so Influx, and its Telegraf to send metrics to a time series database so that you could visualize what was being monitored. But the big one for me was the transition to Prometheus and how that ecosystem has grown. And I'll pause on the Prometheus side for now because...but it kind of goes back into the question that you asked. The one thing that really was a deep dive for me was orchestration tooling. My first exposure was Rancher, which was a great stepping stone, I'll say. It was early days for the Rancher guys and orchestration, and we definitely went through the growing pains with them. We had, I don't know, we were probably up for two days one time when our Rancher orchestration went down at my previous company. But tell you what? When you're working on something with a group of guys for 48 hours, you tend to learn a lot about a system. And then the next one, you know, is Kubernetes orchestration system, which has been amazing just to be able to see how that scales, taking systems like we had here where we were running directly on [inaudible 23:59] hosts and running services per host and being able to schedule six, seven services on a host. And then being able to manage that it's cut costs, and it's given us resiliency. And that's where I'd go back to Prometheus. Prometheus gives us some of that time series database where we can have this monitoring and store all this information. So with utilizing a tool like Prometheus and then, like, Grafana to visualize and get alerts, we're able to determine quite quickly how fast our services are either down or there might be issues. But on top of that, you have these orchestration tools that have some type of a self-healing aspect to them. And I won't throw any services under the bus, but there might be a service or two that they tip over every once in a while because, well, they've got some type of a memory leak. While on the Kubernetes environment, what happens there is it tips over. It gets restarted. You know, the service automatically gets restarted. Previously, you had to manage that yourself. You had to have something monitoring that that would see it. And either somebody would have to have a manual intervention or, you know, there would be something to say, "Oh no, restart this service," you know, kind of like Kubernetes does it. And, on the other hand, too, Kubernetes has safeguards in there as well where, you know, if it starts using too much memory, it will get restarted. You know, it's a bandaid on the memory leak. The memory leak could be fixed, but it's a bandaid on it. That service continues to run, and it continues to operate. And it doesn't, you know, impact us or our customers. There's just new techs in the infrastructure that have given us these bandaids or given us these luxuries that has allowed us to move faster. And I think, for this company specifically, it has allowed us to move faster in a way that we've been able to write a lot more services. It's been exponential the services that we've started with since I got here to where we are now and even the variety of services that we're able to deploy. We're not just a Ruby shop. We're a Ruby shop, a Kotlin shop, a Haskell shop, you know, it's something where good infrastructure, good orchestration allows you to be quite diverse in your ecosystem. Did that kind of hit on what you're asking? [laughs] MIKE: I think so. I think of this idea you keep on talking about, having the good orchestration, having the infrastructure that enables things. I'm thinking about elementary schools that will set up a, you know, a playground [laughs] for the kids to go and play in that lets kids do things that are a little bit dangerous, right? Like, kids fall off the swings, kids fall off the bars, probably break bones sometimes. My son lost a tooth once [laughs] or lost half his tooth. He broke a tooth in half by running into a bar. But they're safer than things that they might encounter as adults. You don't send them out onto a construction site, for example. As educators, as a society, we build these environments to allow the children to experiment safely in a way that there is some risk, but it's managed. And then they get out of elementary school. They get into later on in school. They provide sports, right? Where you get to go and push the boundaries of your physical abilities in a not exactly a sandbox but a constrained space where the parameters are somewhat controlled to reduce risk. You know, the kids who play football they wear protective equipment or, you know, some protective equipment in other sports as well. This idea of providing an environment that allows experimentation seems to be a big part of what allows us to take those risks and learn some things. Also, a recurring theme I keep hearing is that scale is going to happen, [laughs] that we're going to have to deal with that. And they can make you or break you. And you can learn a lot from it, but only if you've set up the infrastructure that you need to grow. And building a system that allows you to quickly scale up seems to be kind of vital. Interesting these recurring themes that we're hearing. You know, we are talking about growth. But in order to have that growth, you need to have an environment in which you are allowed to grow without breaking too many things but also are forced to be in that donut, right? To be beyond where you would go if you're just left to your own devices. TAD: As I was thinking back, this is maybe a bit of a random project. But something that kind of changed my trajectory was, back in high school, I was just kind of the goofy kid that kind of joined the computer science club to do games because that was the place where all the computers were networked together, and you could play games together and stuff like that. And I had a teacher who took me aside, and she's like, "I think there's this thing that's really cool, and I want you to do, like, a research project on it and get back to me." And I'm like, "Yeah, okay, sure." And she had me learn about this new technology called Gopher, and nobody has heard of Gopher now. But it came on the scene about the same time as the World Wide Web. And she kind of challenged this other guy in the club to also do this thing. And we were kind of against each other a little bit, right? Because he was like, oh yeah, this World Wide Web thing is really cool, and I think it's going to take off. And I'm like, [vocalization], whatever. This Gopher thing is really cool, and it's going to take off. And The World Wide Web won out there. But she'd feed us these kinds of projects to get us interested in things and learning about new stuff. And I'm a web developer today partly because my teacher back in high school kind of directed my interest into something. MIKE: That's interesting. [laughs] On your own, you just played games. [laughs] TAD: Yeah, right? There was a really fun Mac game called Bolo where there's this little tank running around, and you form teams. And that was most of the time in our computer science club. And she, honestly, I think she used the games as a hook to get people in, and then she'd redirect that into other stuff. She was very clever. MIKE: I can say that when I've had good mentors, it's made such a difference. In my first year of full-time development, I'll say he's my boss; he was my manager, but he was my peer as well. We had gone to school together, and we were friends, remain friends to this day, stay in touch sometimes. But he was an excellent mentor. We actually had some high school students working with us, writing some of our code. They had their own online game that they ran. I think it was written in PHP, and they had a decent community [laughs] out there playing their game. But then they also professionally, in their time when they weren't at school, were writing some code for us. [laughs] And working with that environment where you had some very junior, very junior developers, and I didn't really have any professional experience at the time. I had a patient, and thoughtful, and knowledgeable mentor that was always sharing. And he spent a lot of time educating himself and was sharing those things. I think the expertise that he shared with me and his mentoring made a tremendous difference my first couple of years in my career and really kind of set the trajectory. He was really interested in databases. He loved data. He loved interacting with databases and really focused on that. And to this day, it's something that I still love and identify with. I think partially because of that mentor that set me on that right direction, kind of like your high school teacher, Tad. Or, you know, Matt, you talked about the people who set you up with testing and other best practices. Having that kind of mentor who sets the stage can make it...well, it puts you in the donut, right? MATT: Yeah, absolutely. That's one of the things I love about Acima is we really have a strong focus on mentorship. And it's extremely fulfilling to be able to help others level up as well. So I'm very thankful for that. And, Mike, you should get a lot of credit because you help push that, ensure it happens. MIKE: Well, thank you. It's something I care about. I think it matters. Having that culture of mentorship and help is a key differentiator, not just to make your company successful, which I think it is central to. I think we've talked about it before on the podcast, but there's the research that Google did that found that psychological safety is the most important aspect on a team for success. And that comes down to what? Well, providing that mentorship and providing that kind of safe ground for people to experiment. So I think it's vital for a company. But also, it's the kind of environment I'd want to work in. I want to work with people who help each other out and who care. [laughs] I want to be with a group of people who cares about each other. And you have to create that. KYLE: I would point out too that—we're hitting on it—but just the ecosystem that you're working in that's a way of just leveling up alone. And I'll kind of second what Matt said about the culture here at Acima. I've worked at a few places where it is very much the QA department, very much the dev or the engineering department, very much the DevOps department. There's not much intermingling, and I would say here those walls have been...they're really low. It's not like me and DevOps. It's not like I have an issue going and talking to any of the engineers. They're part of my team, you know, not direct team, but they're part of my team and very open to talk to, and that's not necessarily the culture at other companies. Even QA I've seen hasn't gotten the respect that we do give them here at this company, you know, that they are part of engineering. They are very integral. We treat them the same as any of the other engineers. And with these mentorship programs, you know, it's kind of on you. We have these opportunities to go and learn. There's book clubs. There's the podcast. There's paired coding and stuff I know going on everywhere. I'm sure I'm not aware of everything that's happening but just the culture. You know, we talk about orchestration and how that might, you know, elevate the company and help keep you rapidly progressing. I think a culture like one that Acima has, you know, and I'm sure other companies do as well, where that communication, the barriers are taken down, and communication is encouraged, you know, relationship building is encouraged. That's something that is going to elevate your career faster than sitting in a silo, you know, be it your own single silo or your team silo, right? MIKE: Well put. And to kind of build on that and kind of connect that with what I was saying, you may find yourself in a company that's mediocre, maybe even not very good at having a good culture. You know, maybe there isn't an emphasis on testing or best practices, or, more importantly, on mentorship, on psychological safety, you know, on inclusion, and mentorship, and support. There's a couple of ways you can deal with that. You know, if you're in a truly toxic environment, then maybe the best answer is to get out of it. [laughs] In a lot of cases, it's somewhere more in the middle where it's just sort of fallen into a slump. And being proactive, taking the initiative, and being the person to make a difference is what will push things forward. To give an example, I was at a place a number of years back where they said, "Why don't we take some of our lunchtime," sometimes, we were already doing it, "and help out some people who are also at the company who want to grow their development skills?" And we started doing that. And there's one person in particular, a woman who was working at the front desk, you know, had a lot of ability. She had a lot of technical ability that was kind of being underused. And she started meeting with us at lunchtime and pairing on tickets together, working on code. And we'd just take those lunch hours and help her. And there was somebody else, and I think sometimes two or three who were working with us to grow their skills. And that changed the culture of the company, right? Because now the developers were really interested in working with these people and invested in their success. And people who were doing that investment have gone on to lead teams. And that woman who was working at the front desk is at another company leading an engineering department now [laughs] after having a successful development career, as part of her successful development career. It started small, but that seed grew into something phenomenal. And it just starts, I think, with taking that initiative. If you haven't experienced that, and this is to the people listening, you know, if you find yourself in that position, step up and do something. You will make a difference. Go out and mentor somebody or start a book club. Do something to encourage that atmosphere of growth. You know, Tad talked about walking around as interns and finding the people with the doors open. Find that environment where the doors are open and build on it. Open your door [chuckles], and let the interns in. Those things may seem small in the moment, but, in aggregate, they make a tremendous difference, not just to the individuals that you're helping, but to the overall culture and to the success of the company at a whole, and also to the health of even the industry. I feel very strongly about this point. [laughs] I've seen it work, and I know it can make a real difference. Let's all try to help people get into that donut and have that sweet goodness of the zone of proximal development. MATT: We can all play our part, right? We just need to take it upon ourselves to empower others and to empower ourselves. We can all make a big difference. MIKE: Great. Thank you. Another great discussion. I look forward to talking with you all next time.
On today's episode, we discuss the progress that JavaScript has made and how Rails hasn't really moved along with that movement. We're not in the business of starting flame wars here but rather talking about the potential advantages and disadvantages of different approaches to technology. Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. Today we've got a few people here. We have Matt, Nathan, Ramses, and Bart. And we're here to talk about JavaScript a bit. To give a little context, I've been doing web development for a while. I first started tinkering around with it back in the '90s. Back at that time, things were a little bit different. There was no such thing as front end, much of anything. The web was designed as kind of static documents that you would navigate between. So, in the early days, what you even think about as a web application, you had a website, and maybe you'd add a little bit of interactivity to your site. So you could do some things dynamically. But that was kind of a novel idea at the time. So you'd go to a page, you'd request the page, and everything on the page would be built on the server, and they would send it from the server out to the browser. The browser would render it. And that was the paradigm. That was the paradigm for a long time. That's how it started. 1993, I believe, was the first web browser, although very few people were using it at the time. And over the next, certainly the next 15 years after that, it was primarily done in kind of the same way. You'd make a request to a server. It would render that document. The document would be sent over the wire over to your browser. Your browser would then show it. They came up with this language, JavaScript, that could run inside the browser, a little language. And at first, it was used for just doing tricky, little things like showing little decorations dancing around your mouse. [laughs] I remember that one back in the early days. And they mostly got rid of those because they were more of a distraction than actually helpful. People were just having fun. But over time, people started to realize, well, maybe we could actually do some useful things with this language that gives us interactivity in the browser. And so they started doing things like allowing you to drag and drop, which was really useful compared to what happened before. And, you know, other sorts of interactivity where you get a little bit of animations, or maybe you click something, and you see something highlighted somewhere. And that interactivity made the browser feel a little bit more like a desktop application. Well, over the last decade, that has really expanded. And we now have not just interactivity on websites but the whole idea of rendering has often been taken entirely away from the servers. The server is just a source of data, and the front end does all of the rendering. And that is a radical shift from the early days. And it was kind of hard-won because, you know, a lot of people would resist that because it breaks the paradigm. There are some changes there. And Rails, the framework that I've done a lot of my career in, hasn't really moved along with that movement. They've kind of stayed; let's keep rendering on the server side. And they've come up with a whole kind of independent system for doing that, for sending real-time updates out to the client that are rendered on the server side so that the JavaScript can be kept minimal. It's kind of an opinion that they've expressed that is not shared by most of the web development community. We're not in a goal here...[chuckles] not in the business of starting flame wars but rather talking about potential advantages and disadvantages of different approaches to technology. I have with us here Nathan Pearson, who's spent a lot of his time working on the JavaScript front end, and he's doing so here at Acima. And so he's here to talk about the React way of doing things, you know, the JavaScript way of doing things and how that compares with kind of the traditional or the Rails way of doing things. So we can compare and contrast and kind of see the value that you might get from these approaches. And that's kind of where I've started. I've started with my I've been doing this for a while talk [laughs] and shared a little history because it matters. And it kind of informs some of the debates people have because they have their history. So, Nathan, where would you kind of like to start with this? NATHAN: Well, hey, thanks for having me, first of all. I guess maybe a good way to do this would be to describe if we're going to talk about a little bit of, like, compare and contrast with what Rails is doing versus what we see with other frameworks. Maybe we should talk about how Rails does it. And then I can get into a little bit more on the other side of things. But if you like, I can try to describe Hotwire to the best of my abilities. Although I'll admit, I'm not an expert in it, unless you'd like to do it if you've done a little bit of research on that or if you have some experience with it. MIKE: I haven't used a lot of it but a little bit. And I think you kind of captured, like, even the name captures most of it. Hotwire is an acronym for HTML Over the Wire. So it's a framework that's designed to send markup, fully-built markup, like, fragments of the page over the wire out to the front end using WebSockets. So it's fast. So there's some real-time communication with the rendering still happening on the server side so rather than the client side maintaining a full sense of the state of the document. That's really not handled on the client side. Rather, the server-side renders it, and the client side just kind of sticks the content where it goes, and that has its merit. You don't have to know JavaScript very much [laughs] if JavaScript is not a familiar language to you. In a world where most people know JavaScript, maybe the advantage has diminished some. It keeps the paradigm that we've had for decades and doesn't force us to go into a JavaScript world. There are some advantages to that as well, including for accessibility. JavaScript sometimes isn't very good for accessibility. NATHAN: Yeah, or for SEO, right? I mean, things rendered on the client. Yeah, I guess if I could, I'd maybe just add that...so as I understand Hotwire, you have kind of, like, the two...is there are two parts to it. They call it Turbo, which is kind of a mini framework that handles really a lot of sort of the unseen interactions on the Rail's side. And then you have the Stimulus, which allows you to kind of pepper in some JavaScript. And I guess the big thing with Turbo is it's mostly built around Ajax, right? So it gives you this...I guess they call it unobtrusive interaction with JavaScript where you can sort of write most of your code still within Rails, kind of like as Ruby, using Ruby templates. And then you use certain directives to indicate that this is going to be an Ajax request, and really kind of just Rails handles it from there. You don't have to worry about how do you replace different components on the screen? That just kind of happens dynamically for you behind the scenes. So I think that's one of the major advantages of it is that it sort of gets out of your way and lets you get your job done, like what you said, which is it gives you that more traditional way of thinking about working with the web as a document, instead of a dynamic application with a lot of moving parts. So it sort of simplifies that for you. But it gives you the benefit of being able to add dynamic sort of changes to your application without a page refresh. Would you agree? Is that a fair way of describing it? MIKE: Yeah, I think it is. And, you know, for anybody who's not used Ajax, it's an old acronym for Asynchronous JavaScript...AJA...what is the name of the second A? It's [inaudible 07:07] for the JavaScript [inaudible 07:09] XMLHttpRequest. You can see why they...to shorten that XMLHttpRequest. [chuckles] I was around when they first started using that technique. And Microsoft introduced this component in Internet Explorer back a couple of decades ago that allowed you to send XML, at the time, over the wire, and other browsers kind of cloned it. And it became the de facto way to send information between the browser and the server without having to do a full-page refresh. And it's only relatively recently that JavaScript has really kind of natively got that ability with the Fetch API. MATT: Just those old days of building your own libraries for Ajax requests. It's sure come a long way since then. MIKE: Yeah, it has. NATHAN: Yeah. So I guess coming back to that just as far as laying the foundation for this talk, so, if we're looking at Hotwire, I would say that there's probably this scale, I guess, in my mind of on the one hand, you have more of, like, this classic way of working with web applications where you have a server-side rendered page that gets pushed out to a browser. And then, in the browser, you get JavaScript that gets sent as well. And then that then, you know, applies some interactivity on the page, so it's a little bit more dynamic. On the other extreme of that, you have pure just JavaScript. So that page is rendered using JavaScript, whether it's in the client. It could, I guess, also be rendered server-side with JavaScript using Node. But JavaScript is really in the driver's seat of doing all of that. And then I think from what I understand of Hotwire, you know, I haven't really worked with it, but it sort of falls in between those two. So it gives you some of the dynamic nature of JavaScript. But because it's still kind of wrapped within Rails as a full-stack application really focused on Ruby, it gives you the ability to sort of work with that and deliver a lot of that interactivity in kind of a classic way but with a lot of, you know, the modern features as well of making it really rich. So it is an interesting proposition, but I'd say that's probably where it would fall in my mind is it's sort of in between these two extremes of how you may want to think about, you know, how web pages are delivered to a browser and where JavaScript kind of enters the scene. MATT: Yeah, it may be worth noting as well that Turbo uses WebSockets, so event-driven. NATHAN: Now, does Turbo always use WebSockets, or is that just the Turbo Streams part of it? Because as I understand it, Turbo is made up of three different pieces, you know, Turbolinks still plays a role, and it's just basic Ajax requests. But I'm not sure whether or not, I guess, I wasn't sure whether or not WebSockets are used universally with Turbo. MIKE: I think it depends on kind of your usage. It's been evolving to this point. And I think you can rely primarily on WebSockets now. But you could still use kind of the classic Ajax-type techniques. MATT: Yeah, you can go 100% the WebSocket route, but it is not required with Turbo. NATHAN: Yeah, it's interesting. So, I'd say, coming back to this kind of other end of that extreme on the fully JavaScript side, I'd say probably React encapsulates that even more than any other purely JavaScript framework like Vue or Angular in that view. They kind of have their own built-in templating idea. They have what are called directives. So you will create some kind of HTML representation of what you, you know, eventually want to present out to the client. And then you can add what they call directives on elements that are kind of baked in, or you can create custom directives that let you have certain interactions with those elements, whether it's managing their state, or replicating them, or looking into them in some way that allows JavaScript to control, you know, how those elements are managed on the screen. React even goes further into JavaScript land where they use JSX, which is, like, a JavaScript representation of XML. Basically, it's just JavaScript will create all of your HTML. So it's not just your behavior, but it'll render your markup really similar to, I guess, what you would think of in terms of, like, I guess, ERB sort of does that. It actually does use HTML behind the scenes, but, like, the form builder and things like that that will create different HTML elements for you. React goes whole-hog with that. I mean, just everything is done with JavaScript. So there's some trade-offs there. In terms of preference, I think I'd say some folks prefer having something like a Vue or an Angular, where you have these directives, this special kind of key attributes that are on these HTML elements. Some like the JSX approach. I do prefer personally the JSX approach just because it just feels like you have even more control. It's all JavaScript. And you can even do debugging statements directly in your markup, which you couldn't do, like, let's say, in Vue. So that's a really interesting sort of feature, and I'd say why I would probably categorize React on the most extreme end of, you know, really having JavaScript run your entire presentation. MATT: Being able to debug in your markup is really powerful. NATHAN: Yeah, it comes in handy when you're looping something. So you may want to check the state of your data as you're going through a loop. And it's a little hard to do that unless you can throw a debugger in there. MIKE: There's also some strength in the idea that you never leave the language. You don't have two things [chuckles] where you have your language, and then you have your templating language. You just have your language. I think that is a real strength. You don't have the cognitive challenges of switching contexts. NATHAN: Yeah, absolutely. And I think one of the issues with JavaScript that I struggle with, I mean, to date, is the toolchain. So, like, modern JavaScript doesn't look anything like what you end up delivering to your client, to the browser, when it gets, you know, pushed out into production. You have to transpile it down to sort of an older kind of more, I guess, like, acceptable sort of version where it's not...doesn't have all the modern bells and whistles. The more, like, custom kind of templating, transpiling that you have to do things like with the Vue idea or with Angular where you have these directives and whatnot, there's just an additional layer of, you know, they call it pre-processing, getting it prepared for the web. So you just have to kind of stitch that into your toolchain and make sure that you configure that properly. And it's just another, I guess, small point of failure if you're not, you know if you don't do that correctly. I mean, it's not a big deal. But it's just something to be aware of where everything is purely JavaScript. It just eliminates at least just that additional factor of having to juggle yet another plugin or a pre-processing library that you'd need to handle that stuff with. MIKE: To take that a step further, most people don't write JavaScript anymore, right? They write TypeScript. NATHAN: Yes, that's right. There's a new survey that came out for this year. Their claim is that in 2022, front-end developers, JavaScript developers, by and large, spent more time with TypeScript than they did with regular JavaScript, which is pretty impressive and understandable. I mean, if you've used TypeScript, you really can, you know, appreciate what type safety and, you know, the autocomplete sort of IntelliSense that you have while you're developing what that brings to the table. To be honest, after using it, it's kind of hard to go back to a language that doesn't have those features. MATT: And it really helps you DRY up your code. And I was also just going to say something maybe to note is the configuration of these modern JavaScript libraries. You know, in the past, there wasn't really any configuration you had to do on your front end. But now you need to be aware of the configuration side of things as well. NATHAN: Yeah, that ends up being kind of a big deal. And there are a lot of tools around that. The big one today is...they call it Vite, so it's spelled V-I-T-E. With React, at least, it used to be this tool called Create React App, which was built and maintained, and it's still out there. It just doesn't have that much usage anymore. But it was provided by Facebook, the same team that builds React. And it was just kind of like a one-button click starter pack for getting your React app up and running without having to worry about configuring tools like Webpack. Vite sort of has the same thing. It's a little bit more flexible. It allows you to do this with Vue, or Angular, or React, or whatever framework you really want. It's not, you know, married to a specific framework like Create React App was. And it also allows you to modify your build process, this sort of pre-processing of JavaScript that you'd need, which is something you couldn't do with Create React App. That was always, like, a major complaint. So, if you wanted multiple entry points, which, for example, if you're building a browser extension, you have multiple types of pages, you have a pop-up page. You have a background JavaScript page. You have what they call a content script. You'd need different entry points for those. And you couldn't really do that with Create React App. It just kind of assumed you just want a basic, you know, web page with React. So that was always, like, a big complaint, and Vite solves that. They allow you to be able to really kind of configure it the way that you want. It doesn't break any of the default configurations. But you definitely need a tool like that these days if you're writing modern JavaScript, which is kind of a topic in and of itself. It's a radical departure from, let's say, things that I think we kind of grew up with, which is like, you know, the problems with the var keyword [chuckles] and stuff like that, and the various type of scoping problems that you'd see with JavaScript. It's really changed quite a bit. They've introduced a module system, which gives you a proper namespacing system. You don't need to use those Immediately Invoked Function Expressions anymore to kind of contain your scope. So it's really come a long way as far as what, you know, the differences are. MATT: You're actually the one that turned me on to Vite, and I have not looked back since making the change on any of my projects. So thank you for that. And another great thing with some of these modern tools is live updates. That makes such a huge difference when you're making changes on the front end. NATHAN: Oh yeah. It's huge. They call it the Hot Module Replacement where, you know, you make a change while you're developing. And you don't even have to refresh your screen; you just see it immediately. And, well, I'll tell you that that is such a pleasant development experience. It's really hard to appreciate that unless you do it, you know, and you see how elegant that is. It's just a...it's a really nice way to work. MIKE: What I'm struck by as you're describing this, although it's not new, so front-end development is really becoming kind of like back-end development. [chuckles] NATHAN: [laughs] MIKE: There's this compilation process, right? You build a build, and you push it out. We started with front-end development being just little toys. And now it's really kind of the same deal as the back end was. And I think there are still a few folks out there who see front end as secondary, but it's kind of coming to its own, where it's the same basic processes we're doing for the backend. NATHAN: Yeah, I mean, you can even go further with it and talk about Node, which is used for the back end. So there are full-stack frameworks like Next.js. I think there's also one called Remix that's sort of a similar type of deal where they're, I think, trying to creep into the Rails space. I mean, they're offering your full-on back-end layers of your stack, as well as the front end. But you don't ever leave the language. You're all in the same language, whether that's good or bad, I don't know. I think as a developer, you always want to learn at least a few languages so that you can really kind of get a sense of what the differences are and understand kind of, you know, those trade-offs. But it is far more robust, I think than we certainly started with when we were talking about JavaScript. MATT: Yeah, things like Next.js took a lot of cues from the Rails world, just the similarities, the dependency injection, things like that that are really great. And, you know, you said full stack. It makes it much easier to be full stack if you're using the same language across your stack instead of having to separate those language concerns. But full stack has definitely, I think, taken on a new meaning in the last, say, five years or so. MIKE: You know, Rails was revolutionary in 2005, but that was getting to be quite a long time ago. The ideas that it spread out in the community have spread and have taken root elsewhere. So Rails really isn't the unique framework that it once was because just kind of best practices, the convention over configuration, or having a high-quality ORM have kind of spread everywhere. And I don't think that we should think that Rails is, wow, this is the only place you can get this anymore. Those ideas have gone elsewhere, and they've bounced around and sometimes improved. MATT: Yeah, you can find them in almost every language now. NATHAN: Yeah, so I use Node Express a lot of times for, like, a quick, you know, back end, if I have to put something together. It's less opinionated than Rails. I configure it so that it resembles Rails because just all of the patterns, MVC, for example. You know, whether you love it or hate it, there's something very familiar with understanding how to group your code up in the way that Rails does it. And I think it's just a quick way to get started. A lot of the patterns that Rails introduced are so, you know, they're so, like, effective in terms of a mental model of how to work with a back-end system like that or a web system that they just carry over really well. And yeah, indeed, I see them a lot in a lot of different frameworks. I think Rails has been really kind of an inspiration for web development across the board. MATT: I find myself doing the very same thing. MIKE: So we've talked a little bit about...we kind of went on a direction there talking about the toolchain. But we haven't talked deeply about what are the compelling advantages of having, say, React that completely and, you know, and disadvantages. But tell me reasons to...advantages to having React manage everything so that no longer are you really running a browser web page but rather, you're running a web application using JavaScript that's managing everything that you see. NATHAN: Yeah, I think it's a good topic, and it is helpful to juxtapose it with Rails. Not to bash on anything that Rails does, Rails does things in a different way. And it is possibly a matter of preference. But I think juxtaposing it with Rails...or there's Laravel and other frameworks similar to Rails that are still doing it in that way as well. So I think just thinking of whether you want to call that, like, the classic way, or kind of this sort of improved classic way of having a server-side rendered page with some unobtrusive dynamic JavaScript in there versus pure JavaScript. What I would probably argue attracts me, at least for the React side of things, for the pure JavaScript way of doing things is, first, for me, I guess it's a matter of ergonomics, just the preference of working with React, or even if it was just pure Vanilla JavaScript, everything being in that world. So you have however you want to organize your code. You can co-locate it. You can think of it really kind of as its own independent unit. And you don't have to think about, you know, separating out these different parts that need to come together across the stack. You can kind of focus on it. So there are certain ergonomics that comes with that. There's also the data sort of transfer part of it, you know, you're dealing with JSON data instead of HTML fragments. So that, to me, tends to...there's an attraction there. I guess it just tends to simplify it. And it tends to help me think about an application as being, well, I guess, the back end as being separated from the front end in terms of an API. And when you kind of merge the two together into a single framework, that separation becomes pretty murky, and it's hard to sort of separate that out. So, you know, as your architecture grows and you have multiple services, and you may want to reach out across multiple services, you know, in my experience, it's just easier to work with JSON data or some sort of transactional data rather than actual fragments of a markup that you want to present in your code. MATT: Yeah, I think that separation of concerns is huge. You know, it makes rebuilding a front end much simpler than if everything is tied together in a single, like, monolithic application. I am curious to hear maybe some of the guys who haven't been doing it quite as long as us old folks in the room how they feel about the separation of concerns. Has it been harder for you guys to pick up on front-end development? What are your thoughts on that, if you have any? RAMSES: Not any super strong opinions. I think it's just with any new language; you just need exposure to it and practice with it. I don't have a lot of practice with or a lot of experience with different JavaScript frameworks, a little bit with Stimulus and React now, and, I guess, Vite too; that's even less. [laughs] I think there's just so many different tools out there, so which one to go with is hard to say. Just find something that you like and learn it. MATT: Yeah, sometimes picking is the hardest part. MIKE: The specific thing that you were pointing out, I think, Nathan and Matt, you're both pointing out, which is that sending data in a consistent data-centric format between applications is better than sending document fragments that, you know, in a markup language is a better idea, I think that's a pretty compelling argument. One of the reasons that the web was successful was that it separated presentation from the data. So a markup language like HTML...in some of the early days of the web, presentation started getting mixed in. You started getting tags that referred to style. And we had to kind of pull back from that where we don't have the tag anymore, for example, [laughs] if you remember that one. Then we said, well, we're going to send you data. We're going to send you, you know, some markup, which is data that's notated, essentially. There's a description of the data, but it doesn't say how to present it. That's the browser's job. And so you just start with the data and let the browser figure that out. And if you want to determine presentation, well, you have a separate language for that. You have Cascading Style Sheets that describe what it looks like. And then, you have JavaScript that describes what the behavior is. And by separating those concerns, we ended up getting away from the entanglements, and there's a lot better success in being able to conceive the problem. And even better than those document fragments, arguably, the markup still is a description of content. But we could also send that in a different dedicated content language like JSON, where you have something that's more like just strings and integers, or Booleans. And if you're a lower level, then the browser can not only think about that as the document being in one format but maybe reformat that document and completely rethink it. And so it lets you go to a little bit deeper level and separate those concerns even more, which I think is a really great idea. MATT: Yeah, and standardization is huge, right? Remember the days of building, like, SOAP APIs? And I have nightmares just thinking about that. But you can standardize things, and you expect something to come across as a different format. It really isolates it. And I think that is just a huge win. MIKE: You don't write WSDLs for fun? MATT: Yeah [vocalization] MIKE: [laughs] MATT: I [laughs] really do. I have nightmares of having to write SOAP API and WSDLs. NATHAN: Yeah, that is definitely a huge deal. Like, especially when you're talking about your architecture growing and you want to think about, you know, having APIs. It's really difficult; I'd say, to do that. In a way, I'd almost argue that thinking in terms of a, you know, traditional view of what full stack means sort of limits you in terms of understanding how to really think about the API. And, you know, if you really kind of just use the example of just building something like a class or a function even, if you think about that functions API, what kind of data is it going to take? What is its output going to be? At least I find myself when I'm faced with a problem that I need to solve; I think about it in those terms of, okay, I need to write this thing. And this is the way I want it to look. This is the way I want it to be consumed. This is the data that is going to come out of it. And then the internal implementation, I mean, that just comes out as far as that's just the work of getting it to look like that, but the design really comes first. And when I think about, you know, systems and larger architectures, I think the same sort of thought process goes into modeling; what is your API? What data is it going to take? And what's the output going to be? And when you are really working with this full-stack approach, you tend not to find yourself in that mental model. You tend to think in terms of, okay, well, what's my UI going to look like? And, you know, so on and so forth. And I think that that has its place. And, in some sense, this whole topic of data versus these fragments and whatnot they have their place as far as what you're trying to build. If it's an initial app, maybe even beyond a prototype, but you're out in the market, and you're kind of at a certain point in the lifecycle of your application that it makes a lot of sense to do it, you know, quickly, I think Rails serves that need really, really well. But when you go beyond that, and you have multiple services, that model of having a purely full-stack framework that you're working with begins to get challenged a little bit. I'd probably throw that in as, like, one, you know, strong kind of distinction between these two paradigms of having this separation. And I'd say the other part of this that kind of dovetails into it is, really, it's kind of a question of control. So Hotwire, what's really nice about it is that you don't really have to know very much JavaScript to really gain a lot of the advantages that JavaScript offers, modern JavaScript, right? Where you're able to refresh major chunks of the page or even smaller parts of the page dynamically without a page refresh. But the issue that I have...and maybe this is a personal thing because I always tend to worry that, you know, what happens when I need more control? Especially if you're a newer developer and you're just starting out, and you're learning the Rails way of doing things, are you really going to understand how to debug a JavaScript issue that's baked into, you know, that Turbo framework? So that's the thing that I tend to be a little bit concerned about, leaning too much on that. Kind of it's such a nice abstraction, but it removes you so much from the bare metal of JavaScript that I would say you could run into certain issues while you're developing. I'm also not sure whether or not...and I don't know if this is totally related to that point. But there's this concern, I guess, I have of whether or not it can handle all the use cases that I've seen, so like routing, for example, would be a big question for me. Like I said, I haven't used Hotwire, so I don't have the experience with it. But in the current app I'm building, there's, like, a stepper interface where you go through, like, a wizard from one step to another. And those tend to be done...I've seen them done in multiple ways, one where the URL doesn't change. So the browser's history doesn't play a role. There's no routing at all. It's just the UI is purely changing. And then there are other cases where you may want that, whether it's for SEO reasons or whatever, you know, reasons you may want someone to be able to click into a specific, you know, pass a link somewhere and be able to click into a specific step, same thing with, like, an accordion interface. I don't know how well a Hotwire would manage or allow you as a developer to manage, you know, that history and that URL change in between a UI like that. Maybe it would. And when I think about it, it seems like a pretty complicated case. MIKE: I was talking to a friend the other day about another case that I think is also challenging for a framework just trying to avoid JavaScript, which is optimistic writes. That is, suppose you're looking at a list of things, and you...[inaudible 32:10] is looking at a list of things, and they want to delete one of them, say it's a task list. And they click to delete one. If you have full control over the front end, you could delete that element from the page and then run the actual deletion in the background asynchronously. Think about it that way. And I think you could do that in something like Hotwire, but it's going to be challenging. But if you have a model of the document already, it's much easier to think about that kind of situation. And that, you know, you remove it from the page, and then the user gets instant results. And then if something goes wrong, well, then they get a notification, and maybe it comes back. But the idea of being able to think about your document in that way, rather than having to be kind of chained to the back end at every step. That you can think about, you know, what if you want somebody to work offline? Why not just build a whole pool of updates that they will make once they get connected? And that is so far removed from requiring all of the rendering to be done on the server side. You know, I think it becomes utterly impractical. One kind of unstated requirement of having something like Hotwire is that you're always connected because you rely on the server to do everything, which means that you're tightly coupled. And that coupling has some problems associated with it. Now, it may be hard to do things without being online, but I think there are some applications that it makes sense to be able to keep the user largely functioning without having to be always connected. NATHAN: Yeah, absolutely. And that, to me, also dovetails into this whole issue of mobile. I know that Rails team is working on something right now for Hotwire where that will provide an answer to the mobile question, but I haven't seen that yet. In fact, I haven't really seen it with many frameworks. So there really isn't a mobile answer on the Vue side of things or Angular. React, however, does have that. And I'm sure that these other frameworks can follow a similar sort of model for it. And that's one of the things that's also really attractive for me with React is that you may not be able to reuse all of your code, but you can reuse a good chunk of your code if you're building an application that needs to be delivered on different platforms. Mobile isn't the only thing. You can do desktop as well. So, you know, Slack, for example, is a JavaScript app run on Electron. So that can all be done with React. And so you can imagine being able to...if you're a smaller kind of startup and you have a smaller team, you can build a lot of functionality that can be reused, you know, APIs, various services, and whatnot that you need to process data validations, various schemas. A lot of the plumbing that you would need and across all of these different platforms can be reused with some pretty minor changes on the, you know, the UI part of it. So, you know, with mobile, you have a different UI concept. It would still be in React. You would just be using different sort of gesture and animation kind of libraries than you would from, like, a web UI. But even that, if you build your web UI, you can glean kind of how you've separated out your components and organized things and apply the same sort of hierarchy of structure of how state is managed and whatnot in the UI, even though it's using a slightly different framework. So you get a ton of that reuse. I'd love to see how Rails answers that. Like I said, I know that they're working on something. I am curious how they're going to do it. But that is one thing that's currently lacking. And so, in some way, if you're talking about full-stack Rails, you miss a little bit of that control on the JavaScript end, and it really doesn't at least today, it doesn't have, you know, an answer to the mobile question. MIKE: We've talked a lot about the advantages of the JavaScript front end. The other question, when might you want to go with something like Hotwire? I think you've just touched on something important, Nathan. You talked about, you know, you're a startup. You don't want to hire a bunch of people. And so you might want to keep your staff small. And sticking with one framework helps you do that. Does Rails provide that advantage in some circumstances? So, who would you recommend Rails to? NATHAN: Yeah, I mean, absolutely. Like, you know, in our case, at Acima, when we first got started, I think Rails was the perfect fit. It still is in many situations where let's say; the UI doesn't change very frequently. It's pretty stable. And it doesn't have a ton of interactivity or demand from consumers. Maybe LMS would fall into that category. But the idea is, yeah, it can certainly, you know, serve a really meaningful sort of role within that kind of a context. A startup with a small team of people that know the framework really well, who aren't really interested in, you know, some of these broader issues or these tangential issues that come up as you mature. They're just interested in getting the meat and potatoes up and running. And, oftentimes, even can live with those because that's good enough for the application. I think that Rails is probably, and still, I think, the leading framework to be able to do that. MIKE: I think it gets you up and running quickly. If you only want to have people learn one thing, and that thing is pretty easy to learn, Rails is a great choice there. You mentioned LMS. For those listeners who probably don't know what that is, it's just an internal tool and things like that where you're not going to have a lot of updates to the UI. It makes sense. You probably want to keep it simple. MATT: You can just get to market so quickly with a Rails application. It's always been my go-to if I want to quickly prototype something or just get something out because it's time-critical. It's powerful, and it's fast. NATHAN: And there's also the language preference issue, right? I mean, Ruby is such an elegant, beautiful language. It's not just easy to learn. It's really just easy to work with. It does so many things in such a right way that it's just really just pleasant from a developer experience. There are things in which, you know, I wish that they can add in a way that makes sense. I think they're trying to add some type safety to it. I haven't really played with any of that. And from what I've looked at in blogs and whatever, I don't know if I just intuitively got it right away by looking at it. But it'd be nice if that was something that found its way properly in the language and, in the framework, a bit of a different topic. But outside of that, I mean, you know, Ruby is just a fantastic language. So I think if you have a preference for that, Rails is just such a natural, elegant complement to it. MIKE: Yeah, so I'm with you. If you want to get something up quickly, Rails is still, I think, a very compelling option. As you grow, it might be worth considering rethinking the front end. I'm speaking to Rails developers out there. [laughs] Rails does some great things, but it's not the only way. In fact, it's become kind of a niche, idiosyncratic way of doing things on the front end. And because React has just been very useful, you know, it's a useful option that has largely taken over front end because it works. There's always somewhat of the hype train where people do it because other people are doing it. But there have been a lot of options for front end for a long time. People have not been locked down into one option versus the other. And they've stuck with React because it works. That model of thinking about the front end as being as serious of a thing as your back end has some real merit in a lot of circumstances, I think. NATHAN: Agreed. MIKE: I think we've covered some really central points. [chuckles] When you're thinking about the front end, the value of using a framework like React for front-end rendering and the decoupling that it gives you, the advantages of thinking API first. We've also talked a little bit about how it breaks the traditional web paradigm. In some ways, that's still broken. Things like SEO and accessibility still haven't been entirely solved yet because the web was not designed that way. There's still some growth that needs to happen for us to get there. And if you want to get quick to market, maybe that's still not the best way to go. So there are advantages and disadvantages to everything. Now there's another tool to maybe consider putting in your belt [laughs] so that you can use it for the next problem you address. And thank you, and we'll talk to you. You'll hear from us anyway next time.
Today, we talk about challenges that we went through on our path to building a software career. Transcript: MIKE: Hello. Welcome to another episode of the Acima Development Podcast. I'm Mike. I've got with me Eddy, Tad, and Kyle. And today, we're going to be talking about challenges that we went through on our path to a software career. Those of you listening will be able to find both hope as you're going through the tough times but also find things in common, like, oh yeah, I relate to that. It's not just me. I've been thinking about where I'd like to start our episode today, and I think that I'm going to start in 2002. If anybody was doing their career at the time, in 2001, there was the horrific attacks on the skyscrapers in New York on September 11th. And it was, you know, a great tragedy for everybody involved with that. And another consequence of that is that it precipitated the demise of the bubble in investment that had taken place in tech at the time. During the late '90s, there had been a bunch of investment in this new internet thing. [laughs] And people were trying all kinds of business ideas on the internet to see if they'd work. Some of those, famously, were ideas...they lost money on every transaction, but they made up for it in volume. [laughs] A lot of those business models...famously, I think pets.com at the time was just losing loads of money. Investment kept them running. But once the investment dried up when people got scared, the whole tech economy just tanked, and there was a bunch of layoffs. It was kind of the seed of a lot of new stuff in tech as people said, "Oh, wow, I can't work for that company. Well, maybe I'll go try something new." And it worked out in the long run. But it was not a great time to be looking for work. And I had been doing some tech work at the time. And I was finishing up school and went out to get a full-time job, and there was just nothing. [laughs] And I was in a bad spot. I remember just every day feeling like I am so useless [laughs] because I was unable to find anything. I put out lots of resumes. Nothing ever came back. The people I interviewed, with I didn't always hear back from. So I spent several months working part-time doing some kind of freelance work while looking for a good full-time job at the time. Eventually, I got a full-time job. It didn't pay very well. But I stayed there for a while and built it up over time and have been full-time in development ever since. And I think those three months humbled me [laughs] and taught me a lot about keeping on going, even when it looks like there's not a whole lot of options in front of you. And that's kind of where I wanted to start is there's one anecdote from my career from a dark time, dark time for the world really being scared at that moment but also difficult for somebody seeking a career in tech that, you know, it may look bad at the moment, but things do look up. What experiences have you all had? KYLE: My experience was a little bit interesting because I came from a small town where if you had any interest in computers at all, you did everything with computers. And my only knowledge of the field was, okay, well, I'm going to go to school. And the first thing that I saw, you know, was computer engineering. I was very interested in hardware at the time, so it was a perfect fit. I'm still interested in hardware. But that's what I ended up focusing on was computer engineering. I didn't know about any of the fields that were available. I was actually in a calculus class. And one of the guys there that I had been becoming friends with, you know, he's just basically like, "Hey, do you need a job? Come interview at my company." You know, he's telling me about this QA testing and IT, you know. I had an idea of what IT was, but I had no idea what a QA tester was and what that even did in software. So I went and interviewed and landed the job, luckily, and got into the field. And that was one of those things where it was kind of exposure. You know, all of a sudden, I'm learning there's software engineers. There's IT; there's DevOps, there's implementation specialists. Just all of these different branches of software that I'd never even heard of didn't know what they did. I thought a computer guy just did computer stuff. [laughs] And it was very humbling in that sense. So that was something foreign to me at the time. And I ended up going through my career in the sense that, you know, I started out in manual testing. I went to QA automation, went to load testing, and found myself on a DevOps team when none of those paths were what I was originally thinking that I would even do. MIKE: And it's interesting. You weren't even aware that they existed, right? [laughs] KYLE: It's one of those things, like, even to this day, it's, like, if you're not in tech, you know, people ask me, "What do you do?" "I'm a DevOps engineer." "A what?" "I work in software." You know, it's something that people just they have no idea about this. You know, even if you're interested in it, like, and then explaining outside of the industry, like, what it is that you do, I mean, DevOps engineer, systems engineer, right? At least people will go, "Oh, okay. I know what a programmer is." And, from a high level, what I've found is [inaudible 05:12] that's about the best you get. MIKE: And, interestingly, DevOps, in particular, is a relatively young field, right? Much younger than software because it used to be you just had system administrators [laughs] and figuring out how to make that work and treat it as a development-type thing where you have configuration management. And I've heard it well-put; you treat servers like cattle rather than pets, [chuckles] where they're just a herd of things. You don't treat them individually, but, you know, you manage them as a group. That's a different take that's really only been a meaningful field, and for about what? Ten years, Kyle? KYLE: Yeah, and it's even expanding, right? Because even those of us that have been doing DevOps now for a few years, it's, oh, I was in systems engineering. Well, I kind of do more DevOps-y stuff now, right? And then now there are several other, you know, buzz titles is what I'll refer to them as. You know, you've got SREs, Site Reliability Engineers. That tends to fall under the DevOps category. You've got cloud engineers. You've got...what's the name? Platform engineers, right? And it's trying to navigate and figure out, like, with my DevOps skills, do I land under those? Am I more geared towards that? And I think what you're getting at is, you know, we started out managing, like, on-premise servers and setting up workflows there. And that has evolved into a world where it's all in, like, on the cloud, and you're managing on-demand hosts, and, you know, you are treating those as pets, right? Each of those had a name, and you cared about them. And now we're entering into a world where hosts are disposable. If you're not using it at the time, why keep it around? You don't want hosts that are sitting there doing nothing. So, yeah, they're like cattle. If they're not doing anything, if they don't have anything running on them, just go ahead and kill them. Get rid of them. You don't use them, you know. And we have orchestration tools, which is a new tech, which manages that and tells us how many cattle we need at a time. It's a very rapidly changing field of software. MIKE: Yeah. And you were going exactly kind of where I was thinking is it evolves and changes, and some of the subfields there didn't exist even a few years ago. Web development, as a field, didn't exist when I graduated from high school because there was no web. [laughs] It wasn't an option because that field didn't exist. Likewise, with DevOps, there's something to be said there for that need for continuous growth and recognizing that it's okay if we don't know about the field because maybe [chuckles] it didn't exist a couple of years ago. KYLE: Even in software, it's the same way, right? I mean, it used to be that, oh, I'm a programmer, you know. And, like you're saying, well, now there's web programmers. Well, to expand on that, you're not just a programmer anymore a lot of the time. I hear the term software engineer used as more of that blanket statement anymore. But if you're a programmer, you're a Ruby dev. You're a Python dev. You're a front end. You're JavaScript. You're Node, you know. There's 100 different languages now, and people are specializing in those. And to even get deeper into that, you're specializing in what libraries in Java for the web development, right? Like, on the front end, you've got all these different front-end libraries to manage the front end. And it's you have specializations there just because those libraries are so huge anymore. MIKE: Absolutely. You learn a framework, and you define your career. And we can talk a lot about web development, but then there's machine learning, or, you know, systems coding, or desktop development, game development, all so specialized that we don't tend to crossover between them very much. KYLE: Yeah, that's true. I mean, speaking of things that are new, if you did system programming for the longest time if you didn't do it in C, you basically weren't doing it. It's been within the, like, what? Last year or two? All of a sudden, Rust has come on the scene, and they're starting to do that low-level stuff in Rust. MIKE: Yeah, Rust has just really exploded. [laughs] It didn't even exist a few years ago. Oh, we've talked a bit there about that need to recognize that new things are popping up. Tad, I'm interested in what thoughts you have about the challenges you've gone through in your career. TAD: It's interesting. When you first posed that question, I kind of stopped and thought for a bit. And I think I've got maybe two stories that probably contrast and are interesting. I was actually thinking back to the first time I ever contributed anything to open source, and this was back when GitHub was pretty new. And everyone was talking about open source and how important it is for you to get out and contribute and things like that. And I was a fairly new developer. And I don't know that I was terribly confident in my skills probably at the time. And so I found this project, and I'm like, okay. I think it was called, like, a Cookbook or something like that. And people were contributing a bunch of code samples to it. And I noticed that none of the code was syntax-highlighted, really. And there was this really popular theme going around at the time. I can't remember even what the name of it was. And so I'm like, okay, I can figure this out. I will clone the repo. I will format all the code samples with this new theme. I'll figure out how to do the CSS for this theme that everyone seems to be liking, and I will push it back up as a PR. And that will be my first kind of dip my toe in experience to software development and the wider world of open source and things like that. And I submitted it. And the first comment was, "This makes my eyes bleed. I hate this. I can't believe someone would think this was good," [chuckles] right? And I remember just reading that. And after someone says something like that, you know, there's sometimes pile on and like, yeah, this is terrible dadada. I'm like, oh, oh gosh. Uh, oops. [laughs] You know, it's one of those things where you're like, I thought I did something awesome. And I thought I was sharing, and I thought I was doing great. And to just have someone else come along and just kind of, like, pound you down is just...it's a little rough. And, unfortunately, in our domain, there's a lot of, like, you can kind of accidentally run into some of that harshness. Like, some of the first questions I ever asked on Stack Overflow, same thing. You know, like, "Oh, this is a stupid question." "Oh" [vocalization]. You know, like, oh, [vocalization]. All right. Okay. You know, you kind of, like, tail between your legs. And you're like, okay, I guess I won't contribute to that platform anymore. And I think that has been an interesting challenge that I've seen sometimes with younger developers is that they need to kind of be nurtured and sometimes protected from that kind of thing. Because I remember joining my first Linux group, and it was just email threads, like, yo, RTFM, RTFM. Like, anyone would ask a question, and they're just like, yeah, read the manuals kind of thing. And so that's been interesting to see. Hopefully, it's been changing. And, hopefully, we do a better job of kind of nurturing young talent. But, Mike, I think when you were talking about that, I graduated the same time as you roughly. I think a little bit later than that. I came into a world post-bubble. I'm like; I can't even find a job. I might not have the skills. So I actually went back to school and got more skills and then joined and had a little bit more success. But, anyway, that's kind of some of the challenges that I saw when I first started out. As a contrasting story, I think I'd like to sing the praises of a guy. Unfortunately, he's passed away now, but he used to be really big in the Ruby community, named Jim Weirich. And I remember one of my first projects; my company just decided this Ruby on Rails thing looks interesting. Maybe we should try it. And I was learning Ruby and trying to figure things out. And I needed to do XML for something. I don't even remember what it was. And I found this gem called...I think it was XML Builder. And I'm like, oh, this gem doesn't work for what I need. And so I thought, well, I'll email the author and see if he can include this feature in his gem, and then it would work for me, right? And I just kind of naively sent him an email. He actually pointed out to me, he's like, "Oh, actually, my gem does exactly what you need it to do, and this is how you would do it. Your approach would work okay, but here's a different approach." And he sent me some code samples and kind of guided me along. And I was like, oh, wow, this is really good. This is good stuff. And I didn't know who he was. [laughs] It turns out, like, those of you who are kind of in the Ruby community, he's the guy that wrote Rake, and he was really involved early on. And he did some of the bigger gems, like, early on in Ruby's history. And that has really stood out to me that he could have easily told me, "Oh, that's in the documentation. Go figure it out." And it turns out it was. I just had overlooked it. And I didn't have enough Ruby experience to have understood that what I was looking for was there. I needed to experiment a little more and figure it out. But it was really interesting to see. He's like; I'm just some rando on the internet sending him an email. And he took the time to very carefully and very thoughtfully answer my questions, point me in the right direction, and make me feel better about what I was working on. And I think I'm lucky that I've had those experiences as well, or else I might have just dropped out of computer science and programming and things like that. Because I'm like, I don't know, this is a hostile place. This is not fun to do. MIKE: It's interesting. I started by talking about kind of environmental difficulties, like, oh, we were going through a bad economic climate. And Kyle talked about difficulties of just knowing what was out there. You're talking about the human difficulties, and sometimes those are the hardest, right? TAD: Yeah. MIKE: Dealing with people who are unkind can be really crushing. But you found people who saw your worth. It made a big difference. There's probably somebody listening who's feeling like, yeah, there's somebody who acts like a jerk to me, [chuckles] you know, because it happens. It's one of those things that happens in life. I think it's important to realize that sometimes people will act like that. And you should probably remember that it's more about them than it is about you. You know, even the theme that you'd put out there, CSS can be changed. Colors can be changed. [laughs] And the idea of adding a style is a great one. And somebody who has a difference of opinion as to what the colors should be, we call that bikeshedding, where you argue about what color the shed should be painted. And it's really not the important decision. What's important is, like, how do you build the nuclear power plant? There are some very serious decisions that go into there, and what color the bike shed is painted doesn't really matter. The fact that there is a nice shed that you can park your bikes in is the important part. But sometimes, you need to recognize that there are people out there who are not as capable socially as others. You know, some people may even be suffering from some challenges there. They have difficulty responding in social situations. In general, you should not take it too personally. Again, that's hard, but you got through, Tad. TAD: Yeah, that's the thing is, like, I've made some really major contributions since then to open source. Like, I'm just hoping that talking about challenges for people listening to our podcast, I'm just hoping to give people some hope. And say, like, I think everyone starts out new, and inexperienced, and rough. And I think a lot of people have wondered, do I keep doing this? [laughs] And then you find something that kind of keeps you going, and turns out you can do it. And it turns out you can get better. And it turns out there are resources out there. You can find a mentor, or you can find other people that will be your cheerleaders instead of your detractors. KYLE: And just to point out, you know, that I've had similar experiences. When I was starting out, I got ripped because I didn't know how to use Git. And I had a developer that just...he tore into me. And I ended up feeling pretty bad about that and going back to another one of the engineers and just like, "Should I know how to do this?" And they were level-headed about it. And it's just like, "You're new, right?" And it's like, "Yeah." "Did you learn this in your classes yet?" And it's like, "No," you know. But I've come to realize that it is the bad days, or it is those people that have a challenge communicating. There's going to be people that are bristly everywhere. But it's one of those things where, okay, if they're going to be bristly, go to somebody else; ask them for help. And then you expand into the internet, right? And nobody knows who you are. They don't care who you are, for the most part. I've had that experience where it's one in five, one in eight, or whatever the ratio is of what I'll post on, like, Stack Overflow questions there, on if I'll get a bristly response or, you know, and people do pile drive. If one guy is just like, "You're an idiot. This is a stupid question," they'll jump on it, and you get downvoted into the floor. But most of the time, people are willing to help. And I always go back to the situation where maybe it is a stupid question. But nobody knows it's a stupid question until it's a stupid question. And I'm sorry, but I search for those stupid questions all the time on the internet. I want to know answers to those stupid questions. So, if you've got stupid questions for the love, please ask the stupid questions so that I can find them and get through my tasks as well. TAD: Right. I think there's nothing more disheartening than I've got a question; I search on it. And I get a Stack Overflow response, and the person has the exact same question as me, but there aren't any answers. It's just critique. And you're like, oh, dang it. [laughs] Like, ah, you had the exact same...I wish someone would have answered it, and both of us could have gotten something good. It's just frustrating to see that people aren't getting helped. And you who needs the same answer also didn't get help eight years later or something. KYLE: It almost feels like a lot of those responses; they took more time to tell you that you're an idiot than it would have just been to say, "Oh, well, it's easy, this one-liner." TAD: Right. MIKE: You know, in more in-person situations, in meetings...but it applies kind of universally to ask the stupid questions. [laughs] If I'm feeling a little bit lost about something, I try to put myself out there and ask the dumb question first. Because I've learned that, in most cases, there's several other people who had the same question as I did and are trying to figure it out, and they really appreciate somebody giving an answer to that. So, if I can expend a little bit of social capital to [laughs] get my question answered, it's generally well-appreciated. And, in the end, there usually isn't that much social capital expended asking those questions that may seem personally dumb. Yes, there are people who will treat you bad. But, in general, you ask those questions, and people will be like, oh, did I miss that? And they'll go back and revisit their assumptions. Communication is hard sometimes because you don't necessarily have shared understanding or assumptions to begin with. And the person talking about it may have more comprehensive knowledge and leaves out important pieces of the story. And, if you don't ask those questions, you miss those pieces. And it wasn't deliberate on the person who was talking about it. They just didn't know that the people in the audience had that gap. It makes sense to ask the question. KYLE: I would even say, too, those of us, you know, maturing in our positions going into more of the senior level role, right? I feel like a lot of my growth, at least, is learning what it is that I'm not communicating and responding to the quote, unquote, "stupid questions" and going, oh, how did I not explain that? Why is this person not understanding me? So I feel like there's growth on both sides that can be had from these types of situations. MIKE: Absolutely. Like I said, communication is hard. And I know that I'm going to leave some things out, not deliberately but just because I'm fallible. We've talked some about the environmental issues that come up that make things hard and just keeping on working through them. You know, economic downturns happen. There's been a lot of layoffs. We're recording this in 2023, and there have been a lot of tech layoffs over the last few months. And that can be really rough if you're one of the people laid off. That doesn't mean that there aren't jobs out there, that there won't be jobs out there forever. There are cycles in the industry, and it's always come back up. It's not permanent. TAD: From what I've seen, there are still tons of tech jobs out there. It's just some of the bigger companies maybe overhired and needed to make some correction. Because, from what I've seen, there's still plenty of stuff out there. I mean, software is still everywhere, in every industry, in everything. I'm not too worried. MIKE: No, me neither. And I've seen unemployment rates in software, and they're not high. [laughs] People are just leaving some of those big tech companies and going to smaller ones. You know, those kinds of environmental challenges that you might have to deal with, but you work through it; you'll get through it. [chuckles] And then there's, you know, the knowledge gaps that you might have to work through. Again, we all have them. Because the industry moves forward, it's inevitable. It's built into the structure of the system that you're going to have knowledge gaps. And by continuing to embrace learning, you can fill those and, you know, and thrive within your niche that you find yourself in. And, finally, there's, you know, those human issues we've talked about that are maybe most challenging and recognizing that it doesn't say everything about you. And it may say nothing about you when people are unkind. It may say more about the speaker than it does about you. TAD: A lot of times, we talk about learning new things. Some people see that as an opportunity. Some people see that almost like a death march. Like, I can never stop. I can never rest. I have to keep learning all the time, and I'm constantly paranoid that my skills will become obsolete. Because we're talking about challenges kind of in our field, how do you navigate that? Meaning, how do you navigate the constant learning without it being a death march? MIKE: That's a great question. As you said that, I want to reply to that by talking about my two-year-old. He gets up in the morning, and as soon as he's finished yawning, he'll get down, and he will start running and finding the nearest thing that he can touch, and manipulate, throw, step on, jump off of, dismantle, put together, and do something to try to influence it and see what happens. He'll do an experiment, like, how does this work? And try to figure it out. And then he'll run over and grab a book and bring it over and say, "Read this book to me." And I read the book to him. And then he'll run over and bang on an instrument, any number of things. He just spends his whole life experimenting and trying stuff because that's what life's about. It's joyous. And somehow, between ages 2 and 42, we sometimes forget just how fun it is to learn stuff. And I'm going to take that a step further. I would argue that the definition of fun is learning stuff. Looking again at my two-year-old, what's fun for him is to go and experiment with stuff, right? Play mad scientist [chuckles] and try stuff and see what happens. Because there's that thrill of wondering what's going to happen, wondering if what you thought would happen is what's going to happen. If I were to express it in scientific terms, grown-up terms, he's wondering if his hypothesis or wondering if his model accurately represented the world. And if it doesn't, like, oh, cool, I was wrong. What can I learn from that? Now I have to revise my model and understand the world differently. That is fascinating. Fun is about trying stuff and seeing what happens. And, you know, as adults, we say, "Oh, I want to have fun. I want to go on a vacation somewhere to someplace new." And we do that because we want to go see someplace new. We want to go learn something we didn't before. What's boring is doing the same thing day in and day out. I think that fun, by definition, is learning new stuff. And if we remember that, remember that learning is fantastic, [laughs] it's what we were born to do, then it kind of changes our perspective. And it also changes the way you study. Rather than thinking that everything has to be formal, go help with an open-source project, right? Go do something that interests you because that'll keep you engaged and get you through the tedious aspects that are part of learning anything. You know, sometimes it's a lot of repetition. Maybe always, it's a lot of repetition. But if you're doing that in order to, you know, climb up to a higher plateau, you know, if you're climbing a mountain, there's a lot of climbing before you could get to that plateau. But we do it anyway because we want to get to that higher vista. There's my answer. KYLE: While you were talking about that, I was thinking about, you know, how this paralleled into our fields. And we'd been talking about cattle earlier. And, with DevOps, we've already discussed how fast that's moving, that kind of, you know, same thing. You kind of have to enjoy the new stuff, right? And you have to not get attached. You can't really get attached to a specific brand or a software or even a library. It's one of those things where you might have maybe deployment software that is just the bee's knees right now. But here, in two months, there might be something that completely stomps it in features. And being attached and not willing to pivot to that new software is just something that will hold you back in your career. It'll hold back your company, your team, you know, it'll just hold everything back. You're not willing to go to the new product and explore that and figure out, you know, is this better for me? It made me think, too, as you were telling your story about your son and stuff, you know, I'm sitting here drawing that parallel. Even the stuff that you're interested in...I'm sitting here thinking about disc golf. When I first got into disc golf...and I'm not sure how many of our viewers can relate here. I'm hoping that...I'll call it ball golf or just normal golf, has the same thing with the different drivers and woods. And I don't know the terminology very well, that's why I'll stick to the disc golf. But it's one of those things where, you know, you're learning, and it's super fun. You know, at least in my mind, it was super fun. I'm getting better, you know. And what kept me interested was figuring out, oh, what do I need to change about my form? What do I need to do here? And regardless of anything, there's new discs coming out all the time that just have different flight patterns, different characteristics. And it's like, oh, well, I need to go try this. I need to go try that. Some of these things are not going to be better. And some of these things might even be repeats of what you already have in your bag. It's not uncommon in the community to have hundreds of discs, you know, at least tens of discs. And it's like, well, how many do you carry on to the course? Well, you know, 10, you know. So you've just got a bunch of these that are laying around, but you've wanted to try them. You've had that investment because it's something you're interested in. And I feel like software is that same way, you know, maybe the new tech doesn't give you anything that you need, but maybe it will. Maybe it's something that you want to put in your bag of tricks going forward. I think that analogy and just pointing that out is really kind of cool. In my mind, I hadn't really drawn those parallels. TAD: As we've been talking, I've actually...suddenly, I've been reminded of a really excellent presentation by one of my friends named Brandon Hays that did at RubyConf (I forget which Ruby Conference. I've gone to a few.) about surviving the hype cycle. And in it, he talks about the different stages of, like, software and the different types of people that are attracted to each stage and compares it to, like, settling the Old West. So, when you're settling the Old West, first of all, you had, like, the trappers and the explorers that just went out and kind of found stuff. Nobody knew what was out there. They went out. They lived by themselves. They were just thrilled by discovery, and that's great. But then you needed people who would come along and build roads. Like, you'd need people to come along and map these places that they'd heard about and say, like, "Okay, we need some ways for some other person to get there." And then, eventually, you had, like, your small settlement and people who were good at, like, setting up the small settlement and clearing the trees and things like that. And then you had the people who would come in, and it's like, okay, now let's make a proper society, and have laws, and roads in our city and things like that. And I know, for me personally, I look around, and I see something like, oh, there's yet another new JavaScript framework out there. And, oh gosh, like, [laughs] I don't know if I could keep up with every JavaScript framework. But there are some people that love that stuff. And I think trying out the new things and trying out the new framework, and those explorers, right? The people that move in and like to figure things out. And I've discovered about myself is I'm probably not that guy. The idea of keeping up with every new JavaScript framework makes me feel a little tired inside. But I'm maybe, like, a generation or two past that where I'm like, okay, I'm not looking at every new thing. But now that there's a few established frameworks, maybe I'm going to look at Vue versus React and see which one I like better. That's what I'm going to learn, and that's what I'm going to do. And then maybe come back and tell my team about my opinions about that sort of thing. And there's some people that are like, you know what? I like to be at the tail end. I like the boring technology. I like, you know, my old reliable Java framework or whatever, you know. And that's great, too. For me, the challenge was figuring out what type of developer I am and sticking in that lane and not feeling bored by the old and boring, which to some people is great. For them, it's like, familiar, and this is what I'm familiar with. And this is what I'm an expert in, right? And feeling overwhelmed by the new and shiny. And I found that I fall somewhere in the middle between the two that if you find that spot along the continuum that appeals to you, then it's a lot less challenging, I guess because you kind of found your fit. MIKE: That's interesting, talking about those groups of people. Because in every one of those groups, there is room for fun, for experimentation, for discovery. TAD: Right. MIKE: You know, you could be the person out discovering new peoples, and landscapes, and geography, and [chuckles] oceans. Or, you could be the person many generations down; you're the plumber who's figuring out every day how to make those pipes work because every situation is a little bit different. And both of them involve discovery, novel situations, creativity, learning something new every day. And they both have value. And they both can have fun. And finding the fun within those different fields is kind of how you grow your career and find the joy in it. KYLE: Kind of the breadth versus depth concept. You kind of need all of those kind of people in software clear through the span, you know. I'm sitting here thinking and, like, kind of what we're saying here, like, I'm almost going into a phone analogy just to kind of describe the different people. And I'm thinking, you know, there's those people that they need the new iPhone. Every time a new one comes out, they need the new one. And then there's those of us that, ah, my phone works. I don't need to upgrade for four or five generations. Then there's those people that, you know unless it gets an improved camera, or unless we get a new cell technology or something specific, some special feature about it, they don't want to try it. And then there's those people that, like, oh, that's a cool feature, but I'm going to give it a few generations to mature. Like, I don't want to be on the bandwagon. I'm the beta tester testing out this new feature. I want it to mature a bit. And there's just these people, I mean, and that goes into the software too, the libraries, you know. Maybe it's, you know, a language. I got to use the new language. No, I don't want to use the new language unless they have something special that I need. Well, maybe it's a library. You know, you can kind of drill down. And those different aspects, those different tiers, are going to be exciting for different folks. And you don't have to be all in on one way or the other. TAD: So, I've got a question for you, Kyle. I think it was you that mentioned Rust. Do you feel like, oh my gosh, I've got to go learn Rust, or else I'm going to fall behind, or else I'm not going to keep up? Or is Rust something where you're saying, like, okay, that's really interesting. There's other people who are developing a bunch of stuff with Rust right now. But where I want to be is, you know, maybe I'll wait until the DevOps tools have matured a little bit before I look into Rust. Or maybe you're like, that's awesome, but I'm just not going to worry about Rust at all. KYLE: If you're asking how I'm feeling about it from my computer engineering background, I think it's very interesting, you know because I came up developing in C. And I would like to get into it. Have I done much with it at all? No, no. It's very interesting tech to me. But I'm very breadthed [SP] in what I'm learning in DevOps. There's a new monitoring tool every week. There's a new way to, you know, utilize monitoring every week. And so that's where my focus is. It's one of those things where when the tooling comes, I would be happy to try out some of those Rust libraries. But it's not something I'd personally be into. I know that there's just people that are, you know, stumbling over themselves to get in there and learn it as fast as they can and get new libraries written. But yeah, I mean, that kind of goes into the topic. What's your interest? What's fun, and what do you have time for? TAD: So, is the takeaway find the thing that you enjoy and find the niche where that fits, rather than trying to feel like you got to keep up with all the things all the time? MIKE: If you think that you can keep up with all the things all the time, I'm sorry. You've got a rude awakening coming. [laughs] You know, people talk about finding your passion, thinking, well, I got to find the thing that I love. I've read that that's maybe a little bit misleading. You need to find the thing that you're willing to do even when it's a struggle. That's what you care enough about. What's the thing that you're willing to keep doing, even when it's hard? And if you've found that, then you've found your niche. You've found your place that you can thrive because you're willing to keep working on it because that's fun. The cost is worth it to you. TAD: Yeah. And I'm asking these things a little bit just because I've talked to kind of newer developers, and they often do feel overwhelmed. They're like; I'm starting my career. I don't know if I should commit to something or not. What if I commit to the wrong thing, and I totally miss the boat? And I become an expert in outdated technology and, you know, I can't put food on the table for my family, and I can't find a job. And, like, these are, I think, real concerns, but there are still COBOL programmers in the world, right? KYLE: They're high-paying right now, right? Because there are so few of them. TAD: Yeah. MIKE: And, even further, if you go and become an expert in a language, it transfers over. Most of those skills transfer over to a new syntax. The skills that are most important are at a bit higher level than that, above the language. Now, of course, knowing the intricacies of the tool you're working with is important. But you can spend a lot of time developing a skill in one tool and then transfer over to another one and get up to speed pretty quickly. Because, you know, architecture, and design patterns, and, you know, understanding data processing and best practices are not going to change from one framework or language to another. Talking about my two-year-old running around, seeing what he can take apart with a fork, is probably not going to directly translate to what he's doing in his adult life. But the motor skills that he's learning, understanding the physics of how things work, you know, understanding of materials is. [laughs] Understanding the difference between a piece of metal and a piece of sheet rock that matters. And he just needs to be trying something. And I think that that applies to our career as well, go out and try something. And the skills may not directly transfer, but they'll probably still help you. KYLE: I'd say, too, don't be afraid to pivot at all. Because just my example in my career, you know, I wanted to go into hardware. Well, I learned about software, you know, and I wanted to be a developer. Well, I went up the QA track. I really liked the QA track. I landed in DevOps, and I really love DevOps. You don't know what you don't know until you know. [laughs] There's probably a better way to state that. But, like you're saying, try everything, and don't be afraid to explore. MIKE: Eddy, in particular, I don't know that we've heard from you yet. Did you have anything you wanted to share about challenges that you've worked through in starting your career? You're kind of at the beginning of your career, so you might have some interesting stories. EDDY: The initial difficulty for me really was just trying to hash out whether development for me was the right career path. In the beginning, I jumped around with ideas. I'm like, oh, I want to be an artist. I want to be a psychologist. I'm like, huh, well, maybe I think it's time for me to really sit down and see what is the most viable option for my future, something that I can sustain a family? I landed upon development, but even then, you don't know if that is something that you're passionate about until you, like, sit down and really, really start hashing it out and see if that's something that's really for you. So my difficulty in the career that I've started was if this is something that I...was really something I was cut out for or not. And once you get over that hurdle, and you realize, huh, yeah, maybe this is for me. Maybe this is something that's worth my time to be invested in and get really good at. That, for me, was the most difficult hurdle. MIKE: You say you tried it. [laughs] And if you hadn't tried it, you wouldn't have known. EDDY: Exactly. MIKE: There's a recurring theme today of experimentation, play, [laughs] doing new things. And you learned by trying. Sometimes that's intimidating because, like, well, I don't know if this is going to work or not. Maybe it won't work out. Well, maybe it won't, but you're never going to know unless you try. EDDY: It also helps to be surrounded by people who do the same thing. The hardest thing for picking up new talent is having the discipline to keep going. And being surrounded by individuals and constantly communicating with everyone really helps to fuel the fire. MIKE: Definitely. Find people who are good mentors [chuckles], and it will make a huge difference. KYLE: I would just quickly point out, too, that Eddy was saying that he wasn't quite sure where he wanted to focus; you know, he's interested in art, and I think he said psychology. And the one amazing thing that I've seen with software is it's cross-industry. This is something that if he finds that he really, really enjoys software, he doesn't have to give up on the art or the psychology. He can find software where he's doing art, or he's focusing on psychology, you know if that's a route that he wants to go. EDDY: It could be argued to some extent that code is art. And there's also some psychological aspects to development as well. So, like, some of those attributes did kind of play its [inaudible 41:44] role in my career as well. MIKE: There's a great deal of art, I think, in any trade and in software where you're building things from nothing, and it's dramatically so. And it can be fun. EDDY: Do any of you ever look at a file with the code being written, and you're like, "Oh, this just looks beautiful?" And, like, to some degree, we're comparing that to art. And you're like, "Ah, this reads beautiful." This looks beautiful. You know, we're comparing it subconsciously, you know, to some sort of art. MIKE: When I see a well-written unit test that's wonderfully clear, has excellent contexts, covers every branch of logic, doesn't go beyond the boundaries, just excellently follows best practices, I look at that, and I just grin. [laughs] It resonates with me. I like it not just from a professional sense but aesthetically; I find it wonderful. [laughs] Absolutely, I see beautiful code. KYLE: I would say, too, that I feel like I find voice in code. And what I mean by that is once I've worked with developers long enough, I can look at code, and I can be like, oh, XYZ developer wrote this, you know. And you can kind of see kind of like an author would, right? You'd be like, this book is obviously written by this author. If that translates into code, too, it's kind of interesting. EDDY: Actually, I want to ask point blank to everyone here, thus far in your career, can you genuinely read a file and just be like, oh, this is the flavor of Kyle? Oh, this is the flavor of Tad? I know because he enjoys using rockets versus -- KYLE: Well, and that's what I'm talking about. I feel like if I'm around an engineer long enough, I can definitely do that. I can just look at the file, and it's like, oh, yeah, Adrian wrote this. I know who did this. EDDY: That's awesome. MIKE: Absolutely. [chuckles] It's interesting. You can see the stamp of the artist. We started from what are the challenges to hearing about the distinctive style of the artists at their work, that as you grow, you get good enough that you actually leave your own fingerprint on things. And maybe that's a good place to stop today, that you can get to that point. That even though you're going through struggles in your career (You'll run into those times that feel dark.), it can become a joyful artistry that people even recognize your fingerprints on. It's been great talking today. We look forward to next time. And I'll see you next time on the Acima Development Podcast.
Software development is largely an exercise in frustration management. And that is genuinely fundamental to what we do as software developers. How do you manage frustration as a dev? Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. Today, we are going to be talking about frustration management. And you might think, well, what does that have to do with code? [laughs] And I'm going to say that it has almost everything to do with code. Software development is largely an exercise in frustration management. And that, I think, is genuinely fundamental to what we do as software developers. We solve problems, and we have to deal with our inner self, you know, with that inner voice as much as we are dealing with anything else because, you know, that's the tool that we have. We have our minds. And if we're not in control of our emotions and our minds, then we're not going to get much done. I feel like frustration management is genuinely central to being able to be effective as a software developer. I wanted to start with a story. As we were preparing for this, I wanted to share something that was genuinely frustrating for me. A number of years ago, I was tasked with working on a project. Specifically, there was communication. There was messaging not working between two systems. And the library we were using to message between the two systems had a few interesting attributes. [laughs] First of all, it was designed to run in a separate thread, so it kind of ran in the background. It actually did not only run just one thread, but it ran a pool of threads, which meant that there were several different parallel threads of execution running, so it was concurrent. There were several things going on at the same time. Secondly, it was distributed because there was more than one system. There was more than one system that was involved that we were listening to. And you could actually have multiple different processes listening or multiple threads. So you had concurrency at both ends, and it was distributed. And third, it was asynchronous. These messages were sent over a message queue. They arrived kind of when they arrived. So there was no guaranteed delivery time. So it was concurrent, distributed, and asynchronous. And if you've ever tried logging something that is across multiple systems, [laughs] that has multiple threads going at the same time, you may find that it's quite challenging. It is remarkably difficult to find out what is going on there. And, further, the system that I was testing had unit tests that didn't work. They were written for a different messaging system, and they just didn't work with the one we were using. So the tests I had didn't work. The messaging layer was sometimes a little unreliable. The code I was working crashed randomly, and I didn't know why. And all of the kind of standard tools for debugging or logging were somewhat ineffective because you couldn't really figure out what you were latching on to. Also, I didn't know it at the time, but the library that we were using had several critical bugs in it. [laughs] I thought that I was solving messaging, but I was actually solving a bunch of problems at once. And I came in excited. I was recently working at this company. And I wanted to kind of show that I knew what I was doing, spent a day working on this problem and got nowhere, and felt really deflated at the end of the day. Tomorrow will be better. And the next day, the same thing happened. [laughs] I spent all day working on it and got nowhere. And I thought, well, tomorrow I'll get this. And that happened for almost a month. Every day, I tried a new thing. And every day, I left defeated and had to come back and push on it some more. And what I did was I just tried lots of different things. Every day, I would try something new or maybe adding different logging. And, over time, it was imperceptible. It was imperceptible. But I started to see where the problems were. Eventually, I found one bug in our library and got that fixed from the library creator. A while later, I found a bug in our code, and the way it was using the library was causing multiple threads to be spawned, and that wasn't good. That got fixed and made it a little bit better. A little further, I found another bug in the library and solved it. I still hadn't solved the problem. The messaging still wasn't working. But by pushing at it, those incremental changes actually got me a little bit closer. Finally, I decided to redo the way some of the unit tests were running, and I got through the unit tests and got those working, which allowed me to progress. After about a month, I finally got all of the problems solved. And it worked. That library went on to work, essentially without thinking about it for years because I'd taken the time. It was a very painful month. [laughs] That's probably the most challenging project I've ever worked on because it's just so inscrutable. But I got through it, and it was worth it in the end. I share that story because, hopefully, [laughs] it reveals some of what's going on, and it's just kind of some personal confession here. But yeah, sometimes things are hard. I talk to my kids when they're working on things. They get frustrated. And I tell them that there are three things that they should do. There's three specific skills that I teach them that they should use when they get frustrated because frustration happens. Helping them with school, helping with their schoolwork, they're going to get frustrated sometimes. So I tell them three things to do. These are things that I give to my children, but I think that they're very applicable to adults as well. And the three things I tell them that they can do, and I'll ask them, say, "You know, you're feeling frustrated. What can you do?" And then they'll pause for a second, and they'll give me ideas, and they'll choose one. First, they can stop and breathe deeply, close their eyes, and breathe deeply. You may refer to this as meditation. It is the process of stopping, calming down, just listening to your breathing. It may sound like a little thing, but it makes a dramatic difference. It makes a surprising amount of difference in your mental state. Separate yourself from the work and just focus on your breathing. The second thing I suggest to them is exercise. Step away from here, [laughs] your work, and exercise for a minute or two. Some people go for a walk. My kids will often do jumping jacks or run up and down the stairs a few times. And getting blood to your brain has lots of evidence behind it, as giving you some added oxygen and probably glucose. It sends your brain the things that it needs to kind of freshen up and be more clear. And the third thing I tell them is go do something different. If you're really frustrated on something and you hit your head on the wall, go try something different. I find those things are very helpful. I've got a number of other ideas as well. I wanted to lead with these ideas, though, because I think that it's really helpful to have something to start with. So, what are your thoughts about this idea of frustration management? And did those suggestions resonate with you? Or do you have other ideas that really work for you? MATT: I feel like stepping away is key because we face these frustrations every day and repeating the same thing over and over with the same result they call insanity, right? So I feel like stepping away is one of the most important things that someone can do. It helps you gain a little bit of clarity. And you never know when those aha moments are going to come. But I have found that stepping away, thinking about something else brings those aha moments, personally. MIKE: But it's sometimes hard to step away, isn't it? MATT: Oh, absolutely. Because you don't want to feel defeated. KYLE: I've got several different levels of stepping away. I'll get up, and it's maybe just a change of scenery for a second. And you stare out the window. And it's got to be some type of movement for me, at least. Even doing that for a couple of minutes and then coming back will relieve some of the frustration and help me think better or going on a walk. Even changing a scenery, you know, in the sense of changing the environment where you're pairing with somebody that seems to help too. The other thing is just stepping away in the sense of working on something else for 30 minutes to an hour or so just to kind of do a mind dump and then go back and see if you can figure it out from there. EDDY: I was just going to add to Matt's aha moment. Like, I live for those moments personally, and that's what makes, like, super, really fulfilling. [laughs] It's great when you can get unstuck. But talking about what Kyle just said, I think change of scenery is super key, whether that's, like, walking your dogs. Like, that's what I do sometimes. Like, I'll take a 15, walk my dogs, and I'll play with them, play catch. And then, when I come back to the computer, and I look at something, I'm like, well, duh, that was the problem. But it's really hard to see that, you know, when you're tunnel-visioned, so, like, getting a fresh view coming back really does help. MATT: I think that's a great point. Another thing is a different perspective helps me often, if possible, right? If you can reach out to one of your peers and get a different set of eyes on a problem, I find that extremely helpful. But I love paired programming so much because then you don't face that tunnel vision that we sometimes have a tendency to get stuck in. MIKE: So you mentioned pair programming. I came thinking about that as well. You said that another pair of eyes can sometimes help you be less frustrated? MATT: Absolutely. As engineers, we sometimes get into habits and form patterns of how we solve our problems, and they don't always work. But having another person there to talk it through with and give a different perspective can be so enlightening. MIKE: And sometimes people feel like if somebody else is looking at them, they're going to feel bad about themselves and feel more frustrated. So, why do you think, Matt, you said this other perspective is helpful? What do you think is so relevant about pairing that will make it better, even though there's some possibility of social stress there? MATT: Absolutely, there's social stress. But I think that the more we practice it, the less that becomes a problem. At some level, I think we all have some insecurities and don't like to be judged. But if we can get beyond that feeling of judgment and get to a point of openness, the level that it can help you and the rate at which you will succeed becomes so much greater. But that is, as you say, that's another level of frustration that we have to overcome initially, I think. And sometimes that is hard. DAVID: This is a kind of beautiful series of thoughts that are stringing together here for me that, as I was thinking about the podcast topic, I actually came to the call ready to say, "Oh, my secret technique is get therapy." And I laughed at myself. And then I thought, actually, that's kind of a serious idea. If anybody here has ever been to therapy, your therapist will do two things: They will either help you increase your capacity to deal with what you are doing, or they will teach you situational tactics to deal with the specific stresses you are facing right now. And what are we talking about here, right? Get up. Go take a walk. Get some exercise. Get some oxygen. Increase your capacity to handle what's in front of you. And then situational tactics, right? Find a way to disconnect yourself from the stress. Take a break. Walk away. Talk to someone else. Find some psychological safety. This is blowing my mind. It's fantastic. MIKE: There's a recurring theme in lots of conversations we've had here in the podcast that a lot of success in software development is not necessarily about technical skills. A lot of it has to do with your team and their willingness to grant you the psychological safety you just mentioned. It's easy to think, well, yeah, I'm really good at coding. That's not necessarily [laughs] the defining characteristic that's going to lead to success. But rather, it's going to be that collaboration with your team, the ability to have psychological safety, and let people feel safe when they come to you with a question, and they're stuck because we all get stuck. MATT: That's a really good point. I think one of the things over the course of my career that has leveled me up more than anything is working on my communication skills and learning how to listen and not talk over people. That's one of the things that I really work on and sometimes still struggle with. But just working on that problem with myself has helped communication immensely. And when you are able to communicate with your team, and your peers, business, and your customers, I think you level up really quickly. And, ultimately, I think that's all of our goal, right? Is just continue to level up in our career and our personal life and become better. KYLE: I was thinking as we were talking through this that half the time when I'm pairing with somebody or reaching out to somebody, it's more of just a teaching experience, I guess, to some extent. And that's where I've found a lot of the success in pairing and figuring out a problem. And so that, like, reaching out to a team member that maybe has no idea about the topic, and part of the way through explaining that, I'll be like, "Oh, this is a solution, right?" And even so much as in, like, I'll be frustrated and go and try and explain it to my wife where she's not as technically savvy. So I have to put it in more layman's terms. And just the process of putting it in layman's terms, you either solve the problem, or it becomes more apparent to you what the issue might be. MIKE: That process of explaining is amazing, isn't it? [laughs] It reveals all of the...maybe not all of them, but it has a tendency to reveal all the cracks in your thinking, all the gaps that you hadn't filled in, the dots you hadn't connected. It is a remarkable tool. And some people will keep a rubber duck or whatever other toy they choose on their desk to talk to if they don't have somebody to talk to, just so they can explain to somebody. That idea of explaining is so useful. What other things do you all try to deal with your frustration? KYLE: I'll just throw out music therapy. I've got different levels of different genres of music that I will go through as my frustration builds. Sometimes that tends to help as well. DAVID: Ooh, riffing off of that, somebody taught me a technique in middle school that blew my mind, specifically how to use music therapy. Like, if you're in an awful mood and you're just like, well, I've got this library full of...this playlist full of, you know, thousands of songs, how do I fix my mood with music? And he told me the secret. He said, "Go find something in your playlist that matches your current mood and play that, and sync up to it. And then start moving towards music that represents the mood you want to be in." And it was that idea of, like, find the music that matches you right now that was, like, the aha moment for me because, like, if you're furious, then, you know, some calm classical is...you're going to spit it out. You're just, like, get away from me with this. So I have a lot of playlists that start with, like, Rammstein and go towards Mormon Tabernacle Choir by the end of it. And it's a pretty eclectic playlist but profoundly useful. MIKE: It's interesting that music is mentioned. It's another change of environment. The change of environment just keeps on coming up as well. [laughs] Change what's around you. And music is one very active way to change that environment, much like stepping outside would be. DAVID: The nice thing about Utah is we are about 20% relative humidity right now, which means we can walk out when it's 20 below, and you can be in a T-shirt. And you can make it pretty much to the end of the block and back before, you know, serious complications set in. A lot of my friends that are out in, like, you know, Illinois and, you know, Ohio where it's, you know, 90% humidity all the time, they're, like, "You stepped out onto your porch without a coat on? What's wrong with you?" MIKE: We've talked about this change of environment and literally changing your surroundings or what you're listening to. One thing that I find very useful is more figuratively stepping back. When I've been figuratively banging my head against the code for a while, one thing that I find works tremendously for me is to take a figurative step back, maybe a literal one, you know, step back from the laptop. But, figuratively, to start, in my mind, looking at the bigger picture. One thing I find is that when I'm very frustrated, it's usually because I'm running into something that doesn't make sense to me. And if something doesn't make sense, it's often because I'm missing the broader context. I'm looking at something too closely, so I don't see what external to that little piece I'm looking at might be relevant. I find that when I'm stuck when I'm in some sort of hole that I can't get out of, what I need to do is kind of step out of the hole, right? And look at the bigger picture. Well, maybe this doesn't make sense because I'm thinking about the problem wrong. And when I go and look at the surrounding code, look at the...re-evaluate, challenge my assumptions, it can make a tremendous difference. And maybe sometimes the change in the literal environment is conducive to that because you're looking at something different. When that's not an option, and even if it is an option, a lot of times, I find it very useful to take that alternative approach, think, well, this doesn't make sense, which means I'm probably thinking about it wrong. Because if it doesn't make sense, if I'm frustrated if I'm just hitting against it, I'm probably thinking about it in the wrong way. Taking a step back makes a big difference to me. Have you found in your personal work that that is an effective technique? DAVID: When I remember to do it. KYLE: That makes me...I had a manager a few companies back who introduced me to mind mapping. And I don't always start out with that, but when I do get stuck in a problem, I will start mind mapping. And how this relates is when I get so far down a path, I'll either take a step back and see, like, maybe I missed a path for a solution, or I just wasn't thinking that specific section through far enough. And I'll keep going back to see if there's a neural path that I maybe have missed. And that has helped previously. That'll get me out of the weeds a lot of the time, actually. MIKE: What tool do you use to write out that mind map? KYLE: Pen and paper, to be honest with you. DAVID: Yes, I was waiting for you to say one of the 20 different mind-mapping tools that are out there. But every electronic mind mapping tool I've ever found demands that you start at a route, and you descend acyclically down from the route. And I was taught to mind map with pen and paper. And my mind maps are cyclical. I will draw a point, then another point, then a second point or a third point, and then I connect the third point back to the first. And now you've got a cycle. When I'm trying to think my way through a mind map, I will doodle the connections that I've drawn between, like, I will darken this connection because it's stronger. I will circle this node more and more and more and underline it because it's more important. And I just kind of let the pen wander over the mind map, adding nodes as I see fit for them. So, Kyle, I'm your kindred spirit on this. Technology has not been able to solve this problem. They've damaged the problem to make it tractable. KYLE: Yeah, I haven't had good luck with a software-based mind map. The only one that I could say has provided me with better results, especially in a team-type mind mapping, is whiteboard just because, you know, kind of like you're doing adding the different colors and everything. I guess you could do that with colored pencils, but I've never done it that way. MATT: There's something to be said about low-tech. You know, in this high-tech world that we live and work in, sometimes low-tech is the answer. MIKE: So maybe changing your environment from the computer you're working [laughs] on to -- DAVID: It can be. MIKE: Doing something very tactile follows right along the lines of what we've been talking about? MATT: I think so. DAVID: It's important to note that it's not just a matter of, like, sometimes the old ways are better where it's, like, well, no, the modern way is clearly better in every possible way. It's more, like, a case of anybody that used a cell phone around Y2K time period; your calls were much, much clearer than they are now. There's a reason for this. And that is because the cell system 20-25 years ago was analog, and you had infinite fidelity on the signal strength. Now, as you get farther and farther away from the tower, your signal starts to degrade and starts to fall apart and whatnot. And as the cell companies wanted to make more and more money, they cram more and more calls into the same amount of bandwidth, which means they have to compand, which means to degrade the signal of each individual call to make it fit in a thinner slice. And so the calls get more and more digital, and more digital, and more digital. And I remember especially, like, in the mid-noughties to late noughties, it was hard for me to use a cell phone because people sounded like rubber ducks. Everyone sounded...people would just quack over the phone. And it was because they had gotten too aggressive. They had cut everyone's bandwidth down way, way, way too far. And they had to back off and say, "Okay, we have to provide more bandwidth to get more calls. We can't just keep degrading signal quality to make this work." That's the thing with a pen and paper. It's not that it's low-tech and that brute force is the better idea. It's that it's infinitely analog. You can do things like darken a line or change a color. I guess you can change color in a mind mapping tool. But being able to switch pen types, being able to change the tactile input that you get as you write something, being able to move two nodes the exact distance apart that you want them on the page in infinite increments of analog precision, rather than having to just put this node under this node on the tree and it always must be down one line and in two spaces, yeah, it's so much more freeing to have that much more power. MATT: The nostalgia of the old analog phones that you had to strap to your belt. But the best phone I've ever owned in my entire life was an old Sony analog phone that was the size of a brick. [laughs] DAVID: So I've kind of pulled us off into nostalgia a couple of times here. But circling back to the specifics of frustration management, I do like the idea of changing the environment. Internally, we can change our environment as well, I think, which is that if you're sitting at the machine and you're stuck...Mike, I've been in that problem where you've got, like, you talked about the messaging system at the start. You have no idea how the system works. You have no visibility into how the system works. You have no control over the functioning of the system. All you can do is sit outside the black box and just cast things onto the water and hope the output will eventually be different whenever that asynchronous stuff finally, finally comes in. And, like, all of these things kind of stack up to put you in...I don't want to say an abusive environment. [laughs] I don't want to use that word lightly. But it is kind of an environment where you're stuck. And you can get yourself into this kind of stuck thinking where it's like, oh, this is terrible. I'm trapped. I have no resources. I can't get my job done. Oh, in addition to the no observability, no debugability, no, you know, da, da, da, there's also no mercy if you don't get it fixed. So we're going to just keep ratcheting this up until you make it work. And you can feel shackled to the machine. And just, like, ah, how am I going to make this work? Sometimes being able to step back and go, all right, guys, it's just a computer. Let's breathe. There's only two ways this bit can go, either one or zero. How do we reduce this problem? Finding a way to step back and give yourself some control over your environment or just control over yourself can be immensely liberating. And it can open up to you a lot of tools that you had on your belt the entire time, but you kind of get blindered. You stop thinking that, oh, I can deal with this, and you suddenly...half your toolkit has vanished because you're not present to it anymore. I don't know; I feel like I'm babbling. Does this make sense? Where, like, you don't feel trapped and stuck on the machine? Suddenly, all the things that you could have done all along but didn't know suddenly you remember that they exist. I don't know if anybody else has had that experience, but it has for me. MATT: Yeah, freeform, right? DAVID: Mm-hmm. MATT: I, as a hobby, and in a past life early on out of high school, was an artist. And I'm kind of relating to that and the digital age where I feel so much more free using real paint or real pencils versus a tablet to create art. Yeah, there's so many things you can do with technology. But there's something about that freedom and the feeling it gives you doing it the old way. It just...it frees the mind, I think. MIKE: You know, I might expand on that a little bit. The recent surge in generative models used for AI art [laughs] was triggered by some pretty interesting realizations. Previously, there was always an effort to kind of start with something and get to something. [laughs] You got to follow these sorts of rules, or you've got to match this thing. And they decided to try a new technique. What they did is they took an image and then they blurred it a little bit. And then they trained a model to deblur it. You know, add a little bit of noise to the image, some visual noise, and then train a model to deblur it and get back to the original. And then, you add a little bit more noise and see if your model can get back. And then you add a little bit more noise. And they do this, you know, with millions of images. They add a little bit more noise, and a little bit more noise, and a little bit more noise. And then you bring it back to the original. Eventually, they just start with pure noise and some text [laughs] and say, "Bring me back to what this image is." And, in previous models, it had always sort of fallen flat. But this approach where you gave it a completely blank slate, right? Just start with noise and make this look like a duck in a captain's hat. And the AI looks at it, and, like, okay, well, I think I maybe kind of see a duck over there, right? [laughs] And it starts inventing. And, eventually, you get a photorealistic duck with a captain's hat. That approach of going back to perfect, you know, as you said, Matt, freeform, where just, you know, start from scratch. Starting with a blank slate ended up being far more effective than other techniques had been. It doesn't even just work for humans. MATT: And I love that. DAVID: The thing I love about the AI things is when they frame it in a style. So they'll do the make me a picture of a duck in a captain's hat, but do it in the style of a 1960s tobacco billboard. And it produces something that is terrifying. You're just like, oh my gosh, that totally could have been on the side of the road in 1964. MIKE: [laughs] MATT: I have spent so much time playing with those things. MIKE: [laughs] MATT: All of these lead us back to those frustrations. And, as we talk about this, maybe that's one of the answers is find something that you find joy in to help with that frustration. The bottom line is letting it go and, I think, accepting it. DAVID: Resignation to your fate. It's a little fatalist, isn't it? But, yeah, accepting what we have in front of us. MIKE: And I think there's something very liberating in acknowledging reality as it is. And, in fact, I take that further. We've been talking about arts a bit. I'll talk about another art example. I'll talk about Shakespeare. Shakespeare is considered, I think, widely to be the greatest writer in the English language. And one thing that's interesting about Shakespeare is that he had, like, one hand tied behind his back. Because, generally, the form that he was expected to write in had some fairly rigid rules. It had to have a certain number of accented syllables per line. Typically, it was rhyming, right? So the language that he was constrained to use was a rather limited subset of the English language. And, with those constraints, he was able to create great art. And I would argue that, to a degree, the constraints themselves were what enabled him. A teacher mentioned this to me in high school, and it kind of blew my mind. Like, oh, that's an interesting point [chuckles] that once we are given constraints, then we filter down the world of possibilities. And then there's less that you have to deal with, and you can focus in on what you can do. And that's remarkably liberating because, within those constraints, you don't have to think about everything. You can think about what could fit, and it allows you to fill in blanks with something pretty great. MATT: And it really helps us to keep things simple. Humans, by nature, overcomplicate problems. And those constraints can really help you just keep it simple. Don't overcomplicate it. Don't overthink it, and just tackle the task at hand. And, in software, that is really important. I try as hard as possible every time I take on a task to make it as simple as possible. If it needs to become more complex as we go along, that's great. But I always find the simpler, the better, and you usually end up producing better work that way. DAVID: I love that. There's an interesting tension here that we're talking about, like, for creativity...and I heard this back in, like, my 20s, but it's been so true. If you want to increase your creativity, increase your constraints. If you want to write like Shakespeare, tie one of your hands behind your back, figuratively speaking, right? There's a fantastic video by Tom Scott about Why Shakespeare Could Not Have Been French. And I'm, like, that's pretty elitist. No, he's like, literally, the notion of an iamb, which is the thing you make iambic pentameter out of, doesn't exist in French. You literally cannot construct iambic pentameter in French. It doesn't work. There are other types of poetry in French that have meters that match the metrics of the French language, and French poets will follow those. But, yeah, if you want to increase your creativity, increase your constraints. If you don't believe me, try this exercise. First, name every animal that you can think of, and give yourself, like, 10 seconds to do it. And I find I get, like, five or six out there. And then circle back and say, okay, do the same thing, but do it in alphabetical order. And you're like, whoa, what? Somebody has said, "Oh, name all the animals you can think of," all right, fine. I'll start in the alphabet. But if you start with A, you can immediately come up with an animal that starts with A, and you get to 10 seconds, and you realize I just named 12 animals because I constrained myself. The constraint gave me structure. The reason I mention this as a tension is that when I'm debugging, I want to go the other way. I'm already constrained five different ways. I don't know how the system works. I can't observe it. I can't debug it, can't...I don't have unit tests or whatever. What can I do to increase my options and my choices? And sometimes we don't have very many. And that's a good time to just kind of sigh and accept without judgment and just say, "Well, I guess we're going to get pretty creative because we are pretty constrained." MIKE: This idea, I think, is so powerful, and I'll add to it. Multiple of us are musicians here. For those who are musicians, I want you to think about this. If I want to sit down and make some music, invent some music, improvise, well, I just sit down and say, "I'm going to write some music," that's an intractable problem. What am I going to do? But if I sit down and come up with a riff, just if I'm going to play on the piano, I will [inaudible 31:46] my left hand. And I'll come up with some chord progression or play something sort of melodic that sounds interesting and then start repeating playing it as a riff. So it's something that could be in a cycle that I can listen to. Well, now I'm wildly constrained versus what I was before. Now I've got something that I have to work with that I have to fit into. And, suddenly, I can play because now I can invent music that fits within those constraints, and I can make music. And if I remember that, if I ever want to sit down and write a song, you know, in a couple of minutes, I can be improvising and having some fun by starting by limiting that world down to those constraints. MATT: That's such a great example. I kind of do the same thing. If I am asked to just sit down and play something on a guitar, I would fumble. But if you said, "Hey, sit down. Play something. This is the mood I'm looking for," then I can say, "Okay, I can pick a key." And once you constrain it down to a key, it becomes really easy because there are constraints on how you're playing it. DAVID: That's impressive. And various things can imply a lot more constraints, right? Like if you say, "Play me something moody," that's going to constrain things gently in a certain direction. But if I say 12-bar blues in G minor, you know the chord progression now. It's 12 bars, and you have to start on the one, and there's rules for how they come out. And so you've got your chord sequence now. MATT: Yeah, if someone says, "Play something moody," I think, okay, A minor because that, to me, is the moodiest key. It makes it so much easier locking things down, having constraints, which, in software development, we have requirements, right? And if we don't have requirements for a problem, then it makes it really difficult to solve. MIKE: I'm going to take this right back hard into software. We've been talking about constraints. Frustration, in the general sense, to be frustrated that word means to be stopped, to have your course blocked. And these constraints we mention are essentially that, right? They're frustrations. They're barriers. They're obstacles. And what we're saying is that those frustrations actually provide us a framework in which we can create beautiful things. And it's the existence of those frustrations that gives our work shape and even meaning. KYLE: I was thinking about this as you guys were talking about music. I don't play, but my family had sent this YouTube video that was talking about how they did the music for the Dune movie. And, in that, we were all kind of shocked to see that the bagpipe that you end up hearing in some of the scenes they were saying that that wasn't actually done by a bagpipe. That was done by an electric guitar. They had just taken a different approach to generating those sounds. And I think that can be related to software in the sense that you can constrain yourself but don't let the constraint be of frustration in the sense of, like, that you tunnel. And what I mean by that is don't go so far into a tunnel that you're insisting on using a specific tool. Sometimes another tool will provide you with the same result, if not a better one. The example that I can think of right now is just on our team. The easiest tool for us to use, specifically our lead that designed the Acima script; he was very familiar with Ruby, and he was able to bust out the script in Ruby. But that didn't make it as easy to pass it around. And so, he took a different approach with another tool and used Golang. And that made it easy to distribute an executable to all of these systems. And so much now that, you know, Apple silicon or ARM64 is becoming a more popular option. We need something for those environments. And this has allowed us, because of that tool, to now generate that software, you know, with just one or two changes. Then we have an executable that will run on those. So it's cross-platform now. Just thinking about that, just while you're constrained, don't also tunnel because that can just add to your frustration. MIKE: Oh, that's great. DAVID: I think approaching your constraints as a challenge as opposed to a trap or something that just leaves you powerless...something that I keep hearing come back, and back, and back as we talk about this is the notion that sometimes we look at the challenges in life with fear. And other times, we look at them with wonder and excitement. And the only difference is the attitude that we bring to it. Looking at the inconsistencies, or the challenges, the difficulties that we face, when we see them with kind of, like, wonder, they become opportunities. They become interesting things to play with. They become flavors to taste rather than things to be pushed away and kept at a safe distance. And I think that mindset really, really makes it a lot more powerful, a lot more capable for us to kind of relax and just kind of play with what we have. And that helps us find the way out that we're looking for. MIKE: I love that: flavors to taste. There's one other thing I wanted to bring up, and I think that it builds on that idea of joy you just brought up, Dave, which I think is phenomenal. I think the one other technique that we really haven't talked about is asking a question, what else could I try? And to your point about, you know, this is a world of discovery, if you're in a situation and you feel like, well, there's nothing I can do, well, then there's probably nothing you can do. [laughs] You've made a choice. But there usually is something, even if it's trivial, right? Well, I could breathe differently. [laughs] That is an experiment. That is play. If you look at the problem and say, "What else could I try? Is there maybe some way I could add some logging to this that is crazy but maybe does something, or is really simple and crude, but it would maybe get some information out of this?" Or maybe I usually use a debugger. Maybe I could just use some simple text logging. Or maybe I could add a request ID to all of my requests that I make so I can track what's going through. Or maybe I could log my thread ID so I can connect the thread with the outputs going on. There's usually something else we can do, and seeing the world as a big sandbox. What could I try next? Changes that perspective. It gives me an opportunity to keep trying. DAVID: Amen. One of the best tools or ideas put into my quiver early, early on, was the notion that debugging doesn't stop when you run out of answers. It stops when you run out of questions. As long as you can sit back and say, "What else can I try? What else is there? Have we looked at this?" There's always more things to find out. So, yeah, when you run out of answers, it's time to loop back up a level, not to just give up. MATT: I love that. MIKE: That, I think, is the perfect place to kind of land here. Yeah. Thanks for joining us and for all of your thoughts. And thank you to our listeners. I hope that you've gotten some value out of these tools you can use to work through the constraints that you have and even celebrate the constraints that you're working with. With that, see you next time.
How do we work effectively with product people? Transcript: DAVID: Hello and welcome to the Acima Developers Podcast. I'm David Brady, and today we've got a huge panel. It's going to be awesome. We've got Mike Challis and Ramses Bateman. We've got David Solano. We've got Afton Call. We've got Kyle Archer, and we've got JP Porter with us today. And today, we're going to talk about working effectively with product people. And we actually went and got ourselves some product people. We have Jeff Madsen and Tyson Novakovich on the call with us. So, you guys know that I like to start with just the topic of the call is the opening question. How do we work effectively with product people? MIKE: I've seen it work well, and I've seen it work not so well. I'm going to point out that Jeff Madsen, who's here he's visiting us, and he's from outside of Acima. And so he's our guest product person today. And I've had great experience working with him on the product. So he's an example of how things work well, as is Tyson, actually. And I've had other times where it's worked badly. For example, I worked at a place where there were product people who would spend weeks writing up lengthy technical documents were essentially unreadable and would hand them off to us and say, "Okay, can you go build this?" And then we wouldn't hear from them again [laughs] because they [crosstalk 01:21] DAVID: And if you have any questions, read the document harder. MIKE: Yes, that's exactly how it was. And I would argue that that's an example of how things should not go. And I think that illustrates how things should go, and the difference that I've seen with some of the great product folks like we have on the call with us. JEFF: I can promise you, as can most people on this phone call, you do not want me writing technical documentation. That is not going to go well. When Mike says unreadable, he means it's in a completely foreign language that is not English or technical. It's in a garbled mess. And so that is not what product should be doing. And I totally agree. So, I was thinking about how do I want to prepare for this and how do we want to move with this? And it got me thinking about one of the things that made our team the fact that we worked so well together is we kind of divided up what are the things that it takes to build good software? And we had a really strong technical team that's represented by everybody on this phone call, besides Tyson and I. And then we needed a team that could go and say, you know, what do people actually want? What would be useful? And when I first started, Mike, Afton, I think you two are the only ones that would probably remember this. But there was a pretty rigorous every week we meet, and every week; we write stuff down in a backlog. And every week, we add more to that backlog so that next week, we can ignore what we wrote in the backlog and then do something else that was more important. Does that sound familiar? MIKE: [laughs] Changing priorities? JEFF: [laughs] Yeah. And I think what we all kind of accepted is that I don't know what two weeks from now is going to look like. I don't know what tomorrow is going to look like for now. So let's focus on what's the most important for today. And what's most important is, what problem can we solve together that's going to drive business value as soon as we can? Tyson, what do you think about that statement? Like, if that's product's job is to work with development and say, "What problem can we solve together today to drive value as soon as we can?" What do you think? TYSON: I think it goes back to the...how I think about it is deciphering what the business actually wants. Because they're going to say they want this idea, like, hey, we want to improve this application throughput, figure it out. Or we want this fancy new button that does all this stuff. Can we build it? You're like, oh, actually, no, you want to do X, Y, and Z. It's much smaller pieces. In this big sweeping change, we can, you know, improve it by we as product decipher that, so that when we go to engineering and work with the developers, it's not, hey, can we build this exciting thing? It's hey, here is this idea of what they want to improve. But then it's very much so a conversation between product and development, like, what ways can we do this? You know, we'll probably come up with some ideas of things we can change. But, I mean, developers are interacting with the code and how features work 24/7. And so it's...they'll have their ideas. And I think it's very much so a conversation between the two groups. That's kind of how I see it. MIKE: Both of you pointed out something that stood out to me, and it kind of goes back to startup culture, to a degree, that, yeah, there might be different priorities each week, and that's not necessarily wrong. Now, maybe every week, that is wrong. [laughs] If you don't have the flexibility to change, then, you know, if you'd say, "Hey, we know exactly what we're building, and we're going to work on it for the next three years as a startup without any ability to be flexible," you're probably going to be out of business in six months. That flexibility is vitally important when you're small but sometimes companies forget that when they're larger and that agility, I think, retains its value. Maybe you have longer time horizons that you can work with. But that doesn't change the fact that we're not very good, to your point Tyson, about building a big thing. Nobody is in any context. I don't think anybody says, "I'm going to build a skyscraper. Step one, build a skyscraper." There's an art, and much of the art of what we do is figuring out that sequence. And I love that both Jeff and Tyson talked about that sequencing, like, well, yeah, you want a skyscraper? Great. We might need some materials. We might need a foundation. We might need some contractors to work on this. We might need some bulldozers. JEFF: The other piece that Tyson [inaudible 05:35] great bit by bit, right? Is a lot of times, people will come and they say, "I want a button that does these 17 things." And when you start adding in here's the first thing, here's the second thing, usually by the time you get to the third or fourth action, it's good enough. We jokingly use a phrase where I work now, is it less worse, right? Like, the goal is to get things to be just a little bit better than they are. And usually, by the time you're not completely finished with a product or completely finished with development of a feature, it's good enough to move on to the next most important thing. And when we started this call, we were all kind of joking about Mike, your time horizons, right? That you brought that up of being able to be agile and not be locked down. We were all kind of joking about how we've all worked at a company that's moved at an incredibly slow pace, and it's because we try to plan. We try to figure it out. We do one deploy a year, or we do one deploy a month. Everything is so time-driven, as opposed to user impact-driven. And I think one thing that I appreciated most working with this team was Tyson, or I could come and tell a story, and we would say, "Here's what's happening. Let me give you some context so that we're all working from the same shared understanding." We would tell a story. We would then say, "Here's the problem with that story. And what we're actually trying to get at the ending instead of Little Red Riding Hood's grandma getting eaten by the wolf, we actually want Little Red Riding Hood to show up a little bit early and be able to save the day." So we tell a story about a new future that we all want to live in together. And we go, okay, well, if you just want Little Red Riding Hood's grandma to live, there's a ton of ways we can get there. Let's talk about some of them. Here's an idea. Here's an idea. Here's an idea. And so then it becomes a mixed bag of here's what I can do. I can build Little Red Riding Hood's Grandma a skyscraper. And I can put her on the top floor with a bunch of security guards in between. Is that really what we want to do? Because that would take a really long time. Or why don't we just tell Little Red Riding Hood's grandma not to answer the door? That might be the easiest thing, and that requires no building. That requires no development. But it gets us to the right outcome. But talking about all of these things collectively and saying, you know, there's a spectrum of right answers that require X amount of dev effort and time, which equates to money and a delayed satisfaction for the end user. And then there's some that are different options that are out of the box where it's just, hey, send grandma a text message to say, "Hey, I just saw a wolf. Don't open the door." So talking about a lot of those things makes it so that the team can come up with a solution and then work together. And now you're all pulling a cart in the same direction. I think, like you mentioned, somebody goes off into a corner, you know, previous jobs. They write a bunch of technical documents, drop it off on your desk, and disappear. And that's probably the least helpful thing because you don't know anything that went on behind the scenes. Why are we even asking for this? Is this the actual problem we want to be solving? And I have 7,000 ideas that I could just tell you that if we cut out a ton of this, we'd still get to the same spot. DAVID: Now I've got this idea stuck in my head that there's a meeting. They're going around the board to solve the Little Red Riding Hood problem. And these suggestions are thrown out. And then finally, like, the VP of engineering says, "All right, look, we've got budget for one more headcount, so start talking to me about woodcutters." MIKE: [laughs] The nice thing about this is if you're being conscious about costs and thinking about that and what is actually driving value, maybe you could use that budget to hire somebody different because you don't need the woodcutter anymore. And, you know, you can avoid some of the trouble and hire more effectively. I love how Jeff and Tyson talked about reframing the problem, that they both talked about telling stories and then jointly coming up with a solution. Now, the developers are going to understand the technical details and be able to come up with technical solutions. The product side is coming with a vision of what the problem is. A lot of times, the developers are kind of divorced or isolated from what users are actually experiencing. They don't necessarily know what needs to be worked on. Product is, you know, their job is to know very much what that is. So they're bringing this tremendous value of knowing what is needed, but they don't necessarily know how to build it. And developers, on the other side, they know how to make stuff, but we're not quite sure what to make that's going to be valuable for the company. And when those two meet, then you can come up with a shared vision that is significantly better than either could come up with alone. JEFF: To piggyback on that, Mike, I think one of the things that I've noticed, you know, we're talking about the difference between great product managers and product managers that are getting started and trying to figure out what's next for them is I think a great product manager can tell you why they're asking for something. They can say, "The user wanted a button that sent unicorns, and laser beams, and a pot of gold with a leprechaun at the end of it." But why did they want that? They've gone in. They've spent time with the user, and they've spent time with the person who's asking for this new thing. And they can then come back and say, "Hey, development team, like, there's this pain that's being felt by a user, and they want to solve it. This is what they asked for. I have some thoughts. Here's what I think it is." But let's pause for a second and say I can tell you why. The second thing that I think a great product manager can tell you is where does this fit in terms of the urgency, right? Like, hey, actually, this pain is bad, and it's getting worse. Something's happened where we have changed a piece of code, and now things aren't going the way we thought, or a new business requirement has come up. We have a new client. And so they can tell you why and where it fits in the priority. And then it's that joint effort to get to the how. Mike, you and I used to always talk about there's the right way. And if we were to do this the right way where we went, like, full technical build out, build the full framework and the structure, it would probably be about this long. I think it would take this many people, you know, highest level, I don't know, ballpark. Let's think about this. And then we would talk about, okay, well, what's the fastest route? And I think it goes back to, I mean, one of the things that always comes up, and I feel like it's a point of friction between product and development, is, well, what you're asking me to do on the timeframe I'm doing it on it is unfeasible. And I'm going to build an unstable structure. And I'm going to create a bunch of technical debt. And understanding that as a product manager is significant because things that are fragile break, and things that aren't meant to be scaled will inevitably be scaled. I don't know how many times I have said, "It's going to be just this one customer. It's going to be just this one thing," and then all of a sudden, you turn around two weeks later, and sales is asking for ten more people to be put on the same thing. And so, Mike, we always used to talk about this technical debt is it, am I putting this on a high-interest credit card? Am I putting this on a low-interest subset? How am I going to have to pay for this debt if I'm not doing the ideal because it doesn't drive the value on the timeframe that the business needs? How am I going to have to pay for that later? MIKE: And sometimes when you have those discussions...you mentioned the text message [laughs]...that sometimes when you're in a pinch, the right answer is maybe neither of the above options. But maybe when you understand what the needs are, there's another way to meet those needs that maybe doesn't build the right solution but doesn't build the wrong solution either but builds a minimal solution. You know, particularly when you're in a startup-type situation, you've got a limited budget and limited time, right? If you don't move quickly and efficiently, you can go under. And coming up with a creative or an innovative way to approach the problem that maybe is unexpected can actually solve the problem without leaving much technical debt, or maybe no technical debt without building the big, grand solution that you originally envisioned. I watched a documentary once about the famous Skunk Works Program that built a lot of the well-known military aircraft. And I'm not, like, an enthusiast, so I know not big. I mean, it's interesting, [chuckles] but I'm not going to know all of the technical details. But one thing that really stood out to me is some of the things that they did when they were building these airplanes. For example, they wanted to build a spy plane that could fly really high. And, to do that, they had to have wings that were outrageously long, and they drag on the ground. So what they basically did was stuck a bicycle wheel onto the end of each wing and said, "Well, maybe someday we'll come up with a solution," and they never did. They put it into production, and they just put a bicycle wheel under each [laughs] of them, you know, with, like, a unicycle under the end of each the wings, which kept the end of the wings off the ground. And when it took off, the wheels just kind of rolled and tipped over and the plane took off. That's all you needed. They had a plane that needed to go so fast that the materials used to build it would deform. And, on the ground, it was leaking fuel, just dumping fuel. At heat, it would expand, and it would close up, and the fuel lines would close, and everything would be fine. But when it was stopped, fuel was just pouring out of the plane. And they thought, what are we going to do about this? And, eventually, they just did nothing. They just filled it with fuel, let the fuel dump, and took off the plane, and when it got into the air, the fuel stopped dumping. Sometimes the things you think you're going to need you don't necessarily need. JEFF: I really want to meet those test pilots, you know, the guy who gets into the airplane as it's dumping fuel on the ground and says, "Yeah, let's hit it." [laughs] DAVID: I want to say I read somewhere that that particular plane takes off with about 10% fuel reserve. Once they take off, they punch the throttle and do a couple of laps and wait for the plane to heat up. And then they go refuel in the air. That was the one workaround for how do we keep this from dumping, you know, all 20,000 pounds of fuel? Just put 2,000 pounds of fuel in it until we can get it hot. That was the SR-71, right? MIKE: I think that's right. Yeah. JEFF: That example just goes back to, like, how do you work together to build a product that functions? You're going to go in with a bunch of assumptions. Everybody will, right? Well, I think I can do this, and I think it's going to work. And, Dave, your example is just, like, when you're talking about product development iterations through this and, like, okay, well, we know that the properties of this metal will expand. We know that this will actually close up when we're at speed. But, well, great, but now how do we get it in the air? And I think it just is another testament to product and development we need to work together to solve the most high-value problem that's in front of you today. Whether you're at a startup and that high-value problem is we need to figure out how to make more money so the business exists, or you at a giant enterprise and you're trying to say, okay, what I'm doing is actually going to be a little bit different. It's not maybe life or death for the company, but there are things that matter there. And there's different levels of priority, and being able to sift through those together and make things less worse, right? How do we progress together on solving the most important problem? And there's creative solutions of how do I get fuel from leaking out of the plane? Well, just don't put it in. MIKE: And you talked a lot about priority, Jeff. Are you saying that we should always be working on the most important thing? [laughs] JEFF: Oh, if only that were true, Mike. [laughs] If only we could live in a world where that was the ability, right? MIKE: But, somehow, it's really easy to work on things that maybe aren't the most important thing because they're in front of us. We get myopic. We work on the thing that we're seeing rather than the thing that we should be doing. That process of prioritization you're talking about means that we actually do work on the important thing, and that is such a huge deal. And it's hard. It's hard, and it's hard to get right. JEFF: And it's continuous as well, right? Like, we've talked a lot about airplanes. Every few months, there's this story about the Air Force was looking at all the planes that were coming back and trying to figure out, okay, where do we need to add more reinforcement for their armor? Okay, well, this one came back, and all the wings were shot up, and this one came back, and the tail was shot up, and this one came back...And we need to add more reinforcement for the cockpit so the pilots all feel safe. And then somebody said, "Let's look and see where are we not seeing any damage because those were the planes that aren't coming back. Like, where are planes getting shot, and they're going down, and we're never getting people back?" And I think that that process of trying to ask the opposite question, trying to figure out, I see that all these planes are coming back, and they're just filled with holes. Okay, well, that's great. If you're trying to protect pilots, let's not patch all those holes. Let's go and say, "Where did they get hit, and they didn't make it?" You have to think about that. It's a deliberate action that you're trying to go through. And listening to the users on the product side is incredibly important. But you have to listen to what they're not saying. You have to listen to what you're not seeing. You have to listen to...and try to find the rest of the story, and that is where you can pull more of the priority. And we talked about technical debt and things like that. And that's...from a product perspective, the development team that you're working with, the people that are helping you build, you need to listen to them as well. When they say something's about to fall apart, you should listen. Like, I think that's...part of the challenge is there's lots of different theories and thoughts on how products should work. And if you're the CEO of the product, or you're the final decision maker, or you're the voice, you know, there's a lot of these things. And the answer is a little bit of all of them, right? You work with your user in the business but also work with the tech side to make sure that you're not neglecting your monthly investment in paying down your tech debt. Making sure you've built stable code, making sure that the thing that you said as a product manager or the thing that you lied about as a product manager and said, "Only one person is ever going to use," and now there's 1,500 people using it. Is it still going to work? Like listening and pulling and trying to put all of that together and asking people, right? Like, we talk a lot about...I call it the trade-off game. Because every time you choose to do something new, you're choosing to not do something else. And making those decisions clear for everybody of saying, okay, if we're going to take developers and put them all on these projects...Mike, you and I would talk about this quite a bit of saying, okay, this means we're not investing in our tech debt for a while. Mike, what does your gut tell you? Is that okay? You know, like, are we going to be all right? Are we going to get sunk? And then you go to the business and say, "Hey, we've ignored paying our tech debt for so long. We can't do that anymore. So I can work on this new feature for you, but that means that everything we just pushed out is at risk because it's not scaling well. It's not growing well." MIKE: I have some thoughts about how that tech debt ought to be handled. But I'm going to pass on those for now. [laughs] I'm going to throw out there that it's good to make that credit card payment every month. JEFF: And, ideally, more than the minimum, right? Like -- [laughs] MIKE: Yes, exactly. JEFF: [laughs] Yes, yeah. DAVID: I actually have a question for you, Jeff. And some of the devs on this team will go, oh yeah, I've been there. I've worked on teams before where the product owner has come to us and said, "Here's what I want built. Here's how I want it built. Here's the problem I want to solve. Here's how I want to solve it," which should be a red flag, by the way, because it's the engineers' job to figure out how we're going to solve the problem. But the thing that we get presented from product they basically say, "Here. We need all of this," or "It's not worth shipping any of it." And so when you come back and say, "Okay, well, can we break this down by priority?" And they say, "No, everything is the top priority." I wish that was a joke. But I really have worked on multiple teams where that was the thing. And so I'm like, well, from agile, we're going to break it down by priority. I guess what we're going to do is we're going to start at the top of the stack and just move...the priority is arbitrary. And I've noticed that those two things go hand in hand. The backlog is on unprioritized or unprioritizable. And product is just saying, "We have to have every single card in the backlog done because, at 99%, we do not have a viable product." Help. [laughs] That's my question for you, Jeff. Help. How do we get around that? JEFF: There's a concept...and when you said the backlog every single card has to be done, there's a concept that is brought up in a book called INSPIRED. It's written by Marty Cagan. It's, I mean, anyone who is looking at getting into product or how, you know, figuring out how to do this or how to build...The title of the book is INSPIRED: How to Build Tech Products People Love. And I'm going to take a wild swing at this, Dave, and say it all starts at the very, very beginning. When you put something in a backlog...the concept that is introduced in this book is called a validated backlog. One of the things that we've actually done at the company I work now is we've separated out where did the ideas go, and then where did the good ideas go? Where did the actionable things go? And we spend a lot of time sifting through the ideas. We have a separate place. We have a separate container. We use a totally separate tool than what is the development backlog. And the reason why we do that is because, from a product perspective, anything that we throw into a backlog for development that sits for more than maybe a month, I'm now questioning the validity of it. If it could sit for a month without doing it, why did we prioritize it in the beginning? So you got to go back and look at that. So going back to this other holding ground, you got to sit and think about these things. And it's only once you've figured out, once you've worked with users, and once you've talked to them, and once you've asked them...We're actually going through this process right now. We're trying to develop...we're going from zero to one, no mobile app to a mobile app for an end user to use, a consumer-grade mobile app. Well, if you look at any mobile app, it's got your user settings, your notification settings, your preferences, your dark mode, your display, you know, there's, like, 75 things that are just kind of given, you know, my air quotes, "given" for a mobile app that arguably drive no business value. And so what we have started to do is we're trying to get into this validated idea portion. And so we have some assumptions about what we think people would want to do most often with that mobile app that we're trying to build. And so we're building out, and we're spending time. We're saying, okay, let me put myself in a day in the life of the end user of this and say...so I work for a travel company, right? So three days prior to me taking a trip, what would I be doing? The day of the trip, what would I be doing? While I'm at the airport, what would I be doing? Once I'm getting ready to go to my hotel, you know, so we're trying to go through and identify these core events or these key milestones in this journey and saying, what would I be doing? What would I be doing? And we're saying, okay, I want to be able to manage...get alerts about my flight delays. I want to be able to pull up my hotel reservation really quickly. I want to be able to make sure that I'm getting my SkyMiles points so that I can get my next flight for free. There's all of these things that are happening. But when do they happen, and how do they happen? And then we actually are just creating a big list of them. And this is where I think product rolls up their sleeves and figures this out. This is how you get to why does the problem need to be solved and in relation to what? Because we're actually going out, and we created a bunch of surveys and said, "You know, here's the seven things that this mobile app could do. How would you rank them, user?" Let's go ask 200 people. "You're a traveler. How would you rank these?" And then the next question is, okay, if you couldn't do the thing that you put at the top of that list, like, if you have a travel app, and this sounds kind of weird, but what if you can't book a ticket? What if you can't book a flight? What other collection of pieces would provide enough value for you to download this? And so now we're getting this user feedback, and we're pulling in these stories, and we're saying, okay, I'm going to change the game a little bit for you, user. I'm not going to give you your number one thing. Would you still use it? If so, why? And now we're starting to be able to get some layers and some nuance and some differentiation between it's not these seven things are nothing. This one thing carries a ton of weight, but it just so happens it's the most complicated. It's the hardest thing for us to do. But if we can give them these two or three things, there's still value. And we can start trickling this into the market and getting users slowly and iteratively, and adding more and getting their feedback. And maybe that idea that we had to solve or build feature number two, number three, and number four were totally wrong. And isn't it great to know that now instead of after the 18 months we spent building feature one and then released it? So it's that validated backlog where you can go back in. And I honestly think that, as a developer, I 100% think that it is your right, and you need to push back on product guys. I think a lot of times we come in like the Top Gun pilots, and we're like, oh, we're totally cool, and we know everything. And we're going to tell you exactly what you said, Dave, like, here's the problem. Here's how I want it solved. Here's this, and here's how you should do it, and ta-ta-ta-ta, right? Like, pushback. Call us out. Like, we're wrong. We're human. And hold us accountable. DAVID: I love that answer for a couple of reasons. One is the idea of validation at a granular level is beautiful. Like you're saying, if you spend nine months or 18 months before releasing the product, before validating that idea, there's an extra wrinkle there, I think, which is that you're not going to validate idea number one. You're just going to assume that the entire product flopped, and you're not going to know why. Because there's 78 ideas in there, and they're all Jeff's grand vision of the 2.0. And it flopped because things weren't...you know what I mean? JEFF: My grand vision of the 2.0 was perfect, Dave, okay? [laughs] Because I'm infallible, right? No. I totally agree. And I think that it goes back to, I mean, maybe it doesn't flop, but maybe it doesn't work. And if I've got 78 things in there, how am I supposed to know where the issue is? We spend a ton of time talking about single-piece processing, you know, isolating the change, monitoring the change, and then knowing how to react if something goes wrong, right? Like, I want to do this big giant thing, but it's a series of steps. Okay, well, let's take step one. Going back to the skyscraper analogy that Mike brought up, like, let's dig a big hole so we can make sure it's going to be big enough, like, do we have enough land? Okay, yeah, we have enough land. Okay, let's dig a big hole and make sure we have enough room to pour this. Now let's pour this. There's these checking spots along the way to ensure that you're still delivering the right value. And then there's always the check-in of, like, have I delivered enough value? I don't need to finish everything. Maybe we get to the point where we say, you know, feature number one was and is the aspirational goal for this mobile app or whatever. But it turns out that the sum of the value provided by features 2, 4, 6, and 9 actually are greater than 1. And we were able to do those in two months as opposed to two years. So let's figure that out. Small pieces, small changes. MIKE: You've said a couple of things there, Jeff, that if you push out more than one thing, you don't know which one made a difference. And you also talked about 2.0. So I was thinking so 1.7.3.9 is actually important? [laughs] It sounds like yes. And you're saying a big part of the reason for that is that if you don't push out those features in isolation, then you can't evaluate them very well in isolation. Do I hear you right? JEFF: Yeah. And I appreciate the 1.7.3.9, like, yeah, 100%. And I think that there's this big challenge. And, Mike, you've talked about the startup life. I am super fortunate. And I really love where I work because I work at a company that's a 30-year-old company. It's been under the same ownership group for 30 years. It's a business that's doing well. I mean, it survived the travel pandemic, you know, and all of that scare. So it's a stable company. It's got a long history. We're no longer trying to say, do I have product-market fit? Am I going to make it to next month? Am I going to make it to the next quarter? They've survived this big recent scare that was an industry-wide scare for travel in general. But what they did is they took a hard look at what they've done, and they've said, oh man, we've missed the boat. We haven't created value for our users. And so, let's pause and hit the reset button. And so I'm fortunate that I get to work at the best-funded startup, right? Like, it's a really awesome opportunity for me. I'm excited. And what it's proven is we have a lot of stuff that's actually on version 7.0. And what we realized is that everything from 5 to 6.9 didn't drive value. And so now we're going back and saying, do I really want to go to 8.0? Or do I just want to start over and say, here's MVP, here's 0.1? And I'm going to take another attempt at trying to solve your problem. And the reason why I'm bringing that up is because I think that there's this product maturity that happens over time. And there's a lot of conversation about a minimum viable product. And, Dave, I think that's exactly what you're hitting on of, like, how do I truly define the minimum amount of work that I can do to create something that's viable? And that is really difficult. And I'm going to kind of challenge a little bit about what you said, Mike, of like, once a product's reached maturity, it is super important to isolate these changes. But, at some point, you have to find enough things. And maybe that's a couple of different features to go from 0 to 1 or 0 to 0.5. I think it's a totally different mindset of I've got a mature product where I'm iterating through and optimizing, or I'm creating something that's brand new. How do I minimize the amount of work I need to do to make something brand new? And so I honestly don't know. We're in the middle of trying to figure this out as well. Because I showed up and we were talking, you know, I started a year ago, actually, this month. And one of the first things they talked about is, like, hey, we've got this mobile app, and it's going to do these 17 things, and it's going to be awesome. The dev team's been working on it, and they're still working on it. And you know what? Sadly, we're still working on it because we weren't diligent enough about minimum. It's hard to go from zero to one. And so, I would love to hear your feedback on how do you launch something that's brand new where you do need to have a collection of features? But it's got to be the right collection that's the least amount of effort that creates the most value. So, Mike, I agree. But I think there's this wrinkle in there that's new product creation; there are a few things that you do kind of need to bundle up, or you need to find out how to balance those. MIKE: I'll bite on that a little bit. If you're doing a minimum viable product...I've heard a quote attributed to Steve Jobs. I haven't verified it, but I believe that it's correct. It says that if you're not embarrassed by your first release, you're doing it wrong. [laughs] JEFF: Yeah, I think that's Reid Hoffman in LinkedIn, actually. MIKE: It's an excellent idea that you need to tamp down your vision a little bit and be just vicious in determining what that minimum actually is. And think about anything you can possibly cut. Anything beyond that is risk. I'll say that it's risk because anything you add to the bundle is extra work that you put in that you haven't validated. So I think we need to be exceptionally willing to cut anything that could possibly not be truly minimum. That's one trick. And there's also another trick that sometimes people use, and that's the word beta. [laughs] Sometimes you can release something that's not fully viable but provides some value in a niche to say, hey, you know what? We're launching this. And you find a subset of your users that are kind of the power users. And you say, you know what? We don't have everything that we need, but we're going to try this new thing. Would you like to have this extra feature? And there are a subset of your users that probably do. They would like to try out that new feature without having all of the things. They might like just one of the things. And you work with that group, and you're actually giving them something, right? As long as you build it with quality, you're developing loyalty with your customers by giving a subset of your customers a more valuable experience. And in return for giving them that experience, you get feedback. You get some validation as to whether that product was valuable. There's my couple of thoughts and an answer to your question. JEFF: I love the concept of, I'm going to call this what it is, and it's not done. [laughter] So you can be as mad as you want. I totally agree with you. But we've talked to 10 or 15 of you, and you think that there's value in it. And that idea of being embarrassed, I love that paired with the beta. Because you're saying I have done the bare minimum possible, but I told you that upfront. And you told me that you'd be willing to try, so please don't be mad at me. Please be nice to me. [laughs] Like, I don't need to be embarrassed because I already told you. I lead transparency in that engagement with your users and your customers. I think that is truly where, you know, you get the user, a designer, a product person, and a developer. And I think that combination is where you create incredible value for people. I think about Airbnb when they launched and how they were like, okay, we don't know what to do, like, you're just going to go sleep on somebody's couch? Like, that's such a crazy idea. That entire business concept was probably kind of embarrassing for people to just say, like, oh yeah, I'm just going to sleep on this person's couch over here, but then it caught on. And now it's this massive industry that's also spun out a whole new real estate empire of, like, I now own properties that I do Airbnb rent. Like, it's generated all this stuff. So it may have been a little bit weird, a little bit different, but they owned it. And they said, yes, this is kind of interesting. It might not be for everybody, but there's somebody who would pay for this, and let me go talk to that person. And I'm just going to tell them, "It's not done, but we'd love to know how you would change this." [crosstalk 35:43] It's always easier, to be honest [laughs] and transparent than to try to hide stuff. DAVID: There's an interesting idea that somebody pressed me on on Twitter or Mastodon or one of those social media things. We were talking about MVP. And there's this interesting notion that going from zero to one, you don't go from a 0.9.9 version, which is in-house, and you only show it to your team. You don't go directly from there to a nationwide release, to the open market, and loyal customers, and angry customers, and hostile competitors all using your product. There's this idea that maybe the MVP goes to a much more sympathetic audience where, you know, we say, "Hey, this is beta. It should work no matter how you use it, but it's not going to, so let us know." Or you even say, "Hey, this is an alpha sketch of an idea. It probably won't work. But I think if you coax the software, [laughs] you can manipulate it and trick it into doing the thing that you want. Just be gentle with it. You can baby it. But it will let you book your travel, or it will let you order your Airbnb, or it will let you sign up for, you know, a lease in a completely new way." And because you're showing that to somebody who's very sympathetic to you, who's very friendly to your company, they're like, "Oh yeah, I would love to see this." And then they know, oh yeah, I can't type that in there. It breaks the app. But if I do this and I do...wait, I can go from here to here? Holy crap, that's amazing. And you just validated your idea. But you had to do it with somebody who was very sympathetic, and it was a very small release audience. And that's somebody that you can hand a 0.1 to, and you can tell them with a straight face, "I want you to try this and tell me your thoughts. It's probably not going to go into the final product. I just need to know if this one idea works or not." JEFF: Yeah. Find your friends, your friendly customers. DAVID: [laughs] I like it. JEFF: Yeah. DAVID: It's like Airbnb but for beta testers. JEFF: [laughs] DAVID: There's a business idea. This has been a fantastic discussion, Jeff. Thank you for coming. We lost Tyson partway through. Unfortunately, he's busy. JEFF: Thank you. I appreciate it. It's been a blast being here. So it's been nice to come back and talk to everybody, hang out again.
Why do you use or why do you not use Ruby? Transcript: MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'll be hosting again this week. We have with us: Matt, Eddy, Kyle, and Ramses. And I hope to hear lots from them today. Our topic is going to be about the Ruby programming language and, specifically, why or why you might not want to use Ruby. This is maybe an interesting time to be talking about that. To give a little bit of history of the Ruby programming language, it's been around since 1995 or so. The creator goes by Matz. He's from Japan. And Ruby was very popular originally in Japan. It was one of the few languages that was documented well in Japanese and became extremely popular in Japan. It wasn't so very popular outside of Japan. I'll get to the moment that changed in a moment. Ruby is an interesting language. It was inspired by a couple of languages, in particular, maybe most pointedly Perl and Smalltalk. Perl being a scripting language primarily used in shell scripts but also used a lot in the early web, and that is wildly flexible. If anybody has ever used Perl, reading Perl code is not for the faint of heart, but it's exceptionally powerful. And the people who use it tend to love it. And that was a lot of the inspiration for Ruby. So Ruby is very good at text parsing and doing the kinds of things you'd want to run scripts in the shell for. Ruby was also heavily inspired by object-oriented languages, not necessarily the ones you might think of like Java, but Smalltalk, which is deeply, deeply object-oriented. Ruby is more object-oriented [laughs] than most object-oriented things in that it doesn't even have what you typically think of as primitives. You can call methods on integers. You can call methods on strings, their objects, just like anything else is an object. Really, anything is an object you can call. You can call methods on methods. [chuckles] It's deeply object-oriented. But, on the flip side, it's also a deeply functional language in that every line is an expression. And it borrows a lot from functional languages as well. You don't ever see for loops in Ruby because idiomatic Ruby doesn't use that kind of approach, that kind of procedural approach. We use iteration and pass anonymous functions. It's got a special syntax for anonymous functions. So it's both deeply functional and deeply object-oriented and very good at text parsing. It's kind of an interesting language that allows you to do a lot of different things rather than necessarily having one way to do everything. So that was around 1995, Ruby was created. About ten years later, in 2005, there was a big change in web development. There was a new framework that came out called Ruby on Rails. And, at the time, in web development (I was out there at the time. [chuckles]), web development was pretty clunky. There was a lot of boilerplate you had to set up. There was vast amounts of configuration files. In the Java world, you'd set up a lot of configuration in, like, XML files before you could do anything. In the other interpreted languages like PHP, there was...really kind of fast and loose. People would do a lot of things without much protection, and there were a lot of security problems. By default, there were a lot of problems with unsanitized database access. And as a result, there were a lot of security breaches. So over on the scripting side, a lot of mess, over on the kind of big enterprise side, very difficult to use. And Ruby on Rails came out, kind of bridging the world between those two. And it was written in a scripting language, giving you the ease of use of a scripting language and the quickness. Using an interpreted language, you tend to go faster with some of the structure that you'd get in the big enterprisey sort of frameworks. And it followed a lot of best practices, such as convention over configuration, so a lot of that boilerplate just went away. And it had a huge impact. Most of the web frameworks today are heavily inspired by Rails, even if they don't exactly follow what Rails did at the time. Now, we are getting close to 20 years after that, and, you know, the world has moved on. Ruby on Rails is still around, but it's no longer the, you know, the top dog. I did a little research this morning, and JavaScript frameworks have absolutely taken over both on the client side and on the server side. We've got a world where there are client-side frameworks like React that dominate. And on the server side, JavaScript has largely stepped up as well. The most popular server-side frameworks are also written in JavaScript, well, with Node.js. Python, which is a similar kind of language to Ruby, is also quite popular on the server side, and PHP is still kicking around too. You got frameworks like Laravel. The world has changed. Ruby on Rails inspired a lot of other frameworks, but itself has continued to evolve or maybe hasn't evolved as much as some of the others, which brings us to today. Our question is, why might you or might you not use Ruby today? I want to share one anecdote of when I started using Rails myself. I started using Rails in 2005, the year it came out in beta. I was a Java developer at the time. And I first saw a presentation at a Java users group about Ruby on Rails. And I thought, ah-ah, I could do any of that in Java. [laughs] I honestly wasn't very impressed when I first heard about it. And then, I got pressured by the company I was working at at the time to switch over to a scripting language. They were pushing for PHP. And I'd seen the kind of lack of structure at the time, and I was very resistant to kind of going into that Wild West that was out there at the time. But I thought, you know what? I'm going to try this new framework I heard about, Ruby on Rails. I learned the language and wrote a prototype over a weekend. I kind of devoted my weekend to it, which says something. I was able to learn the framework and write a prototype of the app we were in over the weekend. We built out that app. And within a few months, we had rewritten our primary app in 1/10th the lines of code. There was literally 1/10th of the lines of code, even as we'd continued to add features. So the application could do more with a tenth lines of code as we had in Java because it's so much terser, and so much boilerplate was removed. I was impressed and kind of in love, [laughs] to be honest. It was so nice. And I've been doing mostly Rails in the years since, and I've seen some good and bad. I can speak a lot to that. As to whether I'd start a new project in Rails today, I very well might. It'd depend on what I would do. If I wanted to do a very traditional web application, maybe with fast prototyping, I'd almost certainly go with Rails. If I wanted to do something new that had a heavy front end, I might use Rails on the back end because it's still a fantastic back end. But it's a good chance I'd use a JavaScript front end and not use what Rails provides for the front end. So if I were to share my opinion at a really high level of some things I might do, that's what I'd share. For anybody who's considering using Ruby, it's nice to know some of the history. I'm interested in what other people think about where Ruby and Rails are today (Rails has really dominated Ruby development since it came out) and whether or not you'd use it in a new project. Any thoughts, anyone? EDDY: I went ahead and looked up at the top languages or stack of 2022. This one's particularly the most popular programming, scripting, and markup languages found from Stack Overflow. And to kind of reinforce what you were saying, JavaScript came in at 65%. MIKE: Wow. EDDY: Which is a huge chunk, right? And then dwindling down from that, you have HTML, CSS, SQL, Python, TypeScript, and all the way in the bottom 6% of those were Ruby. So it kind of just gives me the impression, you know, that the hype train for Ruby has dwindled quite a bit over the years. And this is just judging off of the 2022 statistics. It begs the question, I guess, the context being why or why not Ruby? Well, I guess you could debate, based off this chart, that for job security potential or stuff like that, maybe Ruby was not a bad choice. But, again, I guess it just depends on what you're really aiming for. MIKE: Yeah, popularity is an interesting metric because if it's highly popular, there's probably a lot of jobs available. That doesn't necessarily mean those are the best-paying jobs. [laughs] Ruby developers have generally been relatively well paid, I think because they tend to be able to do more with less. You get a lot done; it makes you more valuable. But if you can't find any developers, well, then the company is not going to hire Ruby developers, and the market collapses, and then your value as a Ruby developer just disappears anyway. And there's a balance there, you know, 6% is still some. There's still a decent Ruby market out there. I mean, there's millions of websites out there. There are still large enterprise-y applications out there on Ruby on Rails, such as Shopify or GitHub. So, you know, there's still a vibrant Ruby ecosystem out there. But, to your point, 6% is not 60%. It's ten times smaller than the JavaScript world out there. EDDY: I'm hoping you can kind of elaborate on that a little bit on why it's gone down. Is it just because it's an old language and, you know, loud voices get more attention? You know, so, like, JavaScript will get more popularity since you have different frameworks. Python and TypeScript is the new thing. So I'm just curious on, like, what has attributed to the popularity? MATT: Like Mike, you and I have a very similar past in our career path and the languages that we've written in. Engineers, in general, have a tendency to jump on the hype trains, and we see things that are new and shiny. And because of the way our minds work, we're very curious, so we like to try new things. That's one of the reasons I think that JavaScript has taken so much traction because, you know, we spent all of these years only using it on the front end. And now that we can use it on the back end, it's like, oh my gosh, I can use everything in my application in one language. But, you know, you'll find that front end and back end are very different, especially if you're using TypeScript and things like that. I personally am not ready for the JavaScript back-end world. I don't feel like there's enough structure yet. There are a few frameworks, things like NestJs, that help with that. But just coming from someone who was strictly JavaScript, it makes codebases extremely hard to work in when people don't establish consistent patterns. And that's something that I really love about Rails. You know, there are definitely different ways of doing things with Rails. However, I think, for the most part, you're going to find a handful of patterns that get followed. I don't mean structurally as far as your code organization and things like that, but I mean the way your code is written. Ruby and Rails are very, very easy to follow and, like Mike said, very fast, and you can get a lot done with very little. And for that reason, I absolutely would use Rails for a back-end system today. And again, like Mike said, I would use a JavaScript framework for the front end because you can definitely get more done that way. But that's kind of my opinion, you know, coming from, historically, I started out writing conversion code, converting COBOL scripts to Perl and PHP. Talk about a nightmare. And you really quickly see how loose and fast PHP could be as well. But, again, it was loose, and back then, everything was procedural. I think we yearn for some structure and some organization in our code. MIKE: You know, you asked, Eddy, why people might be jumping on the new thing. I think that there is, you know, that hype that draws people. I think that's part of why people got on the Rails bandwagon in the first place as well, you know because you get some hype. People want to kind of be with the popular thing. And that's something hard to escape in human nature. But I think it's a bit more than that as well. But somewhat related, if you're going to be writing a big JavaScript front end, you're spending day in day out in JavaScript, and then you have to write a different language on the back end. That's a little challenging that you have to think in two different ways. If you can write in the same language on the front and the back end, you avoid some of that. Now, I agree with Matt that they're pretty different between the front and the back end. And the back-end frameworks are not the same as the front-end frameworks. My experience thus far has been, yeah, they don't provide as much structure as I would like to have. And they tend to degrade into a mess without a lot of diligence and care from the developers, which sometimes is hard to maintain over a large group of developers in the company. There's some risk there. But not having to change languages is a real bonus. And a lot of people have gone with that since JavaScript is the only option on the front end, and you're having to do JavaScript. People think, well, why not just also do JavaScript on the back end? You know, that's kind of a compelling argument, especially for a smaller application, a smaller back end. It's convincing to a lot of people. There's also been the rise of Python, which is a similar language to Ruby. I'm not going to say they're identical. They have somewhat different takes on things, but they kind of fall into the same space. And Python has gotten very popular in the machine learning community, and where machine learning has been under such a big boom in the last few years. Now you have another language that a lot of people are using, and they don't necessarily want to learn something else to go into web development. So, if you're already doing a lot of machine learning, you're likely going to be using Python and using a Python framework, again, just so you don't have to have two different things that you're doing. And I think that there's a lot of that as well; people just want to use the same tool that they've been using. So, if you're doing a lot of heavy JavaScript front end, it's likely you're going to do some on the back end. If you're going to be doing a lot of heavy machine learning-type work, you're probably going to use Python because that's what you're already familiar with. Kyle, I'm interested from your perspective because you're over on the DevOps side, and you use a lot of different kinds of tools. And you've probably seen some of this, like, oh, I've gotten used to this tool, so I'm going to use more of it for this, or [chuckles] maybe you use so many tools that you're just, like, whatever fits in the moment. KYLE: We're kind of a bit of a mix. We kind of started out as the team was growing. And I came with more of a Python background. My manager came with a Ruby background. And then my team lead; he had more of a Bash background for all the scripting that, you know, that we're doing. And that has kind of mixed as we've done things. And so when I've written monitoring tools, that's been in Python just because it's been familiar to me. And when backup jobs and stuff like that have been written, those have been in Bash because that's what was familiar to my team lead. However, a lot of the other stuff was by our manager, and he was familiar with Ruby. So him and I go back and forth on that because there is a little bit of a competition between Python and Ruby, just at least in our team and, you know, which one's the better language. It's mostly a joke than anything anymore because, well, I do like Python. And I could do the same things that I do in Ruby in Python. I've actually adopted and started writing a lot of our Terraform generators, is what we call them, using ERB just because the ERB option with Ruby is just so friendly to me, at least, to where I can just put a little bit of Ruby code into the ERB to help with the generation. And when I'm saying generation, we're creating little Ruby apps to generate our HCL code for our Terraform. We have quite a bit of that just to get our automation done. And that's just been easier to do than deviating to Python or something, as well as when we have been working with services in the teams because we do have Ruby developers here. It's really nice in our environment because we do work cross-services; not all the services are on the same version. And it's RVM, I believe, just feels so fleshed out to me. It's just really easy to set up those virtual environments. And maybe it's just the way I use it, but I haven't had that ease of a virtual environment. With Python, I tend to have issues here and there. Whereas RVM, I've hardly ever had any issues. So that's been really nice on the Ruby perspective. It's also been good...we have a tool called [inaudible 16:45], which is an internal tool which does wrap a lot of the more common CLIs like the AWS CLI and stuff. A proof of concept for that just to see how it'd work out that was written in Ruby, just because it was easier and faster to get it done. To solidify it to where it was, you know, cross-platform that ended up being written in Golang. But to get a proof of concept going Ruby is just really easy to kind of get those things done. It's really easy to get scripting, really easy to get templates going. MIKE: And there are quite a few systems, DevOps tools that are written in Ruby. Are there not? You mentioned the ability to do ERB scripts with Terraform. And I haven't been much on the DevOps side for a long time. But I know that I will occasionally see this tool, like, oh, that's written in Ruby. KYLE: You know, you say that, and nothing's coming to mind right now. I'm only thinking of the Python ones, but yeah, there are definitely some Ruby ones. I just have to think a bit harder. MIKE: Yeah, I know that there are a few of them. And maybe they fall out of, again, with the hype cycle. Puppet is written in Chef or written in Ruby; it looks like. And it may have been slipping somewhat out of popularity. I'd have to go dig because I don't have a lot of expertise in there. KYLE: Yeah. Puppet they have competition from other ones like Ansible, and Ansible is what we use. MIKE: So that, yeah, that's interesting. So you end up using a lot of tools. You like Ruby, but there's other tools that can also get the job done. [laughs] And the best tool for the job, it sounds like. MATT: I firmly believe that teams should use the best tool for the job. One of the things I forgot to mention, though, with Ruby and Rails is you can really ramp up new engineers very quickly with Ruby, and I found probably more quickly than with most other languages. If they have any experience in other languages and understand basic programming principles, Ruby is really easy to pick up. MIKE: I think there's a lot of truth to that. I might ask Ramses. You've been doing software development for a few years now. [laughs] What are your thoughts about learning Ruby as a primary language? RAMSES: Yeah, I've been doing it full-time for almost a year. But then, outside of it, I guess, for almost two years now. Yeah, Ruby was mostly my first language. I've delved into some others, like JavaScript, of course, and Lua, and a few others. But, yeah, Ruby was...it's just easy to ramp up pretty quickly and cling on to, I think. It's easy to read, you know, which really helps in learning the language if you can understand it quickly, and you don't have to think about it too hard. MIKE: You say Ruby is easy to read. I think it's shockingly easy to read if you've been maybe working with another language for a while [chuckles]. Ruby lends itself to very friendly, almost human language-looking code, not in, like, a forced way. But it just...the idioms naturally flow such that it reads similar to human languages. And that means that your code ends up looking almost like documentation. And I think that has tremendous value. MATT: It's the old joke that good code documents itself, right? MIKE: Right. [laughs] And you say it's a joke, and it is a joke. Like, I don't need any comments. I don't need documentation. My code is great. Those are separate concerns. But the truth is, if you have code that is really easy to read, that has a huge influence on the ability of new developers to get up to speed. If you have very obscure code, you may end up having developers scrap it and start over again, even if the code was perfectly good, just because they can't understand it. And if you can't understand something, you can't adequately maintain it, or you're taking so much time understanding it that you might as well have rewritten it, to begin with, and no amount of documentation can really fix that. So using a language and even just paradigms—this applies beyond Ruby—writing in a style that lends itself to ease of reading is a big deal, in my opinion. MATT: I 100% agree with that statement. EDDY: The toughest part about being a new developer or your aspirations is, like, shifting your brain to think in a certain way. And if you pick up a language that has a daunting syntax, it's just really hard to wrap your head around everything else. So, if you pick up Ruby as an introduction to the language or to programming, I feel like it starts cultivating your brain in such a way that it gets easier to pivot to other languages once you get your thought process and your brain thinking that way, or at least it was for me anyways. MIKE: I've actually read, not for programming languages but for natural languages, that there's been some research that says that learning a language that's easy for you it sometimes...and there's even, like, artificial language like Esperanto, which is sort of this made up language that's the generalized European language that's meant to be easy to pick up, easy to speak, and follow some loosely Latin roots to make it familiar to people with some European background. People who learn that language can then much more easily pick up their next natural language. So, if you are somebody who comes from a European language background, or Western language background, say English, and you want to learn something like Chinese, it can actually be faster to learn another European language like, say, Esperanto or Spanish, or French, you name it, first, and then learn Chinese. And you will actually learn, you know, you can go study Mandarin. You'll actually learn that second language faster than if you started with the second language to begin with. [laughs] That stepping stone actually does train your mind. And there's research behind it. You can look it up. I don't have the reference right in front of me, but I've absolutely seen that. I think that that's strongly backed up. That's a really interesting point. EDDY: So, yes, so I would argue, yes, Ruby, for new developers. So for people who are aspiring but have no prior experience. MIKE: And it's also interesting because Ruby will encourage you to kind of go functional light, [laughs] to start thinking about things in some at least moderately functional way, as well as learning object-oriented, kind of an object-oriented paradigm at the same time. So if you're going to move on and go into functional languages, or if you're going to go on and do object-oriented programming, you've already had a taste of it and will be well prepared and have your mind thinking about how to think about problems in that way. I don't know that I thought about that as an advantage of Ruby before. I'm glad you brought that up, Eddy. So we've talked a lot about kind of the utility of Ruby and where it's been good for us. Where are some places that you might not want to use Ruby? If you're going to take on a project, where would you say, no, I'm not going to use Ruby? MATT: Personally, anything with machine learning, I would definitely go with Python, anything with a heavy CPU and, you know, file processing, things like that. And, historically, you know, I came from the healthcare world, and we used to have to process these enormous EDI files. And I did a test because, initially, we wrote these converters in Ruby. One of the files may take an hour to process in Ruby. I converted one of them to Python, and it took, I think, three minutes. So definitely anything that has to do a lot of heavy lifting and file parsing I would not use Ruby for. MIKE: That's interesting. Were you using raw Ruby, or were you using some libraries? In particular, were you touching ActiveRecord at all? MATT: No ActiveRecord. We did use some libraries that were a clone of some C libraries, but it just couldn't do the lifting like Python could. And, I mean, ultimately, C is probably the best answer. But there were very few people in the company who knew C. So we ended up converting to Python because some of us knew Python. MIKE: Well, the interesting thing is that Python has a reputation as a slow language. And in some cases, Ruby is faster than Python. But, and here's the big caveat there, is there are libraries written in Ruby and in Python that are written in C. And so if you can exploit one of those libraries, you're just using a thin front end and a convenient language to use that really fast one. And it sounds to me like you were probably using some C code under the hood that was given to you by Python and -- MATT: Yes, yes. MIKE: So you really were using C, right? [laughs] MATT: Yeah, but we just didn't have to write it in C. MIKE: Yeah, exactly. [laughs] I used a library quite a few years ago, in Ruby, that was a clone of the searching library from Java, Lucene, that underlies, like, whatever everybody uses for search. I say everybody, but that's not quite true, but it's largely true. Lucene is used by Elasticsearch and Solr. And pretty much every search solution I've seen uses Lucene under the hood. Somebody cloned it in C and made it into a plugin that you could use in Ruby. And I used that in a tool that was called Ferret, I think. I used it a number of years ago. And it was so fast. It was so blindingly fast. It was wonderful and buggy. [laughs] And when we got some scale, it would just crash. So we had multiple parallel instances of it running, and the company I was working for was using it heavily. And we were growing really fast. And over the course of a couple of months, it went from failing, like, once a day to failing, like, once a minute, [laughs] and that was clearly unacceptable. So there are some downsides to having that C behind the scenes if you don't have very well-written C that is heavily exercised by a lot of people and well-tested. EDDY: So I read a while back, and I don't know how true this is because I haven't had time to back-check. But, at one point, I believe Ruby on Rails was accused of being difficult to upscale. And I think that's part of the reason why Twitter moved away from that to Scala, I believe. And I think that's what the initial conversation that sparked the debate around Ruby on Rails scalability issues. So I'm just curious if anyone has any experience. MIKE: I have been in multiple startups that have grown tremendously, you know, that same company I was telling about that grew. We were serving about half a billion requests per month for a while. There's certainly bigger, but we had a lot of traffic. I read some articles about this. But I don't think that that was really what Twitter's problem was. The problem was that they were using MySQL as a router, [laughs] and that aspect of the architecture was the key problem. And the language was largely irrelevant. And it was some fundamental architectural shifts, I think, that made the difference for them. I don't think that Scala is a bad choice. And I think that it probably made them somewhat faster in some regard. But I don't think that that was fundamental to their scalability issues. I think that it was something more fundamental architecturally. Because, in modern web development, the way that you scale is you go out horizontally. And if you're using a somewhat slower tool, you can usually just scale out a little bit more and balance development costs versus server costs. And, oftentimes, the development costs are higher. So if you can make the development costs lower, you scale better, which is why people don't write all of their web code in C even though, technically, they could make it faster. You know, most of it's done in interpreted languages [laughs] because the developer cost is higher, and it works. It works just fine. They can scale out. I really think that that is a false argument, from my perspective, because it suggests that it's crashing to use an interpreted language. And if that was so, then why is 65% of the web development being done in JavaScript? It doesn't seem like it holds water to me. That's my opinion. MATT: I think you hit the nail on the head. MIKE: To take that a little bit further, if the top languages are JavaScript, and Python, and PHP, [laughs] and that's what the modern web runs on, yeah, it blows that argument completely out of the water. Because, you know, Rails is a similar language, you know, it's an interpreted language. And they're all going to be, you know, approximately similar in performance. And you might get one that's twice as fast, maybe. But, in the end, that's just not going to make that much difference. Again, the development costs are going to dominate over your server costs unless you're, you know, Facebook or Google, in which case, yeah, you should be using some really powerful low-level tools. And that's really not...well, maybe that's another place you wouldn't want to start with, Ruby. But the truth is, yes, you would because if you're going to be starting your startup, you're not Google. You're not Twitter. You're not a huge company X. You're some much smaller company. And you want to be able to prototype and get to market quickly and be able to keep your development costs low. So you're not going to want to build all of the heavy web infrastructure to launch your tiny little site that supports one client to begin with. That would be a foolhardy way to approach your company. MATT: I think that's a great point because when you are prototyping and trying to get to market quickly, you add a lot of tech debt, generally, right? Most initial applications are full of tech debt. And I think one of the nice things about Ruby and Rails is that refactors can go a lot more quickly than other languages. Extractions are pretty straightforward, for the most part. I think you're creating something that's going to be easier to manage and maintain until the necessity for something more powerful arises. MIKE: Yeah. I think that's really well said. You're not going to scale to the size of the internet giants on your first platform. To your point about tech debt, what you build your first platform to do is not what your final platform is going to need to do. It's going to evolve over time. And I think you need to go in recognizing that that's the case. And maybe you'll be able to scale enough. And a tool like Rails or some of the other tools we've mentioned will scale enough. Facebook has managed to do with PHP, and it's pretty much worked for them. Certainly, it's not going to be PHP all the way down, but you can make those work for quite a long ways. And then, for the time when you get big enough, we'll then use the right tool for the job. KYLE: From a performance perspective, having supported different languages, different applications written in different languages in a production environment, moreso thinking about in a Kubernetes environment, because that's what we use here, I would say that there was a bias, at least in my mind, around some of these languages, Ruby included, where it was one of those one to two ratios, meaning one CPU to two gigs of RAM to run any of these things in a stable manner. I wouldn't necessarily say that Ruby is the most lightweight. However, in the options that we've used here at this company, it does perform quite well. And scaling a Ruby application out with Kubernetes, meaning scaling it out with multiple pods, has been quite successful for us. So, like Mike was saying, maybe in a larger corporation where there is massive amount of traffic, Ruby wouldn't be the solution. However, from what I've seen with the traffic that we get, the Ruby apps do scale quite well, in my opinion. MIKE: Spoken from a DevOps engineer there. [laughs] That's really interesting. Thanks, Kyle. EDDY: Assuming that you do, in fact, decide, hey, I do want to build my website in the Ruby language, I was just curious to get the perspective of the group here on, like, why Rails is the top dollar when it comes to the framework. Because I know there's alternatives like Hanami, and Django, and stuff. But, like, what has set apart Rails that makes it that more important to use Ruby? MIKE: There's always some advantage in numbers. So if you go with the more popular one, you're going to get all of the libraries available to use. You search on Stack Overflow, you're going to get your answers more easily than if you go out in another direction. On the flip side, if you have some strong architectural opinion, if you really disagree with some things that Rails is doing, then there are some alternative platforms out there. And, a lot of times, you can even use some of the Rails stack. You can use ActiveRecord today, which is a powerful part of Rails, maybe the reason that they got adopted. And then you can still use that useful tool and put another stack on top of it. It may be more power to you, you know if that's something you really care about. It's going to be harder to find developers. It's going to be harder to find answers. You're kind of venturing off on your own. You're going off-road there, right? [laughs] But if that's something that you're comfortable with, then you can kind of become the vanguard, maybe even develop a following. It's a little riskier way to go. I might also say that Rails has some opinions that differ from the majority, particularly some of the decisions they've made recently around JavaScript. If you disagree with those opinions, then you might want to use something else so you have a tool that better aligns with the way you see the world. MATT: I think that's a fair statement. We need to use the right tools for the job, and there are, I mean, there are so many options out there. MIKE: There are. Rails still is the heavyweight in the Ruby community. If you want to stay in a language that's similar, you can always go with one of the Python frameworks. And they range from heavier like Django to some lighter-weight frameworks, Flask. Ruby has the same things as well. There's a popular lightweight framework called Sinatra, as well as some others. And I've written a Sinatra app before. And it was extremely successful. It was also an extremely small application, something that would work out well, probably in a lot of frameworks, something that might actually be a good fit for the JavaScript server-side, if that's the way you'd want to go. MATT: Yeah. And there's been...Padrino is another option. And I think we've been talking a lot about Python. But things like Elixir, I think, are an easy transition as well if you want to go the functional route. MIKE: Right. A lot of people get sold on the functional route. [laughs] MATT: It's true. MIKE: So, we've talked a bit about some good things about Ruby, some of the history, some reasons you might want to use it, as well as some places you might not want to use it. You might not want to use it [laughs] for doing any real heavy lifting on, you know, with file system or heavy CPU. You might not want to use it if that's not what the other people in your company are using. But if you want to get up a quick prototype, I think it's really hard to beat Ruby as a language and Rails as a stack or one of its competitors because it's just so easy to get started. And I'm happy to still be using it, although I do use other tools as well. KYLE: One thing that I got thinking about was the community around Ruby, or maybe just the atmosphere. And I'm speaking to this from having worked with different languages different developers as well. And both points of view, I have to say that I don't know if it's just a mentality in the community or what it happens to be. But some of the more friendly, easy-going folks that I've ever worked with have been Ruby devs, as well having to dabble in and troubleshoot Ruby issues. The extended community, be it on Stack Overflow or other forums and stuff like that...not that other languages don't have this too, but whenever there's assistance needed in the Ruby community, it seems to be very respectful and very helpful, which I don't always see in other languages. MATT: That's a really great point. I didn't even think about that, but I agree. The culture is a bit different for Ruby shops than, you know, some of the others, say, here's the extreme, say, like, a .NET shop, right? It just feels like Ruby shops have a tendency to keep that startup mentality, even as they scale. And Acima is a great example of that. We have such a great culture at this company, and you just don't find that so much in some of the more structured Microsoft-type companies. So that was a very, very good point. MIKE: There's an acronym that's used in the Ruby community we were talking about a little bit before we started our recording (MINASWAN); Matz is nice, so we are nice. Matz is the creator of Ruby. I don't know if it's a mantra, but it certainly is saying in a community that we should be nice like Ruby's creator. And I've definitely found that to be a case, in general, and found a very welcoming, caring community among Rubyists, which is great. And that's maybe a great place to close our session. Hopefully, this is useful to you if you're considering [laughs] whether to use Ruby for your next project. Thank you everybody who's been participating today: Matt, Eddy, Kyle, and Ramses. And thank you for listening to our session of the Acima Development Podcast. I'll catch you next time.
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! Transcript: MIKE: 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? EDDY: 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. MIKE: Great. Dave. DAVE: 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. MIKE: Ramses. RAMSES: 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. MIKE: And Damon. DAMON: 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. MIKE: 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. What 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. And 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. He 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? If 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. Or, 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. So 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?" DAVE: 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. MIKE: [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. DAMON: Definitely not. MIKE: 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. And 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. Rails 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. I'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? So, 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. DAVE: 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. Rails 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. And 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. Rails 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. I'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. But 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. MIKE: 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. DAVE: Right, because it's the user who cancels their subscription. MIKE: 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. You'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. Well, 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. DAVE: 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. I 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. But 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." And 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. And 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. MIKE: 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. RAMSES: Yeah, it's complete now. But it was four or five weeks' worth of refactoring custom REST methods into more resourceful actions. MIKE: What was it like when you had that realization? Like, wait, these are all just things. RAMSES: 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. MIKE: 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? RAMSES: 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. MIKE: 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. You 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. And 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. And 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. Like, 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. I'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. DAVE: 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. And 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. A 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. My 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. But 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. But 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. And 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. MIKE: 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. DAVE: 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. Ooh, 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. MIKE: 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] And 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. And 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? DAVE: It's almost like the web code, and the background job code are means of accessing the business logic, which should be somewhere else. MIKE: That's called -- DAVE: Sorry, I didn't mean to run straight ahead in the direction you were pointing so hard, but that's what just happened. [laughs] MIKE: 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? In 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. One 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. But 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. But 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. That 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. So 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? Damon, 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? EDDY: 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. MIKE: 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? DAMON: 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. MIKE: 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. DAMON: [laughs] MIKE: 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. DAMON: Oh yeah, for sure. EDDY: Until you run into legacy code. MIKE: 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] And 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. I 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. EDDY: 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. MIKE: 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. Dave, 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. DAVE: 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. The 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. A 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. You 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. And 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. So 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. But 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. The 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. MIKE: 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. So 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. DAVE: 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. Maybe 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. MIKE: 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. DAVE: 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. MIKE: 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. DAVE: What was the question? Mm-hmm. MIKE: 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. DAVE: 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. MIKE: [laughs] DAVE: 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. MIKE: 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. Those 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. DAVE: 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. It'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. MIKE: Any other final words from others on the call? DAMON: Only that you guys explained this really well, and it's super helpful. So I appreciate it. MIKE: 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.
A discussion about what software developers actually do and the skills required to be successful. Transcript: MIKE: 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? SAM: 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. MIKE: 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? DAMON: 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. MIKE: Right. Thank you. Dave, do you want to introduce yourself? DAMON: 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. MIKE: 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. I 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. And 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. If 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. There 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. The 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] SAM: Only a little. MIKE: Yeah, exactly. [laughs] You're talking about a field that is so vast, that is changing so quickly, day to day. DAVE: And so young. MIKE: And so young. DAVE: 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. MIKE: [laughs] DAVE: 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. MIKE: 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. I 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. Acknowledgment 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. I 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. My 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. And 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. I 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. DAVE: 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. It'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. And 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. I 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. And 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. MIKE: 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. Basically, 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. DAVE: Yeah. You can't integrate five different people's ideas if you don't go hang out with five other people. MIKE: Absolutely. Absolutely. DAMON: 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? MIKE: 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. And 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. There 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. The 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. DAVE: 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. MIKE: [laughs] DAVE: 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. And 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." And 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. And 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. He 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. MIKE: 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. And 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." DAVE: [laughs] I cleaned it up, and I made it work while I was doing it. MIKE: 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. DAVE: 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. We 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. So 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. Real 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. So 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. MIKE: 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. DAMON: 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. ¬ SAM: 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. And 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." And 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." And 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." He 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. There 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. But 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. MIKE: 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. And 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. And 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. DAVE: 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. If 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. If 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. Anytime 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. And 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. And 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. Everything 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. Like, 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] If 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." So 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. I 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. And 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. I 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? How 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? DAMON: 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. And 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." With 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. MIKE: Imposter Syndrome biting you. It's a plague. DAVE: 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. I 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. I 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. Ironically, 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. The 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. And 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. MIKE: Well put. Sam, how do you see software development? SAM: 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. And 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. MIKE: 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. And 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. DAMON: Yeah, that's awesome. Thanks, guys. MIKE: 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? SAM: 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. DAMON: 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. DAVE: 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. Also, 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. There 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. Sam 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. MIKE: 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 -- DAVE: 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? MIKE: 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. If 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. Thank you, everybody. This was a great session. I look forward to talking to you next time.
Today, we have a conversation about what the relationship should be between QA, testing engineers, and development engineers. Transcript: MIKE: 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. And 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. I 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? GUILLERMO: 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. MIKE: 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? JARED: 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. MIKE: Great. Eddy. EDDY: 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. MIKE: David. DAVID: 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. MIKE: Great. Thank you. Diane. DIANE: 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. MIKE: Oh, that's great. Ramses. RAMSES: 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. MIKE: 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? ZSOLT: 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. MIKE: Great, yeah. We love having you on the team. Afton. AFTON: 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] MIKE: Great. Melissa. MELISSA: 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. MIKE: Great. Josh. JOSH: 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. So 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. MIKE: Great. And you probably have some interesting perspective there of seeing things not work so well. JOSH: I obviously don't focus on those. But yeah, obviously, there's group dynamics and all that. It's very interesting to me. MIKE: Thank you. James, do you want to introduce yourself? JAMES: 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. MIKE: Thank you. And finally, Brian, want to introduce yourself? BRIAN: 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. MIKE: 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. I 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. And 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. And 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. But 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. Went 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. That 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. But 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. With 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. JARED: 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. And 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. JOSH: 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. We 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. MIKE: 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? JOSH: I think short term maybe like from a PR to PR basis, but long term it sees more consequences. DAVID: 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." And 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] MIKE: 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. And 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. And 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. AFTON: 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. It 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. GUILLERMO: 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. JOSH: 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. Those 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. That 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. EDDY: 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. I 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. JARED: 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. And 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." I 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. JAMES: 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. And 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. And 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. BRIAN: 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. But 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? JAMES: 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 -- BRIAN: I don't remember at all. [laughs] JAMES: 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. MELISSA: 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. JAMES: 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. BRIAN: 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. EDDY: 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. But 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. MIKE: 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. Google 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. Because 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. I 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. I 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. DIANE: 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. JAMES: 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. MIKE: 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. BRIAN: 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. MIKE: 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. Again, 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. Maybe 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. I 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. What 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? JARED: 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. Because 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. EDDY: 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. I 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. MELISSA: 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. EDDY: 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. So 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. AFTON: 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. And 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. MIKE: 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. As 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. And 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. Just 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? ZSOLT: 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. MIKE: 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. Team, 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. What 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? DAVID: 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. And 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. So 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. MIKE: Thank you. Any other thoughts on that topic, about that open-communication channel? JOSH: 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. MIKE: Yes. JOSH: 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. So 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. MIKE: I think there's a lot of truth to what you said there. It's hard to detangle all the threads there, right? JOSH. [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. But 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. MIKE: I think it has to be supported from the top. You have to have leadership that cares. JOSH: Yes. You have to have buy-in, yeah, for sure That's a great point. MIKE: 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. JOSH: 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? JAMES: 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? And 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? It 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. [laughter] JOSH: Can't go wrong with free snacks. MIKE: 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. But 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. JOSH: 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. And 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. MIKE: Well, and it is important that when you are looking to get hired that you're interviewing the company as well. JOSH: True. MIKE: 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. We'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. And 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.
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. Transcript: MIKE: 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? AFTON: Yeah. I'm Afton. I've been developing for four and a half years professionally: about. Happy to be here. MIKE: Ramses, would you like to introduce yourself? RAMSES: Hi. I'm Ramses. I've been developing for a little bit about a year now, professionally, for just a couple of weeks. MIKE: 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. Today 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. We'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? AFTON: 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. And 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. MIKE: Ramses, you just started as a full-time developer in the last couple of weeks. How are you feeling? RAMSES: 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. MIKE: 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. I'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? AFTON: 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. So 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. MIKE: 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. And 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. AFTON: 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] MIKE: You also said something interesting before. When you described the job, you didn't say the word code. That was dead on. AFTON: [laughs] MIKE: We're here to solve problems, and that's it, right? AFTON: Yeah. MIKE: 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. AFTON: [laughs] MIKE: We're just sticking a couple of things together already there, and, hey, it already works, and everybody's happy. AFTON: 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] MIKE: Well, and you've been around long enough; how do people feel when they get to delete code? AFTON: 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. [laughter] MIKE: 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. And 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. I'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. But 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. AFTON: [laughs] MIKE: 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? AFTON: 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? Because 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. I 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. So 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. If 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. MIKE: 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. So 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. And 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. I 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. AFTON: [laughs] MIKE: 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. AFTON: [laughs] Yeah, absolutely. MIKE: [laughs] It's amazing to have that moment. That moment is deserved. It's earned. And nobody should be able to take that away. I 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. When 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. When 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. But 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. AFTON: 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] And 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. Progress 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. I 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. MIKE: 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. Our 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. AFTON: 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." And 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. And 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. MIKE: How many times do you think you go to Google every day if you were to average? AFTON: 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] MIKE: 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. The 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. But 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. I 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. AFTON: 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." So 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. And 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. So 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] MIKE: 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. Microsoft 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. And 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. AFTON: 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. If 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. MIKE: 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. But 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. AFTON: Right. And then next time, they'll find it for themselves again. [laughs] MIKE: Exactly. AFTON: Or they'll know how to get the answer. MIKE: Yeah, teach a woman or a man to fish, and they can do that thereafter. AFTON: 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. And 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] MIKE: 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. AFTON: Critical, I would say. MIKE: 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. If 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? AFTON: 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. MIKE: 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. And 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. They'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. I'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. AFTON: 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. And 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." And 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. MIKE: 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. And 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. And 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. We 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? AFTON: 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. And, 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. MIKE: Thank you, Afton. And with that, we'll see you next time.
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. Transcript: DAVID 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. SWAPNIL: Hello. DAVID BRADY: Welcome. We have Brian Parry. BRIAN: Hello, gang. DAVID BRADY: Welcome, welcome. We have David Solano. DAVID SOLANO: Hey, I'm glad to be here. DAVID BRADY: Welcome. We have Adam Lauper. ADAM: Hello from South Jordan. DAVID BRADY: Howdy. We have Afton Call. AFTON: Hello from Cottonwood Heights. DAVID BRADY: And last but certainly not least, we have Tad Thorley. TAD: Hey, welcome. Glad to be here. DAVID 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. ADAM: 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. DAVID 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. AFTON: 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. DAVID BRADY: Ooh. AFTON: You could have done your computer science later and still had a different college degree. DAVID BRADY: That's a fantastic -- TAD: I know a lot of developers who got degrees outside of the field of computer science who are excellent programmers. DAVID BRADY: Yeah, thank you for pointing that out. TAD: 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. AFTON: 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. DAVID 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. I 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. And 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. SWAPNIL: I would like to share my experience. DAVID BRADY: Please. SWAPNIL: 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. DAVID BRADY: Mm-hmm. Yap. SWAPNIL: 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. So 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. DAVID 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. And 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. So 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? SWAPNIL: 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. DAVID 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? SREYA: Yeah, Bhatt. DAVID 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? And 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? SREYA: 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. DAVID BRADY: Awesome. DAVID 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? DAVID BRADY: Mm-hmm. DAVID 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. DAVID 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. And 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. But 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. ADAM: 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." And 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. DAVID 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. ADAM: Huh. DAVID 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. And 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. And 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. Well, 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. I 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. But 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? ADAM: 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. BRIAN: 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. At 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. DAVID 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. So 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?" I 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. But 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. It 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. ADAM: 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. With 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. I 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. So 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. They'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. DAVID 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. And 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. And 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. MIKE: 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. DAVID 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? And 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. But 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. AFTON: 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. For 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. And 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. DAVID 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? AFTON: 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. DAVID 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. The 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. But 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] MIKE: 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. What 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. DAVID BRADY: Yeah, that's the bad kind of plagiarism, yeah. MIKE: 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. DAVID 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? TAD: 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. DAVID BRADY: [laughs] TAD: 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. DAVID 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. TL;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. They 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? DAVID SOLANO: Was that because they didn't know how radiation worked? DAVID 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. And 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? AFTON: 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." DAVID BRADY: Yes. AFTON: There you go. [laughs] TAD: 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. So 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. And 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. DAVID 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... I 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? TAD: 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. AFTON: 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. MIKE: Very much so. You're here. DAVID 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. I 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? SWAPNIL: 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. DAVID 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. SREYA: I think we learn a lot when we start working in a real-world environment rather than learning in university. DAVID 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. And 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. DAVID 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. I 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? But 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. I 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. What 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? MIKE: 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. My 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. DAVID 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. And 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. And 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. I 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] AFTON: 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. DAVID 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. I 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.