Acima Development

In this episode, we talk about remote work vs. being in the office. Pros and cons! Ups and downs!

Transcript:

DAVE: Hello. Welcome and good morning to the Acima Development Podcast. We are going to talk today about remote versus in-office work, and that's going to be kind of exciting. I'm your host, Dave Brady. I've been programming at Acima for a little over a year. And I started out on the Atlas web dev team building the website that the merchants use, and now I'm over on the data engineering team. And it's a lot of fun. Today on the panel, we have Eric Martinez.

ERIC: Hello, Hello. Eric Martinez, Product Manager. I've been at Acima for one year, and I'm excited to engage in this conversation with you all.

DAVE: Awesome. We also have David Solano.

DAVID: Hey, guys. I've been here in Acima for one year too, and I'm a developer.

DAVE: Right on. David, where are you from?

DAVID: Costa Rica. [laughs]

DAVE: Costa Rica.

DAVID: Ya.

DAVE: We want everybody to know that we're not all in the middle of Utah. So it's kind of nice. Speaking of people that are not in the middle of Utah, we also have today Marcos Yu.

MARCOS: Yeah. Hi. I'm a new developer in Acima.

DAVE: Welcome. Where are you from, Marcos?

MARCOS: I am from the Philippines.

DAVE: Awesome. Welcome. We also have Ramses Bateman.

RAMSES: Hello, hello. I am from Utah. Full-time developer for about six months now.

DAVE: Right on. And, you know, if the Philippines and Costa Rica wasn't far enough away, we also have Aniket Tiwari.

ANIKET: Hi, everyone. I'm a contract developer, and I'm currently working from India.

DAVE: Right on. Welcome. So we have people from pretty much every time zone. Well, I mean, not literally every timezone; we'd need 24 people here. But yeah, we've got pretty good global coverage, which is actually a pretty good introduction to the topic today, which is the benefits and trade-offs to remote work versus in-office work. I kind of want to just kick things off with a question, which is just to ask everybody on the team or everybody here on the panel what's your opinion? What do you think, bad idea, good idea?

DAVID: Well, I've been in both scenarios. Right now, for Acima, I work remotely. But I think right from my side; I like to be at home working or busy working from a different location. It has its benefits, but I think that it also...sometimes you miss to see people just kind of networking or contact with others stuck around the office. So I think both sides have pros and cons.

DAVE: 100% agreed.

ERIC: There is an argument to both, right? Work remotely versus coming into the office, and I think a lot of the national conversation regarding this topic has intensified because during the pandemic, obviously, working remotely was a thing because we couldn't gather. And I think a lot of benefits came out of that, good and bad. You have a segment of the population who probably it took a mental toll working remotely and not being able to connect with their peers at the office, not being able to have those connections with people outside of your home environment.

Then you have people who reported they were more productive. And then they started to see like, hey, I don't have to go to the office. [laughs] I don't have to get up at 5:30 in the morning, try to get a peloton ride, shower, and take the kids to school, then drive 20 to 30 minutes to the office, and then drive back. So it became more efficient for those individuals.

And then you have someone like me where...so when the pandemic happened, I was kind of doing some contract work, you know, there were some jobs. And when I came to Acima, it was kind of towards the tail end of the pandemic, but I think that we were still kind of starting from...a lot of companies had shifted to completely working remotely. And this is where I felt like in order to start a job; I think it will be really, really hard to start remotely. Now, that's my opinion based on my experience.

I don't know. Maybe there are others here in the panel that might share a similar feeling. For the type of role that I have...so I partner with a team of engineers who manage a lot of the financial transactions and all the systems that manage all that money when you send it out with accounting. And a lot of my job for me to be successful is, I need to have personal relationships with accounting, with lots of people that I would have found a little bit hard to do remotely in a fully remote environment.

Is there a straight answer? I think I'm kind of standing in the middle of the line with one foot on one side and one foot on the other. But now that I have built those relationships, I'm starting to like, hey, I want to work from home, maybe a hybrid model where I don't have to come into the office as much where I have built those personal relationships that now I can work with individuals remotely, right?

DAVE: You actually make some really, really good points. I love this; can you start a job if you're 100% remote? We have some people on the team that did not come into the office [laughs] to get started, right? Aniket, David, Marcos. Like, how did you get started at this gig? How did you get started at previous gigs where you were 100% remote? Have you ever had jobs where you go in for the beginning and then roll out, or do you...oh, wow, my boss just joined the podcast. Welcome, Zach.

ZACH: Hey, how's it going?

DAVE: Are you here to join the podcast, or are you here to tell me to get back to work?

ZACH: Join the podcast. I've been meaning to do it for a while.

DAVE: Oh, thank goodness. Thank goodness. So awesome. Zach, you are the...what do you do here?

ZACH: My official title is Senior Data Service Manager managing the data services team.

DAVE: Nice. So that would make me a senior data service.

ZACH: Senior data engineer, I believe.

DAVE: Just, I mean, you are the senior data service manager. So if I'm a senior engineer, then you don't manage me, cool. I'm sure you'll set me straight later. Today we're talking about remote work versus in-office work. And Eric just raised a really good question of can you be 100% remote? And we've got three people; we've got a Costa Rican, a Filipino, and an Indian on the podcast today. And those are all 10-hour flights or more. I wanted to throw out to you guys, David, Marcos, Aniket, what is it like getting started in a job where you're 100% remote?

MARCOS: Maybe I can share my experience around 2015.

DAVE: Sure.

MARCOS: So this is not actually my first time working remotely. So I was working under a UK client. So the time zone that I work with is very different, so that was a very different experience for me, for instance. So this happened way, way before the pandemic, so I was pretty happy back then, the productivity surge because I don't need to commute and stuff. And also, I feel that I'm accomplishing many things on a day-to-day basis because I feel that I could work six hours straight rather than at the office that I need to consider the traffic to go home to my family, so everything was good.

But then it was also my worst working experience. That's when I learned the importance of communication, especially with working remotely. While working in the company, there was no feedback loop in terms of the work quality that I'd been delivering and stuff. In my head, at that time, during those two years, I'd been doing great. I've been contributing well because I have this bunch of code that I've been pushing on our codebase, and it gets deployed.

Then one day, they told me that they're going to stop working with me because the project is almost ending and stuff. So I was the first one to have been let go. I can understand the situation back then that it is kind of like a project basis and stuff. While looking for a job at that stage, that's when I noticed that my skills haven't grown for the two years, maybe because...I could factor in the lack of communication with my teammates also. You're not able to check the code quality that you're delivering and stuff.

I would agree with the sentiment earlier that it works both ways. Yeah, you're being productive and stuff. Still, you need to communicate with your client and your peers. That's one of the most important points because that will show you where you are currently and if not, you might get lost working alone by yourself.

DAVID: When I started working as a developer, I didn't have work from home, so I needed to travel two hours from my house to work. And from time to time, I could ask like, "Hey, can I work from home this day?" I need maybe to go to the doctor at the end of the day, and it's easy for me to go after job and be here in the house. Then I switched to another place, and I'd go two days, and that was a big change for me. I could rest a little bit longer. I could still network with the guys, with my partners, and that was great.

And then, I switched to another place. And I was in a project where they weren't used to having work-from-home people. But I was completely remote because I was here in Costa Rica. And this client and this project was from the U.S., so it was extremely hard because they were not used to having tools to communicate better. Slack was something that they were barely using.

And even though you tried to communicate with them, the team was not like in that way of facilitating everything for the remote guys. And I was not the only one. So it came to one point when they decided that they couldn't work with people working remotely. So they started to finish contracts because it was not working for them.

Then I switched to another one where remote work was the thing. No one was at the office. Actually, there was no office. And it was pretty fun because they encouraged communication. It's easy for everyone. And then I joined here at Acima, and I think it's kind of both scenarios when you can go to the office; some people love to go to the office.

But for us that are working remotely from a totally different country, it's just awesome because here in Acima, the communication is just great. If have questions, you ask, and you get answers. If you have problems with the things that you are doing, you can pair program with your co-workers. And that is great because everyone here is willing to help you. So I think this is just amazing. For me, this has been the best experience of all time working remotely because I think Acima is just prepared for remote work.

DAVE: I love how you talked about the existence of communication channels. I had forgotten this, but you're absolutely right; I've had that experience where eight of the people on the team were in the office, and two of us were remote. And we absolutely got starved for information because the team that was in the office all their communication channels were implicit, locally-convenient channels.

It's like they would go stand by each other's desk, or they would go hang out at the ping pong table or play foosball or whatever, or they would go eat in the lunch room together. And if you're outside, it's really hard to force your way into that communication circle, and it's actually seen as an annoyance or an intrusion. [laughs]

There was a team that I was on, and we had really good remote communication. And so at one point, we actually started doing telepresence where I would literally come in the morning, and I would jump into...it wasn't Skype but before Zoom existed, but it was one of those get on and do a video call. And in the office, they had a spare machine. So they could just turn that machine on, put my face on that screen, and then they could carry me around like a little disembodied head around the office.

It sounds really cool, but in practice, it's kind of, eh, it wasn't great. All the people that are like, "This is not a good idea," they turned out to be right. But the hallmark, worst moment with that came when a couple of people on my team went to do a special side project with another local team that was entirely local. And I wanted to join with as well, so I'm like, cool, yeah.

So I had them take the telepresence laptop into the conference room where this other team was working. And they sat me down at the end of the table facing down the table, and it was pretty good. And immediately, nobody talked to me because the laptop the sound isn't that great. And I'm getting 12 people's audio slamming into me and that sort of thing. And I kind of got quiet, and I just started listening to everybody, and they started ignoring me.

And at one point, somebody bumped the laptop and turned it like 90 degrees, 120 degrees, so I'm staring into a wall. And I'm like, "Guys, hey. Guys, hello? [laughs] Can somebody turn me around?" And either nobody could hear me or nobody cared. And after 10 minutes of waiting to see if somebody would notice that my laptop was turned around and nobody doing it, I'm finally like, eh, fine, I'll just drop out. And I ended up not doing the rest of that special team project because I literally could not force my way into the communication channel.

DAVID: I was in that position a long time ago, same scenario. It was a webcam. The whole team was in the office. I was remote. And if you talk to them, they were not paying attention. So I decided to drop off, and no one even noticed. [laughs]

DAVE: Yeah. That was the same experience I had. I dropped out of the thing. And I had to go find somebody and tell them, "Hey, you might want to get the telepresence laptop out of the conference room." And they're like, "Oh, is it still there?" I'm like, "Yeah, it's still there. [laughs] It's still pointed at the wall."

DAVID: Yeah. And I've been in the other scenario where they don't have webcams with laptops and all that, but they just have this speaker.

DAVE: Oh, like a conference call, yeah.

DAVID: Right. And it's fine because sometimes, if there's someone who is able to facilitate how the conversation is going, it's easy for the one that is remote. And I actually like that he asked questions, "Hey, David, what do you think about this?" And so everyone listens, and everyone keeps silent and listens to what you have to say. And this enables you to participate in the, even now, in the meeting that is happening right now. But yeah, I think it depends on how the team is behaving at that moment. There's someone who facilitates that kind of communication too.

DAVE: You've touched on an idea that I've tried to communicate for a while now about remote work, which is that for remote workers, there's no communication channel for...I call them priority four communications. So, like, priority three work is work that is in the backlog, and you do it when you can get to it. Priority 2 work is work that's at the top of the backlog, and you need to work on that right away.

And then priority 1 is stuff where they're like, "Don't go home until this is done." It's like we have to have this in place by tomorrow. There's also priority 0, which is don't go to the bathroom until this works. The server's down, and we're losing $100,000 a minute. You don't have time to go potty.

But priority 4 is communication that is not strictly necessary. Like, if somebody came in and said, "Hey, keep it down and get back to work," you would probably be having priority four communication. And to be clear, I'm not talking about socialization or talking about the ball game last night, or any of that. I'm talking about actual work discussions. I'm talking about the thing where somebody sits down and says, "So, how come we don't use SQL Server instead of this other data lake product?"

And the other person in the room can go, "Hmmm, yeah, the CFO hates SQL Server." That's not going to be in the prospectus for the company. That's not an official doctrine. That's not something somebody wants to commit to in an email to tell you. But it is nonetheless a guiding factor for the entire company. So if you're like a database guy and you really, really love SQL Server, then you need to be aware that this is never going to fly here. You're going to have to do this. And that's what I call a priority four communication.

And what I've noticed is that...oh, the other way you can define a P4 is it's something that if you had a question, you would never write an email to your team starting with, "What do you think is the best way to...?" You would never write this email, right? It's like, "What do you guys think is the best way to store data? What do you guys think is the best web framework?" The company already has a web framework. We already have a data storage solution. We already have networking vendors. But these are communications that, as a team, you need to have.

And what you said was really, really important, David, that if there's a facilitator on the call to say, "David, what do you think about this?" They can drive a wedge into the conversation and create space for you to float into the conversation. But it's really hard. Without that facilitator; there's almost no way for you to engage in P4s. Nobody's going to sit down and say, "Oh, by the way, everybody knows that the CFO hates SQL Server." Nobody's going to start that conversation with you. But it's an important conversation.

These are things that I call the lore of a project, the lore of a team, or the lore of a company, things that are not written down anywhere, and they're not official records, but nonetheless, they are very strong guiding rules to how the company is run. And I don't have a solution for that yet. But I think as we see more and more teams move to 100% remote, I think we're going to have to tackle this. I think we're going to have to find ways to get people rubbing elbows virtually, if not physically so that these communications can take place because I think they're actually pretty important.

MARCOS: I kinda like what Atlas team does before their meeting. They set a time in the beginning of a meeting where people could talk about anything under the sun, let's say. So that's something that might come up or something that someone could share.

DAVE: I like that. I've walked in on many conversations on the Atlas team and people who had been in there early...and people are talking about their kids. They're talking about their hobbies. They're talking about what they did over the weekend. And that's a lot of fun to walk in on that and to basically have human beings that I'm hanging out with that I don't have to get anything done with, and it's really nice.

There's a...ooh, don't quote me on this. They call it the FROG mechanic. If you need to communicate with somebody socially and you're socially awkward like I am, so, I mean, I literally had to Google how to make small talk with people. And the acronym that they give is FROG, F-R-O-G. If you can't think of anything to make small talk about, use the FROG acronym. You can talk about their family, their recreation, their...I can't remember what O is...occupation, which I mean with co-workers, is obviously...and I can't remember what G is...goals maybe, I can't remember.

