What Project Did You Work on that Really Propelled Your Abilities to the Next Level?

About this Episode

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

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

Transcript:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MATT: Right.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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