But these are like safe topics that you can bring up with pretty much any stranger, like at a cocktail party or the equivalent. Yeah, walking in on a conversation where they're talking about FROG is awesome because you know that you can jump in and be part of the team and discuss. Eric...and oh, and Eddy Lopez has joined the call. Welcome, Eddy. I see some hands up on the call.

ERIC: Yeah. So I'm happy to hear that those conversations are happening with engineers, especially on the Atlas team. And I'm not surprised that those conversations are happening there. You know, obviously, I work with the Founding Fathers' team. When I first started working with them, that team, this is how I describe those guys; they will never kill a fly, but they're very intimidating [laughs] at the same time, very smart individuals, very straight to the point, very senior developers.

And I do remember those first conversations. They were kind of awkward. I was trying to figure out the balance between, like, all right, here are things that we need to focus on. Here are things that I'm looking at you guys for directions. But going back to the point to, you know, working remotely versus working from office, so two members of that team are local here, and I remember having conversations outside of work, topic-related things helped build rapport, and then eventually build some trust in terms of projects, when we worked on projects. We have another team member who's based in Texas.

One thing about me that I think some of you guys know is I love to travel, and I like to find any excuse to go any place, from going to Panguitch, Utah to Russia, [laughs] any excuse that I can find to go somewhere. So Tyler Hall...and I think a lot of you guys know, he prepared for a year mentally, physically to do...what was it? MMA fighting. And I went to...a pretty cool story about how he started and his journey of preparation.

So I went to his fight. And even though I've only met Tyler once, when I went to the fight, personally, I feel like we have built a long-time relationship if our professional careers take us to different places; same with Adrian and Jordan, Matthew is in Virginia. And during our meetings, we do set some time to kind of shoot the breeze a little bit because that replaces something that happens naturally at an office workspace.

Earlier, you mentioned the cooler water cooler. You have those small conversations that really do have an impact on work relationships, on personal relationships that are missing when you start fully working remotely. So I'm kind of happy that Marcos and David that you guys have found ways to kind of replace that in a remote environment to continue to have those connections, even though we're not physically present in the room, because I think that is one of the many factors that makes a successful team anywhere.

DAVE: That's awesome. Thank you.

EDDY: This is something that's been on my mind for the past few months. And this question is more catered to people that have experience in working remote and in office. The question is like, how would you compare Acima's productivity as the company embraces remote work? Is Acima more or less productive in comparison to other companies that you worked for that don't have remote work?

ERIC: I feel like Acima has been, in my experience, one of the companies that has been...we are more efficient. David, what would you say the percentage of all engineers that Acima employees are remote?

DAVE: On the average team, it's close to 100%.

ERIC: Yeah, I was going to say I'm like, it's going to be pretty high because -- [laughs]

DAVE: It's pretty high. Zach, are we...on the data team, are we 100% remote? I mean, I know you go into the office about one day a week. I, about every other week or every third week, will come in for a day.

ZACH: We're mostly remote. Kenton likes to be in office. So he's probably in the office the most.

DAVE: That's an interesting take, though. It's like we're not requiring people to come in. But we have desks with computers and comfy chairs and sit standard electric desks so that if you do come in, you've got a nice place to sit and work. It's not like you have to come in and sit on a folding chair in a conference room and hate the environment.

ERIC: The environment, yeah. Going back to you, Eddy, which, by the way, I miss seeing your face in the office. Whenever you come to the office, it brightens my day.

EDDY: Aw-shucks.

ERIC: [laughs] I would say that yes, in my experience, we are a pretty well-oiled machine, if you will if you allow me to use that metaphor. We get things done. We don't have to be all crammed in one room office space to get things done. And I think we have proven that. I mean, Atlas, how many engineers do you guys have? 20? I've lost count. They're a pretty big team. And they are a team that, without that team, we wouldn't have Acima and, of course, not to diss on other teams, right? All of the teams that we have are very integral to the success of Acima.

And I think our success is because of you guys, engineering. We're very efficient now. That is my experience from other companies that I have worked with. And I wouldn't necessarily say it is the environment, whether you're working remotely or from home. I also think that it is the people that work for Acima are very good at what they do, and they're very competent individuals. That's also a key aspect that makes this company efficient and successful.

DAVE: I have a question that I want to throw out. I want to kind of address the billionaire elephant in the room, which is a couple of months ago, Elon Musk bought Twitter. He made the news last week by going and addressing the employees of Twitter and saying, "You need to get back to the office." And a lot of people were saying, "Why?" I'm more productive at home. I can write a line of code, and then if my kid wants to walk around the block, I can go do that with my kid. I can't do that when I'm at the office." Elon's response was that...he phrased it very interestingly.

He said you need to have...I'm not quoting, but he said something along the lines of you need to have a mindset of collaborating for innovation. And he definitely phrased it in a way that he was; basically, I think, addressing this kind of communication scarcity that happens with remote that if we don't have people together in the same room, we miss out on the breeder reactor reaction of having everybody in close proximity where they can bounce ideas off of each other at an increasingly high frequency. And he phrased this in very strong terms, like, I, as your employer, I don't get that benefit if you're not in the office. And I'm very curious to see, especially if --

ERIC: He's just a control freak. That's all it is.

DAVE: Yeah, I mean --

ERIC: [laughs] That's all it is.

DAVE: I've worked with a couple of...that's where I was going to go next. I've worked for a couple of CEOs that didn't like remote work, and they both used the word vibe. They're like, "Oh, I like the vibe when people are in the office." And I'm like, you know, is there --

ERIC: That's translation, for I like to control you and making people come into the office. It's like, where are we? In kindergarten? Do we not have that trust? Do we not have that trust in our people? And I think this is something that...culture here, right? There is trust all around. And you guys are engineers, and we're able to deliver things. And we're able to ideate from people who work remotely. We're able to do things. And I just think Elon Musk was, you know, he's just a control freak. [laughs]

MARCOS: I think I could also argue with that statement. So let's say we have this scenario, right? There are people in the office, but they're all looking at their computers doing each of their own stuff. And let's say they're doing it also remotely. So we could probably say that they have no interaction altogether, right? So working remotely and working in an office doesn't have any difference at all.

So it boils down to the people and the culture that the company has. So it's not about the physical interaction. I mean, this is my personal opinion. It boils down to people and culture of the company rather than physical presence or the setup of your company or working remotely or working in office.

DAVE: Yeah. As you were saying that, I realized that there's a communication channel that is present or not a communication...I'm going to say communication channel, but what I mean is like it's almost like a nebulous like a psychological...we all have Slack. We all have instant message. We all have video calls. But we made a conscious decision. And we've set an example on the Atlas team to say, we're going to ask really dumb, low-priority questions or questions that you might think twice about asking or you might consider, oh, this question is noise.

And at the Atlas team, we ask those, and they get answered, and it's super beneficial. And the key example that I have cited over the years...and this is purely anecdotal from my experience. I love remote work, but I step back, and I say, "Well, are there advantages to working in the office?"

And I've had the experience of working with a pair programmer, and we're talking about, okay, we got to run this. We got to get this test working. And all of a sudden, the database goes away and stops working. And we're like, wait a minute, why can't we connect to the database anymore? Something in the connection pool. Wait, we don't use a connection pool.

And because I'm talking with my pair and I'm talking with them out loud, the pair programming team sitting right next to us heard us and turned and said, "Oh, you guys, we just pushed up a connection pooling thing. You just need to pull and synchronize. And then you just need to touch this file, and you'll be good to go." And we immediately got up and running. And that could have sidelined if we were remote and none of that was overheard. That could have sidelined us for a long time.

And I've had that experience as well where I've been sidelined by something nitpicky and stupid that somebody did and then didn't tell everybody else on the team. I think Atlas has done a really good job of addressing that by having one of the team channels be a place where it's absolutely...we have like a company-wide channel for our team where anybody can come and go that wants to have interaction with our team.

But the Atlas team, in particular, had a private engineering channel that they could go into. And that was a place where you could just go, "Oh my gosh, I'm getting this error message. Does anybody know anything about this?" And you get kind of that same feedback where another person on the team will say, "Oh, yeah, I did that to you, sorry."

The nice thing is that they will usually follow that with a link in the Slack channel to the conversation that they kicked off four hours ago or in the middle of the night last night or two days ago, depending on how long you've been out of sync with the repo. They'll come back and say, "Here's the conversation where I said this. These are the steps that you need to do to correct this." That's something you can't do at the water cooler is you can't be in the middle of a conversation with somebody and then hand somebody a link to the conversation that was had at the water cooler three days ago. That's kind of a fun sidebar.

There are some efficiencies that you can leverage of remote work that I think we address the entire conversation around is remote work good enough to replace office work? And I think we overlook some things that remote work is very, very good at and very especially adapted to. So that's kind of a side tangent.

MARCOS: Yeah. And to add to that, I think you can encounter this many times. Like, there are some devs that ask a question, then there is someone that's going to reply to that thread. And he said that "Yes, I've been encountering that for many days," or something. And then there's going to be another dev which, "Oh, I introduced this some time ago." So if you could see that, there's that individuality of a developer that they do not tend to ask questions because not all developers are equal, so some ask questions, some don't. So they tend to just adjust to that scenario without asking.

So because of that channel, they could surface their question, or they could say, "Yeah, I also experienced that." So now that there's a commonality with that, we could actually address that since it's a common problem for all. So that's one thing that I noticed very differently in other companies and here in Acima is that collaboration is really a priority. Everybody has a ticket, right? Everybody's busy. But everyone always checks the message and sees, oh, someone is having trouble. And if they knew or something came up to mind, they're not afraid to just chat it there. So that encourages you also to ask questions rather than keep it to yourself.

DAVE: That's awesome. Thank you. I think there might still be some meat on this bone to talk through. But we're coming up close on our hour here for record time. Do we have any parting shots, any closing thoughts? I'm assuming everyone in the room is pro versus against remote work. Any other shots?

DAVID: I think this has been a great conversation. I just wanted to finish with something that just comes to my mind. If you're working remotely, remember that you also need to be open to feedback. I think that's important. If you want to grow up there and to find the way and the standard of the team, that's something you have to keep in mind.

DAVE: Yeah, that's a nice circling comment to what you said at the top of the call where the necessary feedback was lacking that you have to go...and what I'm saying is if you're remote, you have to go after that feedback sometimes so people that will just like, oh, well, if I don't talk about it, maybe the problem will go away and --

MARCOS: And maybe people will forget if you don't chase that feedback. [laughs]

DAVE: Yeah. And that feedback can be essential to keeping your job. So you can accidentally let some information go by that you absolutely need. And if you were in the office, you would just pick it up and absorb it because it's kind of in the air. And if you're remote, you have to go digging for it sometimes.

EDDY: I have a question for those who prefer to go in the office or aren't opposed to. How can you be productive when it's really easy to reach over someone's shoulder and start a conversation? I don't know about you guys, but everyone in Acima is really nice. And it's really easy to start a conversation. I'll go on record and say if I'm in the office, [laughs] it's hard to get more work done as opposed to when I'm at home.

DAVE: Yeah, that's a really fair point. We've been talking about the communication channels purely from the viewpoint of communication carries sideband information that's really, really valuable, and we lose that when we're remote. But the advantage of being remote is that you lose that communication channel. That communication channel doesn't come find you and distract you. Having peace and quiet and time to think is kind of nice working remote.

EDDY: Yeah, being secluded, for me anyways, I can be more productive. But I'm just curious to gauge other people's opinions.

MARCOS: I've been someone asking someone in the office for some help. So that actually, like request timing also, like, let's say, what if the person is busy? So that's one thing that I encounter most of the time in the office when I was working in the office. So that actually sometimes discourages you to ask someone a question.

So what I typically do is, even though I'm in the office, I just leave him a message. If that person is known to be like the busy guy, because there's always the busy guy that always stares at his computer, so I just leave him a message. So that kind of works the same way with working remotely. You can leave a message to the people and let them take their time to do the stuff that they need and just wait for them to reply.

DAVE: Yeah, that's actually a really good point that when you are in the office, it's very, very easy to have highly urgent conversations, not necessarily important conversation but urgent conversation. And when you are remote, it's much more easier to have asynchronous communication where you fire something off, and then you wait for a little while to get back.

And when you're remote, you can kind of get a little hamstrung where if you're like, "Hey, I need help with this," because you're down, right? It's like if your machine isn't working, you can't write software today until this gets fixed. You don't want to be in an asynchronous situation. You don't want to just like, oh, by the way, if anybody sees this sometime today or tomorrow, could you maybe get around it? No, it's like you need help right now, right? So it's kind of like urgent.

One of the things that I have lamented this multiple times in the past but one of the things you can't do when you're remote is you can't go stand at somebody's desk and just be silent and awkward until they give you what you want. I love that about working in the office. It's just being awkward at your desk until you make me go away. And you can make me go away by giving me what I want, which is nice.

ERIC: And it's more efficient. [laughs]

DAVE: Yeah.

EDDY: I'll tell you this because it brings up a pretty interesting point that we ran into a few weeks ago in the QA team where we're like, "Hey, should we update our laptops? Is it safe to update or not?" And we never got a concrete answer from IT. And I'm going to bring Zsolt in, and I'm sorry, Zsolt, to hear this, like, hello. But he's the only one really on the team who prefers to work in office, like in an office setting. So we just messaged, and we're like, "Hey, can you go bug IT really quick and just ask them a direct answer? Like, this would be nice to have." And he's like, "Yeah, sure. Give me like five minutes."

And so he's like, AFK. And then he comes back about 10 minutes later. And he's just like, "Oh, I have an answer. This is what it is." And I'm just like, well, that was fast. So you can be more efficient, I guess, and you can get your answers quicker [laughs] if you're in the office.

DAVE: Yeah. It's important to remember that when the shoe is on the other foot, it's the exact opposite. Like you just said, it's nice when you're remote to have that solitude and get your head down and get some work done. And you can't do that if David Brady is standing at your desk being awkward, waiting for you to babysit him. It's like, I got to get work done too, man. It's an interesting balance. And that's what I would say is it's a balance. Sometimes you got to lean hard to one side versus the other.

ZACH: So there's a quick story I wanted to share from my last company of how we got, like, limited the hovering over the desk, especially for questions. And I think all of us as developers have done this before where you go and ask a question, and as you're talking through it, the answer just pops in your head, and you didn't actually need to take somebody else's time.

So we were on a project that was just a big time crunch. And our VP of data science actually brought in like a six-foot stuffed bear [laughter] with a Jazz jersey and a hat, and he sat him in a chair at one of the desks at the beginning of our aisle. And before somebody was allowed to actually come talk to us, they had to talk it through with the bear to see if they got their solution from that or not.

DAVE: Nice.

ZACH: I mean, it limited the distractions, and we were able to get the project out in time, half because I think a lot of people don't want to go sit and talk to a stuffed bear, and then the other half just basically they figured it out on their own talking to the stuffed bear.

EDDY: Kind of rubber ducking.

DAVE: I've heard that referred to as teddy bear debugging, or rubber ducking or teddy bear debugging, yeah.

EDDY: Rubberducking, yep.

DAVE: And yeah, like, by the time you serialize a problem in your brain to be able to stream it out as words, that's usually enough to reframe the problem in your head, not usually, but there's a fair amount where that's enough to solve...yeah, you said it already. I'll just...I'll shut up. [laughs]

ZACH: And on the flipside of that, I think that when you work remote, it's more conscious effort to reach out to somebody than to turn your head and say, "Hey," right?

DAVE: Yeah.

ZACH: Or just walk three feet away, five feet away. And so I think a lot of people actually kind of do that internally when they're remote.

EDDY: Zach, I'd argue that maybe there's been times where you'd you start to type a message to someone because you can't figure it out. In the middle of typing that out, you're like, oh yeah, that's the answer. It's kind of like a similar concept.

ZACH: Yep.

MARCOS: And it happens most of the time.

[laughter]

ZACH: I just noticed since we've gone remote, when I get questions, they're hard issues. I mean, some of the time, it's something that I just know because of my experience here. But a lot of the time, it's something where I'm like just researching with one of the team members on how to get past it.

DAVE: Yeah. That is awesome. I want to thank everybody for coming out today. David, Marcos, you're still here, Zach is still here, Eddy is still here. Thanks for coming out today. This was a fun chat.

Today we talk about code cleanliness and organization and the importance of it all.

Transcript:

MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I'll be hosting today. We are going to be talking about code cleanliness and organization and the importance of that. Let's go ahead and introduce the other people who are here today. David, do you want to introduce yourself?

DAVID: Sure. I'm David Solano. I've been here in Acima for a little bit more than a year, basically programming Ruby on Rails. I would love to talk about this important subject.

MIKE: Great. Ramses, do you want to introduce yourself?

RAMSES: Hi, everyone. I am Ramses. I'm primarily a Rubyist, a little bit of JavaScript as well. So I'm excited to be in this discussion.

MIKE: Eddy, do you want to introduce yourself?

EDDY: Hey, everyone. I love these. Thanks for including me. As he said, I'm Eddy. Thank you for having me.

MIKE: Yeah, let's introduce our topic a little bit. And I've been thinking about a good way to introduce this topic. I wanted to start with a story and talk a little bit about my wife; she is an organizer. Let me clarify that there are a lot of people who like to have things organized. It's like something that they like; that's not what I'm talking about. My wife treats organization as a science. [laughs] She doesn't just think, oh yeah, I like to have things organized. She treats it almost professionally.

When she comes into an area of a home or a building and wants to make use of it, she looks at the space, thinks about the shape of the space, and thinks about it in great detail, does research. Her mind just gets cranking and figures out the ideal way to organize the space so that it's most useful. She's taken, classes. She follows prominent organizers (There's such a thing.) since before they were popular. It's like a thing she's brilliant at, a lot of background. And this spills over to other areas where she'll come up with better ways to do things like an algorithm for solving a problem that's slow; she'll think, well, why don't you do it this way? Oh yeah, that's better.

But just on a very small scale, we have a pantry where we store stuff near our kitchen. We'd buy stuff for years and throw stuff in there, and it just went there to die. [laughs] It wasn't very well organized. There was food in there that we liked to eat, but it would end up tucked behind something, and we'd forget about it. And we'd end up buying the same thing a while later, forgetting the original stuff was there. Then we'd go clean out like, oh, wait, this has gone bad. It was never very useful.

So my wife thought about that, did her planning that I talked about, got an appropriate set of containers, put in shelving, arranged the pantry so that everything that is in there is in. And, you know, we had to decide what we were going to put in there. There are some things that didn't get a go. And everything that is in there is an appropriately sized container that is labeled and highly visible on a shelf; there's no too deep anywhere. And things we use less of are in smaller containers. There's some shelving on the inside of the door as well that nests in, so it fits perfectly. It's kind of amazing, honestly. [laughs]

The interesting thing is you can't just throw stuff into the pantry anymore. But we use it far more than we ever did before. Although it takes a little bit of time to make sure everything's put in the appropriate bins, it's immediately obvious. You walk in there, and you know in a moment where the thing that you want is. And we use it multiple times a day. That's where we go for a lot of our food because it just works so well.

There are several interesting things that I've learned from this. Organization isn't just about convenience. It fundamentally changes the way that something can work. This area went from a place that we occasionally used for things we thought, oh yeah, I think we can have long-term storage in here, to kind of a fundamental extension to our kitchen and where most of the stuff that we actually cook with is because that organization allowed us to use it differently. I think that code being so abstract it's easy to misunderstand or to just not be able to think about it very easily. And having these parallels in the physical world allows us to understand better that, hey, wait, there's something to be said about that.

When we're writing code, we run into a lot of similar constraints. When we have code that we've just kind of thrown stuff together and allowed it to build over time, which is the easiest way to let things happen, it's kind of how code usually goes. If you're not very conscientious about it, then you end up with a structure that's kind of formed ad hoc, and it gets harder and harder to work with. And it's not just a small thing like superficially hard like, yeah, that's kind of not aesthetically pleasing to me. But it makes it less and less useful.

You accumulate what we call technical debt, which is doing something quickly now that you'll have to pay back later. It can actually accumulate to the point where it's very hard to get anything done because it's really hard to tell when you make a change whether it will have ripple effects somewhere else in the code that's really hard to understand because you can't see it. You can't wrap your head around it. I've got other stories I could tell, but I wanted to start with that one to set the stage for our discussion.

RAMSES: I think you bring up an interesting point; when the code is organized well, it makes it easier to think about and easier to find things. Like, in a pantry that's disorganized, back to your analogy, if it is disorganized, it's hard to find things. And you often buy the same thing even though you already have it, and it's perfectly usable.

MIKE: Oh, I'm thinking about times I've had to navigate messy code and tried to find something. [laughs] I have absolutely seen people rewrite code that does the same thing as what was already there because they couldn't find it.

DAVID: This just reminds me, like when I started coding, there were no standards obviously in the place that I was. So I was just writing code, writing code, at the end, it was working. Six months later, when you have to go back to make a change or something, it was extremely difficult because you probably have forgotten about it. When you take a look at it, it is like, oh my God, who did this? Oh, it was me, but I don't remember now.

MIKE: [laughs]

DAVID: And it's working. But why did I do it in this way? Nowadays, it's, for example, people working in places like Acima, which has standards, we follow our code review process. We guarantee that new code always follows good standards, and it's probably a little bit more easy to organize. That doesn't mean that maybe we're going to switch it later to a team that needs to do delivery faster.

I have also been there on teams that there is one team which has time to build code in a proper way and another team that they just deliver. It doesn't matter how you write it; try to write as good as you can but just write your code and try to do the delivery as fast as the client requests. And as you mentioned, add a ticket to work on this later for the other team, but unfortunately, I think sometimes it adds a little bit more complexity to the code. I believe it's something that we need to avoid.

MIKE: That's interesting, one team that does a bunch and the other team that cleans up. Do you think that that actually ends up going faster in the long run? One team that just tries to go fast, another team cleans up?

DAVID: No, it will definitely add more time to the other team, especially if they need to do a change of something.

MIKE: Yeah, there are some choices that you can make, shortcuts you can take in the code that might save a little time in implementing it in the short term, maybe, but in the long term, make it much slower because it's harder to work with, and sometimes very small changes that have big impacts for years afterward. I believe strongly that taking a little bit more time to do it better upfront usually doesn't take more time.

To share a recent story, I won't go into deep details about the project; there's a team that was trying to get a project done quickly. And they thought, well, this is so urgent. We don't really have the time to coordinate and get all of the names in common, and it's just names, right? Making sure that we're on the same page about what things should be called. We're not going to get all that straight ahead of time because we just need to get going, so we just need to get coding.

And several months later, after implementing it the third time, [laughs] they finally got it out after having coordinated and gotten all the names straight. The process of trying to get things working across teams when they didn't have the contracts well established, and those boundaries well understood meant that they didn't match, and it was kind of a disaster. And doing it the way that should have been done in the first place actually worked. Luckily, we don't have a habit of doing things that way around here. It was anomalous, but it was kind of eye-opening to see that this one project that they tried to rush didn't work. It didn't work. And that's just a single example.

If you build your code that way for years...and I've been in a number of places over time, and I've seen code that just created things on top of the mess, more and more and more, you know, just shovel it onto the pile. It may save a small amount of time upfront, but oftentimes it doesn't even save you time then. It can take more time to try to take the shortcut than to do it the long way. Everybody who has in the real world tried to take a shortcut has likely found that oftentimes the shortcut actually takes longer. [laughs] It works that way in software too. Have you all had that experience?

DAVID: Probably I've mentioned this in other podcasts; I'm not sure. But there was one big function, so big that it takes like, I don't know, hours to finish. It needed to be completed in minutes because we needed to run it at night, so we don't affect any clients. But we needed to do some changes there. The function was extremely confusing to understand, and to fix it that we decided to just drop it and start one from the business side logic and created a new one following good standards.

Once we finished it, from hours to finish, it just took minutes. It still was heavy, but the approach we followed was to just build it from scratch because it was so difficult to understand. There was so much business logic there that it was just better to do it from scratch than to try to fix something that is already too tight.

MIKE: And did you even rebuild it with performance in mind, or did you just rebuild it, and it worked?

DAVID: Oh no, we built it with performance in mind because we took a look at some of the ways they were doing some cycles in the code. And they were performing a lot of queries to the database. Instead of just pulling one amount of records first, work on them, and then pull some other records later, they were just pulling on one record. They had the N+1 problem a lot of times there. So yeah, we thought about performance first.

And we also thought of something which I've mentioned some times in architectural meetings. We thought of building a guide about how this process works because all the business logic was in the code, but it was spread across multiple people. So you have to ask someone from legal, someone from, I don't know, who worked with the clients to know why this process works in this way, someone from another department to know why this process works in this way. So we gathered all that information, and we built some guide first, so we documented everything. And then, we managed to code the version again.

And after we coded in a proper way, there was already a guide and some documentation that you can first read and understand from like a lecture. And then you can go and take a look at the code, and then you'll see, oh, now this makes more sense. So we did those two approaches, which I think was a good approach in order to do that.

MIKE: To talk about refactoring something for performance, I was involved in a project a number of years ago. I was working for a company to build a CMS, a content management, and we had code that would display advertisements. But the CMS we provided was...the company is defunct now, so I could probably talk about it, but it was for primarily newspapers, magazines. The publishers were moving online. And sometimes, they worked with advertisers, so we had to have our own ad network. But mostly, we worked with external ad networks.

But we also had our own in-house ad network at the time so that these publishers could run ads from their local merchants. A car dealership, for example, might want to advertise on the site, and we had support for that. And we noticed that the serving of ads because there were a lot of them on a page, was more than half of all of our database load. And just our overall time in our application, more than half of it, was just serving these ads, which seemed really excessive given that the ads were relatively simple. And there's all the work of publishing the articles and showing all of that content, but the ads ended up dominating that.

So we extracted that code out and just built it from scratch in a really small microservice. It really didn't do very much. It just was very focused on delivering the ads, and that's it. And once we had that built and took it out of the primary app, it went from being most of our database load to being almost unmeasurable; it was just 1% or 2%, I think. It was an insignificant part of our load. Just cleaning it up, just cleaning up the code, and getting it out into its own place where you could see it and think about it made a tremendous difference. And then we basically forgot about it because it just worked.

DAVID: Yeah, that sounds great. I wanted to bring something now that we're talking about cleanliness. I'm not a big fan of unit tests, [laughs] but I know they are pretty good in order to ensure that your code works as expected. And this is something that I found in this process of knowing how to code in a better way. If you find that your unit tests, for us RSpec, if you find that your code is getting a bit more complicated to test, that means that maybe your code is not coded in the proper way, and you're adding more than you need there.

So this is something that I actually use to ensure that I'm writing something that other people can understand and that I'm doing it in a proper way too. Because I've been there that I'm trying to test something that is just not possible to test in the same class, and you know, oh, maybe I need to move this to another class because it's a completely different thing. So yeah, I believe unit tests are a good tool to write better code, clean code.

And I think this is something that here we can do; I mean, we have good examples here because we're being clean in the current RSpec we have writing here in our project. And, I don't know, the other guys can tell me if they have found it, but I have seen some examples where trying to test the code is hard sometimes because maybe we could have done a bit better in the way we did that class or something like that. But yeah, I think it is just amazing to ensure that you are making an easier code or clean code to save some time.

MIKE: I think that's a fantastic point. Well, unit tests have several things that they are good for; sometimes, what their primary value is is not what you think their primary value is, [laughs] I'll put it that way. You think, well, I just want to verify that my code is correct and unit tests are good at that. But if you've thought through your code wrong, you're likely to think through it wrong on your test as well. So you're testing that your code does what you expect it to do, which was not what you should have done in the first place.

Tests can actually be misleading in that regard, but there are some things they're very good at, like allowing you to refactor and make sure your code isn't broken. And what you just said is a tremendous one, I think. It's a tool, an instrument. It gives you visibility into your code quality. If your code is easy to test, then that suggests that it's easy to think about because your tests are kind of like an external observer. And if your code is really easy to test, good on this branch, good on this branch, test both of them, and everything's good, that's a really good sign that your code is good.

And if your code is really hard to test, then you probably have too much going on, right? I'm with you 100%. It's an excellent indicator. Ramses or Eddy, do you have any thoughts about using tests to kind of force yourself to keep your code clean?

EDDY: So I can see the more in-depth I get into picking up tickets and breaking unit testing, I'm starting to see the benefit of why we have them. If you test with QA and unit testing, like, you're ensuring that the ticket or the dev ticket that you picked when you're deploying the master is working the way it's intended. So not only are you testing the code, but you're also testing the UI side of stuff. So I do see the benefit behind it. It can be quite stressful to wrap your head around at first, but I do see the benefits on unit testing for sure.

MIKE: Another thing that got mentioned...I think somebody mentioned it. I think you mentioned it, David, but it may be you just said something that made me think about it, but I think you mentioned it. You talked about, I believe, RuboCop, which is what they call a linter, but it's also a static code analysis tool. We have those across languages that a linter is a tool that checks your code syntax and makes sure that it's clean. Static code analysis goes a little bit further and does some analysis on your code to check whether it has some security vulnerabilities or whether it has some complexity and just some kind of broader tests. And the boundary is a little bit fuzzy between those two.

A really sophisticated linter might start going into some of the static code analysis. And a purely static code analysis tool might actually have some linting built in as well. But these related tools exist in a lot of languages. And I didn't use those early in my career, and now that I do use them, I think that they are fantastic. And I say I didn't use them; I didn't use them as much, I'll say that. I don't think I've ever completely gone without using those kinds of tools, whether your IDE makes them suggestions or I would run...certainly there's compiling where I'd run syntax checks.

Now that these tools are more broadly available, I love them, RuboCop in the Ruby world, because it takes the job of enforcing consistency out of the hands of your peers. So your peers don't have to nag at you and say, "Oh, you forgot to indent here." Instead, you can together come to a standard and usually use a community standard that says, "This is how we're going to do it." And you all agree that you're going to do it that way, and now you don't have to think about it. Now everybody is coding to the same standard.

And, generally, it's enforcing not just arbitrary choices like how far should you indent, resolve the tab versus space arguments [laughs] by just not having them, whatever linter you're using is going to make the choice for you, and you don't have to have the argument. But it goes further than that. It means that because you're not having those disagreements over...I'll come back to the idea of a bike shed. You're not having disagreements over irrelevant things. You can actually talk about relevant things in your reviews.

When you have one of your peers reviewing your code, they are not thinking about how distracted they are by some syntax somewhere because they don't have to. They get to think about structure and whether it actually solves the problems that it's intended to solve, and that's a much better thing to be thinking about. It's much better discussions to be having. They're much more fruitful and likely to lead to better changes than just making some superficial changes.

Coming back to the idea, there's a widespread idea in software about bikeshedding and the idea that, as a verb, you bikeshed. It's a verb. And where that verb comes from is the idea you build something very complicated like a nuclear power plant. People in the community are really not going to share an opinion as to what the design of the reactor is going to be because they don't have the expertise to make that kind of choice. There are going to be a few people who have that expertise who will evaluate the parameters and come to a decision. So it's a very important decision that will have decades-long impact, but only a few people will participate.

But if you build a shed out front to keep bikes dry when people go up to park at the facility, and you ask what color it should be painted, you will have long, maybe months-long arguments and debates of people expressing their opinion as to what color that shed should be painted. And the idea here is that the debate over something is usually inversely proportional to how important it is. The more important a decision is, the less likely it is to be debated.

And linters help with that problem because they remove that lengthy discussion over irrelevant topics. And what colors should be painted? Well, it's always going to be black, and you don't have to make that decision. In the end, that decision didn't matter very much. It frees your mind to talk about the more important things. It's an aspect of code cleanliness, keeping your syntax clean, that I think it's fundamentally important. You can't understand code very well if it's a mess. But you can solve that by using an automated tool to tell you how to do it and then do it that way.

DAVID: Yeah, I totally agree. And I'm glad you brought this up, Mike, about RuboCop. I also have...sorry about that. So when I started coding and I was introduced to RuboCop, I was angry [laughs] because it was highlighting all my errors in the code and, like, who invented RuboCop? I was so angry.

MIKE: [laughs]

DAVID: Of course, I was a junior, and in those times, I was thinking that I was right in the way I was writing code. And then I realized that, no, this is actually a good tool because it provides you a better way to do things. And it also ensures that other people that are going to, which is the most important thing. Also, if other people are going to change your code, at least it follows a standard there. So yeah, it's a pretty good tool.

And this is something that I'm glad that Ruby has, so RuboCop is one of those. And I also wanted to mention another one which is Rails best practices, which also allows you to follow good practices in Rails. So this is just great in order to talk about important topics, as you mentioned, in your code and not only maybe the way you just coded something. A tool is already going to provide you with a fix, with highlighting the error and using it in a proper way. So yeah, I'm glad we use those tools here in Acima.

MIKE: You know, some languages, you can take languages with syntactic whitespace like Python, for example, they structure the whole language to enforce certain conventions. So you can't argue with it. Your code won't work unless you write it cleanly. And it doesn't solve all problems, but it does solve some. And there are proponents and detractors of that idea out there; not everybody loves it.

But there's a reason that people would have that idea and push it forward because it's just so important to have that consistent syntax to be able to work together as a team that it's worth having it baked in the language where you can't even get your code to run unless you follow that standard. There's a reason that people would build something that way, whether or not you think that you should do it that way. It suggests that there's enough value that some people have considered doing it that way.

DAVID: Yeah, definitely. And this also saves time. And I wanted to mention this because last time we had our weekly meeting, we mentioned that no one is going to code review your code if you don't ensure that RuboCop passes. [laughs] And it's something good because it is our team's standard. And it also ensures that you're going to present some code that follows the team standard and follows the rules that RuboCop currently has. So this is something really good.

MIKE: I agree with you on that. If you're not used to doing it that way, it can sound like, wow, that's a pretty strict rule. You won't even review my code if it doesn't have clean syntax? I'd say the opposite is true. If you don't have a rule like that, then you're forcing the reviewer to have to make comments like, "I don't like the way this is structured. It doesn't really follow the standards." You are coercing your peer into evaluating parts of your code that it shouldn't be their job to have to review.

DAVID: I agree. A few years ago, we didn't implement this RuboCop in one of our projects, and we, the devs, spent a lot of time just trying to have our team standards like, hey, make a breakpoint here; this is a new line. And oh no, do an end instead of curly brackets here. And all that time could have been saved if we had used RuboCop. Because we used to have like 20 comments per code review [laughs], and that was just a lot, something that RuboCop could have just fixed in a couple of minutes or seconds, actually.

MIKE: And you can integrate that into your editor, and then you don't even think about it. Because you get syntax highlighting that says, "Your code is not following the standard here." I learned to see from a long way off in my editor; oh, I know exactly what's going on there. It's just got the underline or the color saying something is going on here.

I know, even without having hovered over to see what the message is, I know exactly what the problem is. Because, like, oh yeah, I bet that that's saying I haven't added a comment on my class to say what it does, or I bet that's saying my line is too long. So you end up internalizing it to where you do it without even thinking about it, which is great.

So let's see, we've talked about how messy code takes longer to work with and may not even save you time to make the mess in the first place. We have talked about the value of following standards. We've talked about the value of sometimes refactoring and starting over from scratch and building something clean because it saves you more time than trying to fix code that is so messy that it is unsalvageable.

I think there are some other interesting questions here. One interesting one, I think, is how do you start a project clean? How do you start it with standards such that you avoid a lot of these problems upfront? You're never going to avoid all the problems. Just by natural growth, I think any system is going to develop parts that are more complex than other parts. And in that natural progression, you'll notice that this part has become more complex than it was initially, and I need to go in and refactor it.

So I don't think you can universally avoid problems, and just naturally, some things are going to be more complex than others. However, I do think that you can avoid a lot of the worst pitfalls by starting off with good standards and good structure. I have some thoughts on this, but I'm curious what you all think.

EDDY: I like the idea of clean code; for example, the concept of self-documenting code is really important, especially to me when I'm viewing a file for the first time. And I think that the code should be describing what the code intends to do by itself without the need of following the syntax per se. I think the Ruby syntax really aids in that as well because it reads in English. But having the code do the talk for you is really important.

MIKE: That's interesting. We've talked about things we can use to measure whether the code is good or not. Like you say, if you read the code and it looks like English and reads like prose, the code itself reads like documentation, that's a good sign that it's well-organized and easy to understand. And if you have to stop and think about it or if you have to have a lot of comments to explain it, maybe you've done it in a way that is not easily thought about, and it'd be better to reorganize that.

As David was saying, that person that comes back and doesn't understand it is likely to be you six months from now or maybe one month from now sometimes. [laughs] Future you is not going to remember current you very well. And it's going to come and try to figure out what current you is doing and wish that you had been more conscientious.

EDDY: Or having easy-to-understand names, [laughs] like, that's really, really, really important.

MIKE: I think we could have a whole session on that one. I think it's funny that, as developers, we'll sometimes think we're saving time by dropping a few characters in a variable name, like, oh, I'm not going to put these characters in there because I want to save those three characters of typing, which takes you some fraction of a second. But then, when you come back and try to think about the problem, you have to figure out what that variable name is, and it takes you several seconds every time you look at it. What time have you saved?

I think you almost never save time by coming up with abbreviations because they force you to have to think more about it. And that thinking about it takes a lot more time than the trivial amount of time it takes to type a couple more characters. I mean, we've got good tools for input. Even if you have some, you know, I sometimes get some repetitive stress of it, and I don't want to be banging away on the keyboard all the time. And despite that, I think variable names should be long because it just doesn't add very much to write a few more characters to make your names easy to read.

And yeah, to ask my question that I was asking before a little bit again, how do you get the standards from the beginning? I could make some suggestion there that, in most cases, it makes sense to go with some sort of community framework rather than thinking I'm just going to start things from scratch and put it together as it goes. I want it to grow organically. Well, okay, things do grow organically, but people who garden put up a trellis for their climbing vines because they want to give them an opportunity to grow and not just sprawl out across the ground.

This idea that things growing should not be restricted at all, I think, is misguided. Things grow better when given an opportunity to climb up a structure toward the sky. And if we give them that structure, to begin with, then things will grow organically to fill in the space that you're providing for them. And if you don't provide them that space, then they'll hit those constraints very quickly. And you're going to have to rebuild it, and rebuild it, and rebuild it, and create those constraints over time, which is much harder than adding some constraints up front.

And specifically, I think it makes sense to say, well, this is where these kinds of files go. In some languages, you're not going to have as much opportunity there. But almost everything you're going to work in is going to have some sort of framework, and then you can think about architecture. Well, what if I'm going to use model–view–controller architecture? So I'm going to have my data layer over here, and I'm going to have my logic layer here. And I got my presentation layer over here.

Taking the time upfront to separate those ideas, to separate that code, and organize it is worth it. It is absolutely worth it, and that's why frameworks are popular. Also, they do a lot of the lifting for you. But the convention, the code conventions, this is where you put things is sometimes underappreciated as a vital part of what those frameworks provide you. It's not just the libraries they provide, which are invaluable, but it's also the structure.

DAVID: I totally agree with that. I've tried to create a few projects in the last few months just for fun. So I like the fact that when you're going to start a new project, the language itself or the framework itself provides you with the tools as you manage your code better. I don't want to start to go into details, but, for example, with React, if you try to use React, sometimes they enable the ESLint; I think maybe it is called.

So if you make some syntax errors or just code in some weird way, it will highlight the error, and your code won't compile, [laughs] and that's good. You probably get a little frustrated at the beginning, and then you'll be glad that it highlighted that error because it will definitely save you in the future.

In the case of Ruby, I do agree that when you're going to start a Ruby or a Ruby on Rails project, you should add these valuable gems we talked about, like RuboCop is one of them. Bullet is another one which will highlight the N+1 error or how your queries are in the database. So yeah, I think that's a good approach; use everything that frameworks provide in order to code better and clean.

MIKE: I'm with you. [laughs] Bullet is a nice tool. As you say, it looks for things you do with the database that you shouldn't. [laughs]

DAVID: Yeah, it has saved me sometimes, [laughs] a lot of times to be honest.

MIKE: Great. I think that we're reaching the end here, the time we were going to spend. Does anybody have any final thoughts that they've been holding in they'd like to share about code cleanliness and organization?

DAVID: I just wanted to close that having team standards is extremely valuable in projects because they let you grow up as a developer and also as a person because you will understand the way the team works and the way you should also think if you go into that team. That also provides or gives you a way of knowing how mature a team is. And here in Acima, it's something that we actually have.

We have changed our standards too. I mean, we have had a few meetings where we'll talk about why we changed this in this other way. And we come to an agreement, and if it is good for our team, we change it. And so this is something great that a team should have. And it is something that is so valuable because it will help you code better. It will help you understand more the way to code and also the way the team works. I just want to highlight that. I'll finish with that line.

MIKE: Again, you said it wonderfully. Those team standards just make such a difference. Maybe I conclude here by tying back to where we started, the idea of organization. And I say we should all be more like my wife [laughs] and treat organization not just as an aesthetic concern, like, I like the way this looks, but realize that it's a fundamental characteristic of something that is easy to use, and that is maintainable in the long term.

Take some time to learn some of that science of some of the process that is involved in creating good structure, good hygiene, good cleanliness in our code so that we can maintain our software into the future. Take the time to develop those team standards because it's worth it. It's been great talking, and I'll see you next time on our Acima Development Podcast.

Let's talk debugging skills! The conversation starts with some fun stories and experiences regarding debugging in general, and then panelists share thoughts about how to find bugs, lessons learned struggling through debugging, and how the way we structure code has a great deal of impact on debugging.

Transcript:

MIKE: Welcome to another episode of our Acima Development Podcast. We have, I think, an exciting discussion today. It's relevant to anybody doing development. We're going to be talking about debugging skills. Before going to that, let's go around and do some quick introductions. I'm Mike. I'll be hosting today. I've been a software developer for over 20 years, a Rubyist for most of that. Ramses, do want to introduce yourself?

RAMSES: Hey, everyone. I've been a familiar voice on this podcast for a while now. I've been a Rubyist developer for about a year and a half and a professional developer, I guess now, for about six months, and at Acima for almost four years now.

MIKE: Thank you. Afton.

AFTON: Hi, this is Afton again. I am also hitting my four-year mark this week here at Acima. And I've been in Ruby and Ruby on Rails my whole career.

MIKE: Thank you. Zsolt.

ZSOLT: Hello. I'm Zsolt. I've been doing hobbyist development for a little over ten years. I have been a Rubyist for about three months of that so far, very wonderful thing.

MIKE: Great. I think that we've got a range of experience levels here, which will be really great for the discussion. I wanted to start the discussion with, let's say, a couple of stories. The first one is not my own. I had a friend who had a professor [laughs] who told me this story. This friend got the story from the professor. He had a professor who said...when he was teaching the class, he taught them the way you find the last blue wolf in Ireland.

And the way you find the last blue wolf in Ireland is that you build a wall across Ireland. And then you stand up on the wall at night, and you listen for which side of the wall the wolf howls on. And then when you figure out which side that is, you build a wall through the middle of that side of Ireland. And then you stand up on the wall at night, and you listen, and when you hear the wolf howl, you know it's on that side of the wall. And then you build the wall through that section and do the same thing. And after a few iterations of this, you've found your wolf because you've cut down the problem size by half every time. That's my first story.

[laughter]

The second one is more of a personal one. I've got a window well that has regularly flooded for years, and it's just been a persistent problem. Luckily, the basement is unfinished or mostly unfinished, but it's a hassle. When it floods, we have to peel up the...we got some foam floor, and we peel it off the ground and have to mop up the floor and scoop up the water and put it in a bucket and dump it. It's a pain. [laughs] And I've had to do this often, particularly when the rain comes from that side of the house.

And I've tried all sorts of things to solve the problem. First thing I did was dug out some extra dirt in the window well. I thought, well, if I add some capacity to the window, well, the problem is that it's not big enough. Well, it didn't help. And I noticed that there's a drain pipe in there. It's a perforated pipe that goes down into the ground and connects to some others that go to a drain that comes into a sump with a sump pump. It drains the foundation, so we don't get flooding.

And the pipe, I thought, well, you know, this pipe is really long. It's hanging up at the top. Maybe some kids shoved some stuff in the end of it because it's just perforated. Maybe water can't get in the top. So I shortened the pipe, didn't help at all. [chuckles] We still got flooding. I used some caulk, and I sealed the edges of the window well. I thought, well, maybe water is pouring in from the side when it rains heavily from that side, and if I seal the joints, that will help. And the same problem still happened.

Earlier this year, I got a pipe auger or a pipe snake, like, long ones, so I could really run it down there, 50-foot long. And I attached a drill to the end, and I put it in there. And I thought, okay, there's probably some debris in there because it's just draining really slowly. So I ran in there, and I ran it in there, bzzzzzz, spun it around for a while. And I pulled out a little bit of mud and a little bit of grass, and not enough to matter.

[sighs] What is up with this? As I was standing there looking at the window well, kind of scratching my head, I noticed that there is a drain coming down from the roof into some drain pipe that ran out through under the lawn and drained over into a low spot that drains out to the road. And I noticed that where that drain pipe came out, the grass had grown over it, so it was plugged over. And I thought, oh, I should do something to fix that, you know, I bet the water is not able to get down there very well. I should have thought a little harder about this.

So I went over and took a little shovel and cut out around the end so the water could drain out there. And I took a hose, and I thought, okay, I'm going to test this. And I took the hose over to the end of the drain pipe coming off the roof. And I noticed that where that drain pipe met the pipe that goes under the ground, they'd become dissociated. The ground drain pipe had loosened over time. It had been washed out a little behind and fallen off and slipped over to the side.

So the drain pipe coming off the roof wasn't going into the drain from the ground at all, and if it had, it was plugged at the end. So any water that was coming down there, and it was about three feet away from the window well, would have immediately just started flooding the area next to the house, gone straight down to the window well, and poured inside.

After all these years of trying to figure out what was wrong with the window well, I realized the problem wasn't the window well at all. The water was coming off the roof and pouring straight into the window well. And there's no amount of drainage [laughs] that would have helped to solve that problem. The problem is it was just dumping water in every time it rained.

I took the pipe that went underneath, connected it to the drain pipe, stuck a couple of rocks under it, just some pebbles nearby, to brace it so that it was high enough. And presumably, the problem is solved with a couple of little pebbles. Had I looked around the window well ten years ago when this problem started happening, I would have saved myself a lot of trouble.

A couple of things I want to point out from this story, additional tools did not solve the problem. You know, I cut the pipe. I used the caulk to seal the joints, used the pipe auger, you know, I kept on escalating the tools I used to solve the problem. None of that solved it. What solved my problem was better observation of the situation and, in particular, of the context. Looking bigger than just at the window well and seeing the context that it was in allowed me to see that I was targeting the wrong problem. If I had looked a little bigger, I'd have seen what the underlying cause was for all the troubles I was having.

I thought through these stories ahead of time since we're talking about debugging because I think they'll really inform our discussion talking about software and how to find the problems that we have. With that, [laughs] any thoughts from the rest of you about...well, you can start with the stories or about debugging in general, your thoughts about how to find bugs given this discussion so far.

AFTON: That's such a good story. It brought a quote to mind from The Pragmatic Programmer I've been listening to. And I'm going to botch it. And I'm not even 100% sure it's related, but it's what came into my mind. [laughs] So it was saying that novices tend to try to fix problems by adding more correct code, or writing something to be more correct, or a new workable code. And experts go in and try to remove the problematic code. [laughs] So, I mean, first of all, you tried to add all these new solutions in, and then, in the end, you had something that was existing. You just had to refactor. I don't know how that works in -- [laughs]

MIKE: Oh yeah, refactor, exactly.

AFTON: Yeah. [laughs] That was a good quote.

MIKE: The direction I've thought about this is I see a lot of people lean hard into their debuggers. And debuggers can be a useful tool. So I want to be careful here. I don't want to suggest that you should never use a debugger. That being said, a debugger is a sophisticated, complicated tool. And if you've got a complicated, hard-to-think-about problem, then adding something complicated and hard to think about as part of your solution may be problematic.

And I have not, in my career, seen that debuggers have tended, you know, the fanciest of the debugger has not gone very far to helping people solve problems. For myself, I honestly don't use debuggers very often. I print out to the screen, and that's worked in every language I've ever worked in. It works in C; it works in Java; it works in Python; it works in JavaScript; it works in Ruby. If you print something out, and they've all got tools to do it, whether you're doing your console.log() or your puts, or your System.out.println(), if you can print something out to your screen while your program is running, you get that context.

And you can put it where you think the problem is. You can put it on one side of the problem, going back to that blue wolf in Ireland. You can put it on one side of the problem and the other side of the problem, and you can isolate it, split the problem in half, figure which side it's happening. And such a simple tool means you don't really have to think about it; instead, you're just trying to identify which side of the wall the problem is on, cutting out half the problem that way.

You know, which side is it on? It gives you that visibility in a way that leaning really hard and trying to find all the things in one specific spot might not give you, you know, looking with a larger scope to cut the problem in half rather than getting hyperfocused on one spot.

I'm going to say debuggers could be a solution; you know, there are some pipes that need an auger to be cleaned out. [laughs] But, in general, it's the awareness that you need to be concerned about, and if you get that with the debugger, great. But, you know, if you can just print something out to your screen, that probably will work just about as well and maybe even better because you don't have to think about it as much.

ZSOLT: Right. The interesting thing is that, for years, I've been told that print debugging is a terrible practice and you shouldn't do it. And I'm like, you know what? I'm going to respectfully disagree with that and do it anyway.

MIKE: [laughs]

ZSOLT: Because it works very well for me. But I've also recently started using more actual debugging tools, and I do see where their uses stem from. But I do agree that you don't want to eat a bowl of cereal with an industrial food processor; I don't know.

MIKE: [laughs] You can use that to process the cereal and avoid the chewing, but it might not be fun.

ZSOLT: Exactly.

MIKE: Really well said. I've seen developers who are really, really good, and they often have minimal tools. They know the tools they use really well. I'm not trying to suggest that we shouldn't use tools, but they use them judiciously. [laughs] They learn that the tools don't necessarily solve the problem. It's the problem-solving that solves the problem. Ramses, what's been your experience with debugging?

RAMSES: I'm pretty simple with debugging. I'll use a lot of print or put statements in combination with regular debuggers. If it's JavaScript, I'll just use a debugger. If it's Ruby, I'll use byebug or binding.pry, just so that I can do a quick analysis of whatever objects or logic I'm trying to investigate.

MIKE: Makes sense. I want to talk a little bit about the first story that I shared about finding the last blue wolf in Ireland. It's a silly story, and sometimes the best ones are like that because they stick. [laughs] They don't have to be very serious, but they stick in your head. If you can cut up the scope of a problem in half repeatedly, it gets much smaller very quickly. It ends up taking the time relative to the base two logarithm of the data you're looking at.

And the code that we look at is not generally tremendously big. And we might be working with millions of lines. Even if you have a million lines of code, you cut that in half once, and you're down to 500,000. That's a large size, but after you've gone through 20 iterations of cutting it in half, you've gotten to a pretty small problem set. It really doesn't take very long to cut things down when you cut them in half every time.

But I think a lot of times we neglect that idea when we're looking for problems. We think, well, I know where the problem is, so I'm going to look really, really close there and do a lot of looking there and don't look next to the window well. There's another story that I've heard that I was sharing yesterday that I've seen shared a number of times, but I think is great.

You got a drunk guy who's looking for his keys, and somebody notices he's looking for his keys under the streetlight. He's like, "What are you doing?" He's like, "Well, I'm looking for my keys." And he's like, "Oh, so you dropped them here?" And he's like, "No, I dropped them somewhere over there." "Oh, why are you looking here?" "Well, the light's here. I can see here." [laughs]

And it makes us laugh out loud when you think about somebody doing that. But we totally do that; we look where we can see or where we think the problem might be. And if we spend too much time looking where there's a lot of visibility rather than expanding the scope of what we're looking at, find some way to add visibility to other parts of our code, then we're likely to waste a lot of effort looking where there really isn't a problem. And instead, thinking, well, what can I do to look at the broader scope and eliminate where those problems are?

ZSOLT: I also have something to add to that. In the same vein, it's also important to not over-isolate because then you'll just end up confusing yourself even more. Because there have been several instances where I have cut out too much, and then I just didn't understand how I got from not working to not working in a different way. I'm like, this is giving me even more unintended results. What's happening, you know?

MIKE: That's interesting. And how do you go about fixing that?

ZSOLT: So when I find that I've, I guess, you could say that I've overscoped the problem, then I will try to take a step back and then rethink my strategy for isolation of the problem. Because sometimes I'll be like, all right, so I have this set of functions that do these things, and then I'll take a look at one function that I think might be causing the issue. And then, if it's not that, I have to re-scope to another thing.

MIKE: Okay, so you hyperfocus on the problem is here in this function, and you realize, wait, maybe it's not.

ZSOLT: Exactly, because you start seeing that, wait, this is actually what I expected, or something else is wrong, you know?

MIKE: Yeah, absolutely. But you suggested something, and you said, but I think the problem is this function. A lot of times, if you're going through a series of functions, just something as simple as logging in each of those functions and to find out where the problem starts is really helpful. And you don't necessarily have to have it in all the places. You start by putting some sort of statement halfway through and figure out which side of that logging statement the problem happened on. You've cut down a lot of scope, that binary search.

Cutting the problem in half every time is just tremendously powerful, I think. It's not just powerful in debugging; it's how indexes work. And it's the reason you can search your database and get answers back quickly [laughs] instead of having to search every row. The internet wouldn't work without that kind of algorithm.

So I've asked Ramses and Zsolt specifically about some of their experience. Afton, I know that you were self-taught for a while as well. I'm curious what kind of lessons you learned while you were struggling through debugging alone during that time. I suspect you found some interesting lessons about how to track down tricky bugs.

AFTON: I was building a new project, and most of my struggles were how do I implement a new thing? How do I address a new problem? So, learning to research and going and finding answers was a big thing that I spent a lot of time doing and getting better at. But my own codebase at the time wasn't; I don't know, I'm not sure that debugging...because isn't debugging kind of fundamentally existing stuff, existing code, the problems in it, right?

MIKE: New code has problems, too. Just because it compiles doesn't mean it works.

AFTON: [laughs] Yeah, I'm not thinking about my learning stage and any scenarios really about debugging. I will say I've been thinking about how I go about debugging now. I typically find an entry point where, okay, the bug is being identified as this kind of process issue, or it's this feature-related. So I find the entry point, find what UI kicks off what processes, and go start at the controller.

And, I'll even, in my notes, outline as I'm going through the code; okay, the first entry point is here. This is what the code is doing, and either this can happen or this can happen. And what is the next step? And so I step through, you know, service objects and other methods and functions and just document this is what the code says it's doing. And I'll throw in my binding.pry at each new entry point to ensure that the data that I'm getting at that moment is what is expected.

So stop at each point, look at the data. Is this what the code is expecting? Okay, if so, great, move on to the next step. And work my way down to the point where, okay, it's expecting this value or this attribute and can find something that is inconsistent or unexpected or not present but should be. That's usually pretty effective for me, and creating an outline in my notes helps me gain this big-picture context, going from broader and narrowing as I go. So I think that's kind of a way of cutting in half, cutting in half.

This cutting in half thing I was trying to think, how do you do that? How do you start with a problem and cut it in half? How do you know you're cutting in the right place? How do you know what the boundaries are in order to cut it in half? [laughs] I mean, you have to see the borders of your zone in order to cut it in half. Those are kind of the questions that were running through my head, and I'm like, do I do something like that? And how do you know that you're doing that effectively?

MIKE: And as you were talking, I was envisioning pipes again (Talking about pipes today.), and I thought about sewage lines. They have access points, right? Once every block or so. When something's blocked up, they can go into each of those access points and find and check which one was blocked. They can't necessarily check everywhere in between. But there are those boundaries that you're talking about where you can check if things flowed correctly in between.

AFTON: Right. [chuckles]

MIKE: And, if you have a wide area, we'll start by checking some points in the middle, and you might be nowhere near the right spot. But you at least know that things were flowing there. And then you go downstream and say, well is it flowing here? It's your idea of you got to drill down through all this area. Well, you got to start somewhere, and maybe you don't know it. And maybe you're going to start at the wrong place.

That's the beautiful thing about binary search, though, is you can start at the wrong place, and that's okay. [laughs] Is it right here? And if it is, well, then you know it's farther down the pipe. It's farther down the call chain. And if it's broken there, well, then it was farther up the call chain. That's the idea, is your idea of this call chain. Again, I'm visualizing it as pipes again, but it's just calls, right? You got calls from function to function to function.

You can figure out, you know, start somewhere and see if it's right there, if it's correct, you know, if everything is flowing properly at that point, and if it is, well, then the problem is probably downstream from there, farther down the call chain. And if it's incorrect, well, then it's farther up the call chain.

AFTON: Right. Yeah, no, that makes sense. That's really good. Yeah, so I think that's essentially what I'm doing then.

MIKE: Yeah. I think these metaphors...so I like to throw out a lot of them because they capture ideas, I think, better than talking about the actual thing often does. Because if you can visualize something, if you can easily grasp it, then you can relate it to the problem and better understand that problem. As humans, we talk in symbols all the time. Words themselves are symbols representing ideas. They have great utility that we don't have to hold up an apple to communicate about an apple.

I can say the word apple, and that is a symbol that represents the idea of an apple, and communicate with you that way. It's not the thing itself but a token or a representation of that idea that allows us to talk in a more abstract way. Stories are a great way to abstract ideas to think about them in a higher level way than getting lost in the weeds as we sometimes do.

I want to make another observation about debugging. How easy is it to debug code that is sprawling and complicated, methods hundreds of lines long or functions (I'm using those synonymously.) methods or functions hundreds of lines long with lots of branching logic? Thoughts?

AFTON: That is very difficult [laughs] because there are so many things that can go wrong, and all in one place, supposedly returning one result is not easy. [laughs]

MIKE: No. And you think, well, it's just code, right? It does the same thing. The broader structural organization shouldn't matter; I mean, it's still just code. I say that, but I know it's not true. The way we structure our code has a great deal of impact on debugging. And I found that sometimes for tricky problems, the best way to debug the problem is not to but rather to restructure the code, refactor that code. Sometimes it's remarkable how much difference that makes.

To share another story, my son was doing some Minecraft modding a number of years ago, and he came to me for some help. And he said, "Yeah, my code is not working. Can you tell me why?" And I looked at it. And it was this deeply nested function. I think it was nested like ten levels deep or more, and the code wasn't formatted cleanly at all. I mean, there were double curly braces, and the indentation was inconsistent from line to line.

I looked at that, and I said, "You know, I really want to help you, but I can't." If you can go and just clean up your syntax, get your curly braces aligned, and your code indented, that's all I ask." I said, "Just get your indentation right and your braces in alignment so that I can see the structure of your code because right now, I can't. It's all over the place." He was young. He can be excused. [laughs] "It's just not lined up. I can't see it. I can't understand what's going on here because it's not organized."

And I didn't ask him to refactor the function. I didn't ask him to break it up into separate functions at all, just to order the code. He came back to me a couple of hours later, kind of with his tail between his legs, and said, "Well, I did what you asked, and the code works now."

AFTON: [laughs]

MIKE: All he did was clean up the syntax. And somehow, he had gotten some braces misaligned so that there was an if block somewhere that shouldn't have been. And by cleaning that up, without even noticing that he had fixed it, he had fixed his problem. That moment has really stuck with me because I remember, oh, wow, all he did was clean up the syntax. I'm not saying that cleaning up your syntax is always going to solve your problems, but it says something.

I mean, debugging is a human endeavor. It's something that we have to do to make better sense of the code. And things that we can do to better wrap our heads around what's going on are going to allow us to find the problem better. And that applies, first, not just to debugging but building the code; anything that we can do to easier think about the problem is going to be likely to help us move faster, not slower.

It's not working against you to organize your code well. It's actually helping you work faster and more easily. It may feel like it's a constraint that I can't just quickly get all the ideas out of my head. I understand that idea. But I would argue pretty strongly that organizing those ideas as you get them out, even though it's difficult, even though it's a constraint, even though it's hard to do that when you just want to get it out, is actually going to help you work faster.

It's similar to the idea of writing an outline of a paper before you just start banging away on the keyboard. Getting that organization in place is extremely helpful to being able to better express your ideas because it gives you kind of a map. It allows you to not have to worry about everything at once but to be able to understand what's going on elsewhere and then not think about it. It allows you to better wrap your head around the global context so that you can forget about it and focus on the local context. That's really powerful. It's a tool that allows you to use your brain.

One thing you said, Afton, I think goes along with that. I'm talking about taking notes and organizing an outline. Well, you said you do that when you're looking to solve a problem. You write things down, and you outline what the problem is so that you can see the overall scale of what's going on and then focus in on the parts that actually matter.

AFTON: Yeah, that helps a lot. And what you've been saying goes right along with our team convention of creating single-purpose methods and single-purpose service objects in order to take complexity out of one class and divvy it up into small, understandable, manageable pieces. Because, like you were saying, if the piece is small and we can hold it all in our head at once, it's going to be a lot easier to debug, to understand, and to utilize. So yeah, our team works really hard to do that. And that does aid in easier debugging, single-purpose methods, and classes.

MIKE: You've spent a lot of time working with a team that cares about those kinds of things. I've not always had that luxury. When you're working with sprawling code with a class that has thousands of lines, and hundreds of functions, and multiple different workflows that pass through the same class, they overlap each other. You're not sure which one is deprecated or how much they cross over or not. [laughs] Sometimes they touch each other, sometimes they don't. It is really hard to figure out what's going on.

Sometimes the best way to debug is to rebuild. I say rebuild; starting from scratch is often not tenable. Most of us who are in the industry are working on applications that are in production. And we can't just throw out this thing of value that we've built and start over. So, somehow, we need to improve it in place while being a running system. People talk about upgrading the airplane while it's flying; we've got to do that sort of thing.

But refactoring can be done. You can take something big and messy and replace it with something tidy in place, in particular, if you have written your code to be highly decoupled so that everything around it has a single entry point into that code and is able to, you know, just call that method. As long as it gets the same thing back, you can completely redo everything inside.

Now, maybe your problem is that it's not decoupled, and you've got a couple of things that are closely coupled and entangled with each other. Well, then, your problem is to figure out where to divide those. That's a whole different discussion that we should probably have some time. But by getting those divided so that they are decoupled, and there's a clear boundary there, it's likely to help you to solve the problem because now you've isolated the two components, and you can fix the problem where it is rather than having to deal with its repercussions everywhere else.

I'm just spending some time talking about this idea of debugging via refactoring. I think it's not something that we always talk about when we're talking about debugging, but I think it's a real thing. And sometimes, it's the most useful tool that we have. Finding problems in the code through isolating by using a binary search, following the call chain, cutting the problem in half every time is very useful. And it may even get you to the problem quite quickly and allow you to solve it there locally.

But if you're often having problems in the piece of code, that suggests a bigger problem than just a quick patch is going to fix. There can be larger structural problems that are leading to those bugs. I've seen this many times where there's code that's just problematic all the time, and it's generally because it's too complicated. And by complicated, I'm going to...let me define that. And it goes back to what you were saying, Afton. It's usually when things are doing more than one purpose, serving more than one purpose.

So if you've got a function that does multiple things or does something with a number of side effects, well, now you've got lots of things happening in one place, and you have to think about all of them going on at once, and that's hard to do. It's hard to make sure that all of the combinations are covered. One of the best ways to solve that is to disentangle the multiple things that are happening in that code into single-purpose components. Depending on the language you're in, there are different ways you could have those components, functions, classes, modules of some sort. The important part is that they have a single purpose.

Once you've done that, well, your code is still doing the same thing. So by some measures, the complexity is identical. But by disentangling the components, they both become more reusable. But they also become easier to comprehend and are less likely to have unexpected side effects when they interact with each other, unexpected interactions because they don't have any interactions other than through their public interfaces. And removing the opportunity for accidental interactions is what I mean by removing complexity. I think, oftentimes, we can do that. And that should be one of our primary focuses of refactoring. And that leads to code that is less likely to be buggy and may also be the most important thing we can do to debug problems.

I'm thinking about a particular problem that a team worked on a year or two ago. There were two workflows. I'm not going to get into the details, but the overall workflow for one object and the overall workflow for a related thing. They were entangled with each other and presented as one overall workflow. The problem was having both of those together meant that there were a whole lot of intermediate states. You think of a state machine, and there are a whole lot of states you have to accommodate because it was the combinations you have to accommodate, all of the combinations of all of the states of those two different things.

And by extracting one of the things out into its own thing and giving it its own workflow, we were able to dramatically simplify the number of states in each of the things because now we didn't have to account for the combinations. Each one just had to think about its own set of states. And there was a perennial series of bugs that was happening in one of these two things. And by just extracting them, the problem went away and hasn't been back since [laughs] because we disentangled them. The key to debugging wasn't just to fix that local problem, which would have patched that one little spot, but it would have left all the other problems of entangled state, and disentangling them was the real solution.

AFTON: Yeah, I'm pretty sure I remember what you're referencing. And I just remember whenever someone had to go in and make changes in that code; it was like a nightmare of, oh, good luck in there, you know. [laughter] But then someone new had to go in and try to make sense of this complicated system, which was more likely to create more bugs because it was so complex and hard to change that it was going to likely produce more bugs when changes were made. So yeah, extracting those out made the scope of the one feature easier to understand and, therefore, easier to change, which helps mitigate the likeliness of bugs. [laughs]

MIKE: Yeah, and I think the engineer when he was going in there, he was going in there specifically to solve a bug, and he said, "You know what? I'm not going to be able to solve this bug because the concept is not well enough disentangled." There's this concept that wasn't a concrete object. And by having it fuzzily spread around within the other object, it didn't have its own representation.

Going back to this idea of abstracting ideas, by giving something its own representation, there's a place to put everything. I worked with a developer once who said, "You know, you always need to create a new class, so you have a place to put stuff so that there's a place for everything." And I think that was really wise. By creating this new class, this new representation of the idea, there was a place to put the code that needed to be there.

The idea is you could give it its own database table easily, for example, and then have all of the attributes persisted cleanly and separately. And by being able to represent that idea separately, we're able to persist the state in a way that we couldn't previously because it was all entangled. And it was able to solve the problem because the idea could be represented. Before, there were key ideas that weren't even saved. They were just inferred, and sometimes the inferences couldn't be accurately made. Having that disentangled allowed us to see that, oh, wait, we need to be able to save this idea. And we couldn't see that before until it was disentangled.

ZSOLT: I do agree about the importance of making sure that you have discrete chunks of code, I guess you could say, to ensure that you don't have weird conflicts like that. Because I've had several scenarios like that in my personal experience where I had everything in a handful of functions, and that was not good. And then, I separated everything out, and things started working significantly better. And I'm like, oh, maybe that's smart. Maybe I should do that more often.

MIKE: [laughs] It just sort of magically starts working better, right?

ZSOLT: Yeah. It's kind of weird when your code is written right that it works right.

[laughter]

MIKE: Yeah, there's an uncanny parallel between code organization and code working. Again, it's not what we always talk about when we're talking about debugging, but I think it's an important thing to recognize and think about.

I think there's maybe one idea we've touched on but haven't dug into as much as we could, which is this idea of looking outside the local scope to see the context a bit more. There have been a number of times when I have been working on a problem, and I got some output. And I said, "That's just not possible. I don't understand. It's impossible." And I've learned that as soon as I think that, I need to recognize, yep, that is impossible, which means I'm looking at the problem wrong.

If an impossible thing is happening, it means I'm looking too closely. And I need to step back and think about what context this code could be operating in that could make this impossible thing happen. It means that there is some input or some state that I was not accounting for that is causing the problem. I talked about the drain pipe that was flooding my window well. I wasn't accounting for that. I was assuming that all of the problems were just coming from water pouring off the wall into the window well. And it just seemed impossible that so much water could come up in there.

Well, it was impossible, given the scope of where I was looking. And I needed to stop, take a step back, and think, where am I not looking? What am I not looking at? And that moment of pause where you stop and say, well, this doesn't seem possible; I need to take a step back and figure out what I'm not looking at, I think is one of the most valuable things that we can learn when we're debugging.

ZSOLT: The only way that you will have an impossible problem is if you're impossibly scoped because everything is either defined or undefined behavior. If you're getting something that doesn't match either of those, then your scope is wrong.

MIKE: Well, that's interesting: if you're impossibly scoped. Yeah, I think that's a really interesting idea you're saying. When you see something impossible, it means that your scope is wrong. The behavior you're saying is defined within this scope is really not the key source of the problem.

ZSOLT: Right.

MIKE: Interesting. Yeah, I think that's very well said. If you're seeing something that seems impossible, then it's almost certainly a scope problem. The problem is the scope, not the code necessarily you're looking at.

ZSOLT: Right. I deal with a lot of unmanaged code like C, and C++, and Assembly. And you get a lot of issues like that where if your scope is wrong, everything's just going to be really confusing.

MIKE: Yeah, that's really interesting. It seems to dovetail really neatly with what I was saying. When you see those impossible problems, it's evidence that your scope is wrong. You're looking too closely. And you need to step back and look at the context, well, let me look a little bit bigger. What is the environment of this problem? And maybe the environment isn't what I thought it was.

ZSOLT: As they say, you're missing the forest for the trees.

MIKE: Oh, that's great. Any other thoughts about this idea of scope or context of a problem and the impossible results, how to identify that moment to step back and look elsewhere?

ZSOLT: Sort of to touch back on what was previously discussed, a pretty solid way of making sure that you don't get into these impossible situations is to just make sure that you're writing your code in a cohesive way that doesn't cause these conflicts to happen in the first place. If you build a building out of garbage material, then that building is going to fall apart.

But if you build a building out of solid materials, it's much more likely to last longer. And the same thing can be applied to code. If you write code like crap, then it's not going to last very long because you're going to see that it's going to start falling apart at the seams. But if you write solid, well-documented code, then it's significantly easier to debug. It's significantly easier to maintain in the future.

MIKE: Thank you.

RAMSES: It's really interesting. I've been thinking about that a lot lately on how to reduce the number of bugs that are introduced by writing cleaner and more concise code.

MIKE: Yeah, it's interesting that by making your code properly modular, large groups of bugs just never happen in the first place.

ZSOLT: Somebody once told me that the best way to debug your code is to ensure that bugs don't happen in the first place.

MIKE: [laughs] I will say that in the real world, we don't always have the code we wish we had, [laughs] whether it be our own fault or that of others. But one of the things we've talked about of reducing the scope of the problem and then also looking back outward and seeing the problem in context, looking for what the true source of the problem is rather than getting too focused on right where we're at is likely to help you even when you're working with code that isn't ideal.

And then, if it's persistently a problem, you can avoid those bugs by refactoring. That's just part of the work we do. We improve the code that we're working on and leave it better for that iteration but also for ourselves in the future.

I think that ties up the discussion we've had nicely. We've talked about the various ways to address the problems by filtering away things that aren't relevant, by expanding our scope to find things that we hadn't looked for, and by improving the code so that the problems are easier to find. I think that's a great discussion on debugging. We'll leave it there. Thank you, everybody, for being here today. And we'll see you next time.

Impostor Syndrome is definitely a topic that deserves more than one discussion. It's easy to be at a desk and feel like you're not sure; do I belong here? People around me seem to know what they're doing, do I? The answer to both is Yes. We return for Part 2.

ICYMI: Here's Overcoming Impostor Syndrom Part I!

Transcript:

MIKE: Welcome to another episode of our Acima Development Podcast. We've got what I think is a good one today. So I think it's something that we struggle with as developers. I think most, if not all of us, hit this occasionally, at least. And we've got a perfect group today to talk about this subject because we've got a wide range of experience.

The topic we're going to be addressing today is impostor syndrome. Before we dive into that, let's go ahead and introduce ourselves. I'm Mike. I'm going to be hosting today. Well, let's go around. Eddy, do you want to introduce yourself?

EDDY: My name is Eddy from the QA team. Happy to be here. Thanks for having me, as always.

MIKE: Great. Damon.

DAMON: My name is Damon, and I am on the application support team.

MIKE: Thank you. And Ramses.

RAMSES: Hey, everyone. I'm Ramses. I'm on the Atlas development team. Excited to be here.

MIKE: Thank you. And I'm currently Director of Engineering here at Acima. So we've got a range of experiences, of backgrounds which I think is perfect. We've got somebody who's been doing software development for decades, somebody who's officially on the team who has only been doing it for a short time, somebody from support, and somebody from QA, both of which hope to get into development. It gives us a chance to talk about the different perspectives that we might have on a career in software and how that feels from those different positions. And there are similarities and differences, but I think you'll find that there are more similarities than differences.

Let me give a little introduction of this idea of imposter syndrome. It doesn't just apply to software; I think it applies in a number of fields but particularly in software where our job is to solve problems. There's no handbook, and there's no clear set of guidelines that this is exactly what you do. Instead, you're sitting in front of a computer with a problem to solve and sort of go ahead, solve it, and that's it.

And you certainly have peers who can help you. But it's easy to be sitting there in that desk and feel like I'm not sure; do I belong here? People around me seem to know what they're doing, do I? [laughs] I have a hard time imagining that there's anybody who doesn't feel that way sometimes. To talk a little bit about my background, I've been, as I mentioned, doing this for over 20 years. I started my full-time software career right after the dot-com bust.

A lot of those big dot-com companies from the late '90s went belly up in the early 2000s. And the industry was flooded with developers, skilled developers who had just been let go from their jobs. And there was a glut of people to do work, and the jobs hadn't quite caught up yet. And it was very challenging to find work. I eventually found full-time work. My recollection is I was making less at the time than I had been doing working construction previously. [laughs]

And I went and got a degree for this. It was certainly easy to feel like I didn't belong and I had made some wrong choices along the way. That led to some interesting developments. I was working for a startup that went really big and then crashed spectacularly. They actually let go of all the software development team but one, and then he quit. They ended up hiring me back on. So I went from being just a junior developer to running all the software for the company within just a few years. And I wasn't perfect yet, and there was a lot of pressure.

I learned a lot during that time, trying to run things on my own. I also made some mistakes and had that, you know, I'm swimming in the deep end now. There's nobody here to help me experience lots of mixed feelings. Do I belong here? Do I not belong here? I had some respect in that I was doing the job, but then I wasn't doing it perfectly. And I had all those questions.

I later moved to another company where I had a somewhat similar experience. We grew tremendously and then slowly tapered off. That company finally shut down operations back in January. And I ended up there at the department for a while and asking myself, am I doing okay? Am I not doing okay? And after a while, after that, I went to contract work.

Across all of this time, I had experiences that taught me a lot and had positions where they seemed to show some respect. But all along, all along my entire career, I've wondered, am I really doing okay here? Do I really belong? And now I'm here at Acima. I recently got my title to Director of Engineering, and it sounds kind of respectable. [laughs] But just like everybody else, I'm figuring it out. I can't claim to know everything. There's a lot that I don't know. And I'm always trying to learn just by reading and paying attention to my peers, trying to figure out how to do this the best way.

I've learned to recognize that I'm never going to know everything. It's a fast-moving field with so much to learn that I couldn't possibly know. And doing well in this industry is not about knowing everything but about having that humility, recognizing you don't and being willing to ask, and further, just trying to solve problems.

And with that, I'd like to, you know, I wanted to give an intro there. Now I'm going to be quiet for a while. And I'm interested in the thoughts of the others here on the call to share what their experience has been and how they perceive things given that background, this idea of imposter syndrome.

DAMON: Maybe you can add to what you were saying. You mentioned you were in the field for over 20 years. How did you warm up to the idea of imposter syndrome, and how did you get over it?

MIKE: That's a good question. I don't think I heard the term until much after my career had started. I don't think it's gone into widespread use; I could be wrong; one of those things that I might just not have heard about. But I don't think it's been in widespread use until the last few years. So I think there might be a few answers to that. First of all, when I heard the term, I thought, oh yes, that's what it is.

And I've noticed that as I've mentored a lot of people...and that's something I'll point out that has helped a lot. As I've mentored a lot of people, I've noticed that most developers I've worked with tend to feel that way. They'll express something along the lines of, you know, how am I doing? Do I really belong here? I feel maybe out of place, not because the people around them aren't supportive, but, wow, I'm around a lot of smart, capable people; am I really that? And the answer universally has always been yes. Yes, you are that.

And we have differences in experience. It's not that everybody has exactly the same skill level and exactly the same background. But everyone that I've worked with has had something to contribute. Perhaps the biggest differentiator I've seen as I've done a lot of mentoring between people who are really successful and people who aren't is that the really successful people are deeply curious.

They don't see asking questions as a sign of weakness but the natural consequence of their insatiable curiosity. [chuckles] They just want to figure things out. And because of that, they're willing to be vulnerable enough to ask, whether it's to ask their peers, ask mentors, ask Google, ask whatever it is they need to ask to figure problems out and experiment and try. None of us are going to quite know the answers. If we all knew the answers, then we could automate this job, and we'd all be out of work. We don't know the answers as the people who are asking the questions who have been very successful.

So to answer your question, how did I see this and get over it? A lot of it has come from not just my own experience but watching everybody else that I've worked with. I've seen so many people become successful. I've mentored a number of people who have gone on to be quite successful in their careers. And they were a diverse group of people, and they've come from different backgrounds. The number of people coming from customer support or similar roles to that, you know, who felt like, wow, I'm going into development; do I really belong here? They went on to become extremely successful.

And seeing that progress of these capable people who maybe doubted themselves at first but allowed that curiosity to blossom allowed that curiosity to lead them to ask those questions and solve the problems. If I'm curious, if I'm solving problems, if I'm helping people out around me, well, I'm adding value. And it doesn't matter if I'm exactly like everybody else around me; I'm helping.

DAMON: I find that kind of interesting because I came from a different background. So I never did customer service or anything like that. I was in the military for a few years. And I had a position where it was, hey; we're going to give you this piece of equipment. You need to figure out how it works. If it breaks, you need to figure out how to fix it.

And asking questions wasn't encouraged. It was almost frowned upon. It was like, oh, you can't figure it out? Okay, we'll find somebody who can. And when I came to this role sitting side by side with super smart people like Ramses or learning from somebody else, it was like, am I supposed to be here? Is it okay to ask these questions? I think breaking that habit for me is very challenging. [laughs]

MIKE: That's interesting. Well, I've got a couple of things to say to that. I've seen research that suggests that people who come from the military are more likely to be successful in this field. I don't know all the reasons, and I don't know that researchers know all the reasons. [laughs] But something about that background, maybe about the requirement to be a problem solver, tends to be very helpful.

The other thing I would point out, though, is what you said, is that idea of it being frowned on that I shouldn't ask questions; you experienced it there. But I think most of us experienced that somewhere. People who've gone to school, well, if you're asking the person next to you for help on your assignment, well, that might be cheating. And we get ingrained in us this idea that you shouldn't ask for help; doing that is doing it wrong.

But in the industry here, the opposite is true that if you're doing it yourself, you're doing it wrong. And let me explain that a little bit. It's not that we can't go off and solve a problem largely independently. But almost none of us are going to write in machine code. We don't write zeros and ones; we're writing computer languages, which were written by somebody else. And most of what we do is use libraries that were written by somebody else or maintain libraries that are written by a community.

And we're just working at the very top of this pyramid that stands on the work of so many women and men who've gone before us. This idea that we would be working alone is, I think, really misguided that we're all deeply dependent on those we're working with now and those who've gone before who've laid the foundation for us.

There are many different sources that will tell us, "You shouldn't be asking. You need to be figuring this out on your own." I think most people have to overcome that notion from a variety of backgrounds. Well, you got it in your previous career; many of us get it from our previous careers, or from school, or just from our upbringing. And it may not be universal, but it's quite common.

DAMON: Yeah, I think that makes sense for sure. Yeah, like you were saying, just being in this field now and asking so many questions, there are so many people that want to help you. There are so many people that are like, "If you have a question, ask." And you kind of think like, oh, that's just something people say. People are just like, you know, "If you have a question, ask." But if you really ask, they're like, "Okay, hold on, let me pair with you and break it down exactly how it's supposed to be." And you learn so much from that. And that has been super helpful, for sure.

MIKE: I'll ask a follow-up question. Have you had people say things to you like, "I love pairing?"

DAMON: Oh yeah, especially like Melissa, Afton. They're always down to pair and like, "Well, let me show you exactly how to do it," you know, it's great. They actually love just teaching.

MIKE: And that love is genuine. It's not, “I'm going to put down this because I'm sympathetic.” They genuinely love it. And I think that those of you listening can probably find a mentor like that because there's a lot of joy in mentoring. It's very enjoyable to go and watch those lights turn on in somebody's eyes and see them get it. It's a wonderful experience, and it's probably my favorite part of the job.

It's not something that I feel like I'm being burdened to do, but it's something that I feel like I get to do. Like, oh, wow, I can get out of a long meeting and instead go and help somebody find something cool. It's not something you should be shy to do. And if you're not finding mentors that are willing to do that, then maybe you need to look a little farther afield because they're out there. I found that there are many people who want to share when given the opportunity.

EDDY: When I first picked up the Atlas backlog tickets, it was easy for me to feel that I was the only one having a problem and seeing other people pushing dev tickets and stuff, you know. But in reality, with pairing, you get to see really quickly that others are presented with the same problems as well. And the unique part about pairing is you get to see their approach to how they solve a problem.

To me, the important thing that I've learned thus far is to ensure the problem doesn't become bigger than you do. Use it as a stepping stone, in a sense. So you get comfortable, and you accept it, and it's okay. And accept the fact that it's okay to ask other people for help. You've done a phenomenal job with picking the people that's on the team because everyone that I've reached out to has been more than willing to help and pair. For me, it is basically don't get scared of the uncomfortable situations and instead embrace them, and then eventually, you will find the solution.

DAMON: I think that's just something to piggyback off of here. That's something really interesting that you say because when I did my first ticket, I think it was the day before yesterday. And I was like, "Hey, can I pair with you? Because I don't know where to start," and just seeing how someone will go through the process and they run into the exact same issues that you would run into down the line, it's like, okay, I get it. [laughs]

Like, I wasn't the only one, you know, just not getting it. And then they need your input, or they want your input, and you want their input. So it's just, I don't know, I love it. Like you said, Acima, as a company, picked a fantastic team as a whole.

MIKE: One thing I'd like to maybe add to that is that...let me preface this a little bit. There's a cultural trope of a software developer as being an antisocial recluse who maybe goes down in the basement and bangs away on the keyboard alone for a long time and comes out with some masterpiece. And I'm not going to say that there's nobody who works in the basement. I work in a basement office. [laughs] But that is, in general, a misrepresentation of how software gets built. We work as a community.

Maybe let me give an example perhaps. The most successful software project on Earth is Linux, which is an operating system made by a guy named Linus who did his own take on something similar to the Unix operating system and made a portmanteau of that, of Linus and Unix, and you get Linux. He wrote this simple operating system quite some time ago, more than decades. He just gave it out to the community, formed a community around it. The community worked together to build something amazing. And he started getting industry support, and there are people paid by their companies to work full-time on that operating system. And it grew to become far more than what one person could do.

Now, Linus Torvalds is a very talented person, and he still leads that community. But he's a leader, not the sole developer. In fact, I don't think that somebody in his position should be writing most of the code or trying to because they can't, and they would be spending the time doing things that are more useful, which should be guiding the community.

I give this background to suggest something about how software really gets built. There are people who are capable and working and building things, but they really only become successful when they work together with the community. And as a leader that leader can cultivate an attitude of mentorship and community, or they can breed a toxic environment where everybody is forced to go work on things alone. That's a choice, and sometimes people don't make that choice consciously. I think they usually don't. But there are consequences to that choice that gets made.

We talked about choosing people well, and honestly, I think that that maybe misrepresents it a little bit in that there are amazing people on the team, but I think there are amazing people all throughout the world. And they're able to be amazing when they're empowered to do so. I'm going to make a passionate entreaty, a call to action to everybody out listening. Within your sphere of influence, try to create that kind of healthy community where people are encouraged and have the opportunity to ask and grow, and if you do, you will build a fertile ground for good software to come out of.

I'd like to share one more thing briefly. I'm an avid gardener. I don't always get as much time to do it as I used to, but I still enjoy it. One thing I've learned is that you don't feed the plants, and maybe if you're doing hydroponic gardening, you do. But if you're out in the soil, you don't feed the plants; you feed the soil. If you try feeding the plants, then you're going to be very focused on the plants, and that tunnel vision you get is going to miss important components. You're going to miss the broader aspect of the ecosystem you're dealing with.

If instead you pay attention to the soil and create healthy soil, so you're feeding the soil microbes and the invertebrates, and the arthropods, and worms, and whatever else is out there living in your soil and try to grow very healthy soil, then you will have a diverse ecosystem out there that's kind of self-balanced that is not likely to have a lot of diseases, for example. And when you grow your plants in it, they're growing in a healthy environment that will allow them to grow well.

If you're trying to force your plants to grow, you might be able to make it work sometimes, but it's not going to work very well in the long haul. Rather, if you feed the soil, then the plants will grow on their own naturally.

In the Midwest, where I live, there's been a change. I don't know exactly the time frame. But it used to be that the debris on the field was always plowed under in the fox. They wanted things to look tidy. They don't do that anymore. They leave the debris from the corn and soybeans on the soil to protect the soil over the winter. It keeps it from blowing away. And it decomposes, and then they turn it in in the spring, where it then feeds the soil.

And that change has led to a lot less loss of topsoil and better crops. Just thinking about growing the corn misses something really important. We feed the soil. And as leaders, what we need to do is create an environment for people to thrive, and they will because people are amazing. And they'll bring their different skills to the table and be able to do great things.

DAMON: I think that's a really good analogy.

MIKE: Ramses, we haven't heard a whole lot from you today. You've been working on the team for a while now.

RAMSES: [laughs] Yeah, it's been a while.

MIKE: What has been your experience with impostor syndrome and learning to ask those questions and feel comfortable and like you belong here?

RAMSES: My experience has been really interesting. When I started out in location support, it was very mostly do-it-by-myself kind of approach. I was very community-driven, but I was also self-motivated to find the answer however I could, whether that was just Google or asking a friend or a colleague, who are also my friends. And now it is very...it's kind of the same, but I am definitely a lot more community-driven now and not as self. I mean, I'm still self-motivated, but I try not to spend too much time on a problem by myself. And if I do find myself doing that, then I know it's time to reach out.

MIKE: Do you ever find yourself still questioning, am I sure I belong here?

RAMSES: Yeah, probably all the time. [laughs] I feel like I'm getting a lot more confident. But you do still always have the, you know, is this the right approach, or is this a good approach? Or how can I write my code cleaner or more simpler? But I think the best way to learn is to be uncomfortable, you know, put yourself in uncomfortable situations. That's how you grow.

MIKE: Absolutely. Put yourself in uncomfortable situations. We could probably spend quite a bit of time talking about that one.

RAMSES: Oh yeah.

DAMON: I remember when I was going to therapy for a minute, my therapist would always tell me, "Lean towards the discomfort. Lean towards the discomfort." And I'm like, oh man, [laughter] nobody wants to do that. That's something you just need to do. Because I feel like I have a lot of confidence, but just some days where it's like, man, I know somebody who could figure this out way faster than I could. I'm spending too much time on this. It's just a lot, you know. Yeah, just lean towards that discomfort and make yourself uncomfortable and just do it.

MIKE: Do people go to the gym because they're already, like, totally huge?

RAMSES: Sometimes.

MIKE: Sometimes. [laughter] It's true. [laughs] But they didn't get that; I mean, they didn't start out that way. They go to the gym specifically to do uncomfortable things so that they can grow.

EDDY: I think the biggest point is that when you're first starting in the industry, there's just so much knowledge, and technology, and frameworks that have been established for years before you even heard what programming was that it's really simple to start chipping at the top and you're like, dang, there's just so much I don't know, and it's really simple to feel overwhelmed. That's the problem I had when I first started. The infamous phrase it's just the tip of the iceberg, I think, applies really well here where at the surface, you're just like, yeah, I can do this. But then, if you don't have the right mindset, it's really easy to fall victim to that.

MIKE: It is. I said at the beginning, and I'll say it again, that I recognize every day how little I know after decades in the industry, and I'm an enthusiastic reader. [laughs] I've always loved reading and learning things, and I still feel like I'm just barely scratching the tip of the iceberg. But that doesn't mean that I'm not able to be effective.

I think it's a cognitive bias, some sort of psychological...I don't know if weakness is the right word because we have these biases for a reason, kind of heuristics that guide us but sometimes they lead us astray. And one of them is that we think that we have to do everything to be doing it right. That's just not true. If you've accomplished something, you've accomplished something. Accomplishing everything is nobody's realistic goal. Getting competent enough to do something is a great achievement.

If you're learning software and you're providing value to the company, then you belong there. You've just done something that company wanted. Well, of course, you belong. You just solved a problem. And you may not understand the full scope of every problem that the organization you're working for is trying to solve or the larger industry here, all the problems of humanity. But you wouldn't expect yourself to do that in other circumstances. You shouldn't have to expect yourself to do that here.

You do the ticket. You talked about working on a ticket and it seeming intimidating, pairing on it, seeing other people having trouble, and getting through it. But when you get that ticket up and in production, first of all, it's a really great feeling. [chuckles] And secondly, you've accomplished something now. You just provided value. And it doesn't really matter if it was hard. What matters is that you solved the problem.

EDDY: That's super helpful to know, and it makes me feel better about myself in a sense because a lot of the tickets that I will be working on will be beginner tickets, like right now, or cleanup tickets or something like that. So it's like, for me, it's like, oh, somebody just threw it on the side because they didn't really want to do it because, you know, it's simple to me. But it's like, hey, we needed that done. It benefited us in some type of way.

MIKE: We have a pool of work. I used to talk about it with a former product manager. And we said, "This is important work, but it's not necessarily urgent." It's kind of a monster. It applies in software, but I'm thinking it applies in probably many fields of urgency that there's always something that's got to be done in a short time frame. And if you're always paying attention to that monster and fighting it away, then you never take care of some other things that are extremely important. They're just not as urgent.

And in the worst case, you can have a situation they call firefighting where you're just running and putting out one fire and then running and putting out another fire because the whole system is just barely holding together, and things are falling apart. And you just solve one disaster after another because you're never taking the time to do the maintenance to prevent those disasters.

And you say that you're doing this work that maybe doesn't seem like it's the most urgent. Well, it is true that we tend to have people who are wanting to become developers; we'll give them work that is not the most urgent because we're trying to get it done quickly, but that doesn't mean it's not important.

I'm thinking about that condominium complex in Florida that collapsed a year or two ago. There were problems with the foundation that people had noticed for some years, like parts had been falling into the parking garage. And I think that the pool was not shored up well. And people had seen that for a number of years, seeing that there were problems, but there was always something more important to work on. And I can say important, that's the wrong word. There's always something more urgent to work on. And they didn't take the time to do that work of shoring up the foundation. When it failed, it was catastrophic and tragic. People died.

EDDY: Oh yeah.

MIKE: Had they had somebody go in and do that work to just shore up the foundation, "Let's fix the foundation here and make sure that important work is done. Even if it's not necessarily urgent, we're going to specifically dedicate some budget to having this important work done," then that tragedy could have been averted, and lives could have been saved.

We're probably not talking about such a life-and-death thing with most of the work that we're doing. Maybe you're in healthcare, and it is life and death. But there is important work to be done, and you shouldn't feel like it's irrelevant just because it's not the most urgent work. We wouldn't have identified that work and created stories for it to be worked on if it wasn't important.

DAMON: I think just hearing that is super reassuring for me personally. It makes me want to learn more and obviously just go and grab tickets and just be like, okay, let me figure it out. Let me learn. Okay, I don't know it. All right, who wants to pair? It's good to hear that, for sure.

Mike, let me ask you something point blank here.

MIKE: Yeah, absolutely.

DAMON: When you are in the middle of that transition where you have that milestone that you want to become a full-time developer, is there a general consensus, or is it like perspective for you when you know that you're ready to take that leap? Where do you define that line?

MIKE: That's a great question. Let me try to give you a nuanced answer because I think that a short answer is probably not going to quite cut it. And my nuanced answer is going to be that it probably depends on your situation. Let me elaborate a little bit. You're never going to be ready, and recognizing that, I think, can take a burden off your shoulders because if you're never going to be ready, then you don't have to worry about being perfectly ready. But I think that giving examples is helpful here.

So let's talk about Olympic athletes. Olympic athletes will spend years, sometimes even decades, of their life training. They're usually younger, so maybe not decades but many years of their lives training for that one moment. And still, only one person is going to win, and sometimes it's a fluke. Somebody has come prepared as well as they possibly can. And then something goes wrong, and it's outside of their control.

We have human limits that prevent us from really being able to be truly prepared for something completely. That shouldn't be our goal. So I'm going to scale that back to say, well, if you can't be perfectly ready, well, what can you be? And I would say you're ready to jump in if you can consistently provide value in the position that you're going to be given.

So, for example, let me take an example outside of software. I've worked in construction. And I spent some time as an apprentice carpenter. First, I worked as a laborer. And when they have you work as a laborer, you're not really expected to have any experience at all, and your value comes from being able to haul things around and tear stuff down. You can carry around power cables and plug them in.

And I worked at a job once where I tore a whole bunch of wallpaper off walls in a large building. You know what? I didn't have to have a whole lot of skills to do that, just the willingness to spend long sweaty days tearing [laughs] wallpaper off walls. After a while, though, because I actually had had background before that, they had me start with putting on sheetrock because I knew how to do that. And I was providing a little bit more value.

Now I was providing value as a laborer, but I could provide a little more value by actually doing some of the carpentry work. And then I started putting up some of the other parts of the walls, putting in the studs. The job I'm particularly thinking of was indoor construction in the south. So they didn't put in termite-vulnerable things. So we used metal studs, but you screwed them in. I started doing that, so I was providing additional value. Had I stayed at that particular job, I would have become an actual carpenter and become a master of that profession over time.

Well, back in software, nobody's expecting you when you start...if you're getting hired as a senior developer, well, then you should probably have senior developer experience. But when people are hiring you as a junior developer, that's not what they're hiring you to do. They're hiring you to provide value. If what they need is somebody to haul around the wires and the equipment and tear stuff off the walls, well, then you're providing value in that position.

And if you're at a company that would be interested in what you have to offer, then you belong, then you're ready. And if you don't have the skills that they need yet, well, then you should build those skills. If you're actively looking to get that career, one of the best ways to do so is to find a position where you can start to work on some of those tasks before you're necessarily full-time. Go and talk to the development team, "What can I help you with?" Most people would love to get some help with something.

I gave kind of a long answer to your question because I think that it's important to recognize that you might not be able to find a clear-cut point. You're never going to feel like you're perfectly prepared. But if you can put yourself in a position where you're helping, you're already doing the work. And I think you're ready to go full time when you're able to consistently be providing value all of the time and give more than you get, I guess I would say.

DAMON: Those are fantastic answers. Thank you. Ramses, I kind of want to piggyback off of that question to you as well since it's more recent since you made that transition. When the opportunity presented itself, what was your mindset before and after?

RAMSES: I'm probably a prime example of that question, I think. Before getting into application support in...what was it? October...no August 2020, maybe, time slips by. I had no development experience or very little. And then getting into application support October 5th is, when I picked up my first ticket. And it was a simple add a new selection in this HTML drop-down, super simple. But it kind of really sparked my interest, and from there, just on nights and on weekends, I'd go through Ruby courses and everything else.

But by the time I made my switch over to full-time development, I had maybe 160 tickets I had merged into production. Through my application support time, I tried to pick up a ticket, a development ticket every week, or a couple every week as much as I could, even if they were just small and simple, and most of them were. But sometimes, I'd work on slightly larger projects, but it was really helpful for my development, I think.

MIKE: I would point out just how closely that mirrors what I was saying, but Ramses provided help, started working on things. He was not full-time yet but grew his skills where he could eventually get to the point where he was basically acting as a developer anyway. So let's hire him on. He's already doing the work. Let's hire that guy already. And he's continued to do a great job, by the way.

DAMON: I can attest that Ramses has been a great asset and a great resource. Coming from someone he trained, he is the best. [laughs]

EDDY: Even though it's bias-ism, I agree, Damon, [laughs] cold-heartedly agree with that statement, yeah.

DAMON: Ramses, did you ever have the imposter syndrome whenever you found out or decided to become a full-time developer?

RAMSES: Yeah, I'm sure I probably did. It was something that I was long waiting for, had plans on moving into development in May 2021 and just had some unexpected events come up, so it just didn't really work out then. But I finally made that transition in...was it February, January? Maybe late January 2022. Sounds about right. Well worth the wait.

MIKE: So we've talked for a while about our individual experiences feeling this imposter syndrome and some ways that we can overcome it: working on building your skills, recognizing some of the psychological biases we have that might mislead us into thinking that we're not ready when we might be, and what we can do to be ready. There is actual value to preparation. Just jumping in completely unprepared isn't a good idea, but recognizing that no amount of preparation is going to fully prepare you. Does anybody have any closing thoughts to tie this up before we conclude our session today?

EDDY: I think it was just comforting to hear that even people who have years in the industry can also relate. And just being able to be vocal and having someone take time to listen to their concerns goes a long way with…

DAMON: The exact same thing. To piggyback off of what he said, hearing people that have had so much time in this industry and have been doing this for a minute they still go through the same things even to this day; as a newbie, it's good to hear that for sure. And it's good to know that we have people all around that want to listen and want to help because they were in that position.

MIKE: Well, let's go ahead and finish up then. Recognize that imposter syndrome is a thing. It's something that strikes most, if not all of us, in making us feel like because we're not perfect, that we don't belong here. We need to do a few things, you know, reach out to mentors, find somebody who can help you as that can make a big difference. Also, recognize that if you are providing value, then you belong. That's what organizations want is somebody who can help. If you're helping, then you're doing the right thing.

And finally, if you're wanting to grow your position, reach out and find opportunities to move into that gradually if possible. Find opportunities to help outside the boundaries of where you are. Stretch yourself. If you're not in software development, take a class or reach out. If you're working in a place where they have a development department, ask them if you can help. Can I take some tickets and work on those that you might not have time to do? And hopefully, that'll be well received. And many times, I think it will because people love help.

There are things we can do to move forward despite our lack of perfect experience that can really help overcome that idea of feeling like you don't belong. Because once you see yourself moving forward and helping people out, you recognize that you do belong there and you're making a difference.

It's been another great discussion, and I look forward to doing this again next time. Thank you.

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 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.

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.